IAM and Identity Across Clouds: Why Permissions Take Longer Than the Install

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

DevOps from Zero #12

⚡ Byte Size Summary

• Tell the difference between authentication (who is this?) and authorization (what can it do?) on AWS, Azure and GCP
• Map the same idea to each cloud's vocabulary: IAM roles, managed identities and role assignments, service accounts and IAM bindings
• Add an identity pre-check to your runbook so approvals stop blocking installs

The Story

A ROSA install cannot start until the customer has accepted the terms and activated the ROSA listing on the AWS Marketplace. That part takes minutes. The part after it is where the time goes.

ROSA installs with an STS-based installer role. That role carries an elevated trust policy, so the customer's cloud security team has to review it before anyone creates it. On the engagements I worked, that review took 3 to 5 days. One customer took almost 2 weeks. Once a customer decided to proceed, the average was about 1 week from the start of the security review.

Nothing about the cluster was waiting. The team was waiting on a permission.

We fixed it with a runbook change, not a technical one. Identity and permissions approval became a required pre-check item. If the pre-check was not complete, the install did not start. The pre-check is a set of provider-specific scripts and CLI commands that inspect the target account or subscription for problems before anything gets provisioned.

I am telling you this in an identity article because it is the most common reason cloud projects stall, and it is rarely a technical reason.

The Problem

Every cloud has to answer two questions every time something makes a request:

1. Authentication: who is making this request?
2. Authorization: is that identity allowed to do this specific thing?

Beginners collapse these into one. They give a workload an identity, attach a role, and assume it can now reach everything it needs. Then the request fails with an access denied error, and they cannot tell which half is broken.

This happens on AWS, Azure and GCP. The names differ. The mistake does not.

The second problem is time. New cluster installs and new customer onboardings need elevated permissions: AWS service control policies (SCPs) that allow the install, and the equivalent on Azure and GCP through managed identities or service accounts. Those permissions need approval, and approval has a queue.

Why Existing Approaches Fall Short

The usual fix for a permissions error is to grant broader access until it works. An administrator-level role makes the error disappear. It also removes the review that the security team was about to do, and nobody can later explain why that identity needs that much.

The usual fix for the delay is to ask earlier, informally. That works until the person who remembers to ask is on holiday. A request that lives in someone's head is the same tribal-knowledge problem we covered in the Infrastructure as Code article, applied to permissions.

Neither approach is repeatable. Both lead to the same outcome: an install that starts, then stops.

The Architecture

The diagram shows the same three-step chain on each cloud: an identity, a grant that connects it to a role or permission set, and the resource it wants to reach. It marks the one place the chain breaks: the identity authenticates successfully, but no grant exists for the target resource.

That break point is the design lesson. A successful login proves nothing about permissions.

How It Works: Step by Step

You can separate the two questions with commands. The first command on each cloud answers who am I. The second answers what can I do.

1. Check who you are authenticated as

# AWS
aws sts get-caller-identity

# Azure
az account show

# GCP
gcloud auth list

2. Check what that identity is allowed to do

# AWS: simulate whether a role may perform a specific action
aws iam simulate-principal-policy \
  --policy-source-arn <role-arn> \
  --action-names s3:GetObject

# Azure: list role assignments for an identity
az role assignment list --assignee <principal-id> --all

# GCP: show which members hold which roles on a project
gcloud projects get-iam-policy <project-id>

If step 1 succeeds and step 2 shows no matching grant, you have found the authentication-versus-authorization gap.

3. Put the check in the runbook

For ROSA, the pre-check also covers the account-level prerequisites before the install begins.

# [AUTHOR TO VALIDATE] — insert the pre-check script / CLI commands used in the standard runbook

The rule that mattered more than the script: the install does not start until the identity approval line is checked.

Security and Operational Considerations

• Scope grants narrowly. On Azure, a role assignment at subscription scope reaches everything below it. Assign at the resource group or resource when you can.
• Prefer attached identities over stored keys. Roles, managed identities and service accounts attached to a workload avoid long-lived credentials sitting in a repo or an environment variable.
• Do not skip the review to save the week. The elevated trust policy on an installer role is the reason the review exists. Shorten the wait by asking earlier, not by granting more.
• Rollback. Identity changes are easy to add and easy to forget. Record every role and policy you create for an install so you can remove them when the cluster goes away.

What Breaks at Scale

One account is manageable. Twenty accounts, subscriptions and projects are not, because the approval queue repeats per environment and manual grants drift apart. Three clouds also means three vocabularies for the same ideas, so a team fluent in IAM roles still has to relearn managed identities and service accounts.

The pre-check scales better than memory does. Each new environment runs the same list.

Quick Recap

• Authentication and authorization are separate — a working identity does not mean a permitted action
• The same chain exists on every cloud — identity, grant, resource; only the names change
• Approval time is the real blocker — 3 to 5 days typical, almost 2 weeks at worst for the ROSA installer role
• Make approval a pre-check — if it is not complete, the install does not start