Cloud access from CI — what cloud credentials do

A cloud credential that the CI assumes is a production credential. The role the workflow declares can read every resource the role can reach — including the production databases, the production object stores, the production secrets, and the production network. A CI job that assumes a misconfigured IAM role is a CI job that reads production silently. The discipline is two-fold: trust OIDC federation to issue the right token for the right job, and verify the assumed identity before every privileged step.

What a cloud credential enables

A cloud credential on a CI runner enables every capability the identity has been granted. The blast radius is the union of the identity’s grants.

flowchart TB
    CRED["Cloud credential"]
    CRED --> I["Identity layer"]
    I --> R1["Compute"]
    I --> R2["Storage"]
    I --> R3["Database"]
    I --> R4["Network"]
    I --> R5["Secrets"]
    I --> R6["Container"]

A narrow role limits the radius; a broad role with AdministratorAccess makes the radius the entire account. The categories are the same on every cloud: IAM in AWS, service accounts in GCP, subscription identities in Azure. The blast radius scales with the grants.

Verify the assumed identity

The first thing a CI step does after assuming a cloud identity is verify which identity it assumed. AWS provides aws sts get-caller-identity; GCP provides gcloud auth list; Azure provides az account show:

aws sts get-caller-identity

The output names the account, the user/role ARN, and the session identifier. The CI engineer writes a test that parses the ARN and asserts it matches the expected role for the workflow; a mismatch fails the step before any privileged call. The verification catches a wrong trust policy, a wrong role, a leaked credential, and a misconfigured OIDC federation.

Trust policy and workflow declaration

OIDC federation requires two configurations that must agree. The forge side: the workflow declares which role it wants to assume via aws-actions/configure-aws-credentials or equivalent. The cloud side: the IAM role’s trust policy declares which forge, repository, branch, and workflow path may assume the role.

flowchart LR
    subgraph FORGE["Forge side"]
        W["Workflow declares role"]
    end
    subgraph CLOUD["Cloud side"]
        T["Trust policy: repo plus branch plus workflow"]
    end
    FORGE -->|"Token validated"| CLOUD
    CLOUD -->|"STS token issued"| JOB["Job, scoped, ~1h"]

A trust policy that allows '*' for the repository is a trust policy that allows any repo on the forge to assume the role. The structural fix is to scope the trust policy to the repository, branch, and workflow path; the operational rule is to review the trust policy every time the workflow file changes.

Production discipline

1. OIDC federation for cloud access. Every cloud has an OIDC integration; every workflow declares the role it needs; every trust policy is scoped to repo, branch, and workflow path.
2. Verify the assumed identity before every privileged step. aws sts get-caller-identity, gcloud auth list, az account show.
3. No long-lived cloud keys on runners. No IAM user keys, no service account JSON files, no static credentials on disk or in environment variables.
4. Trust policy is part of code review. The PR diff includes both the workflow and the trust policy.
5. Audit the cloud surface quarterly. Every role the CI assumes, every trust policy, every OIDC issuer.

Cross-course references

• Part XC-01 (What the CI platform can touch) maps the cloud surface in the wider blast radius.
• Part XLI-03 (Production credentials on runners) covers why OIDC is the structural fix.
• Part XLIII-04 (OIDC in AWS) covers the practical AWS configuration.
• AWS for Production Sysadmins — Part XXXI (IAM) covers the trust policies that gate role assumption.

Quiz