Review cloud permissions and role trust together

A role may have a narrow resource policy but an overly broad trust relationship, allowing an unintended workload to obtain its credentials. Conversely, a carefully restricted trust policy can lead to a role that has excessive authority. Review identity acquisition and resource access as separate, connected decisions.

Cloud providers express these decisions differently. AWS role trust and permission policies, Azure identities and role assignments, and Google Cloud principals and IAM bindings are not interchangeable configuration formats. Begin with one provider and a concrete task, such as allowing a production export worker to write to its designated object prefix.

Start with two edges: workload → role, then role → resource action. In this example a production invoice exporter should assume ExportNorth and write objects under north/. A staging runner should obtain neither that role nor its production capability. The role name and a successful test under production do not constrain staging. The trust policy must enforce the intended workload identity using claims the configured issuer authenticates.

The Terraform below states the whole model for AWS. GitHub Actions signs every job's token with the same issuer, https://token.actions.githubusercontent.com, so trusting the issuer alone would admit every repository on GitHub. The trust policy therefore requires the audience sts.amazonaws.com and the exact subject repo:company/reports:environment:production with StringEquals; a prefix such as repo:company/* would admit every repository in the organization. Subject formats depend on the provider and on how the job runs, so check the claims your jobs actually present.

On the use side, compare action, resource and applicable conditions. The role may only PutObject under exports/north/, and an organization SCP explicitly denies DeleteObject on every export object; real AWS evaluation can also involve resource policies, session policies and permissions boundaries. Here PutObject north/a.csv is allowed, GetObject is not granted, and DeleteObject is explicitly denied. Adding an Allow for DeleteObject does not override that explicit deny. The configuration passed terraform validate and the four Checkov trust checks.

Finally review who can alter either edge. Someone allowed to change a trusted pipeline or deploy arbitrary code under its service account may gain its role without modifying IAM. Someone allowed to update ExportNorth’s permissions can expand its capability. These are administration paths, not harmless metadata rights. Record them as privileged access and protect their change process and credentials accordingly; the GitHub Actions hardening guide at /domains/supply-chain/ci-cd/github-actions-hardening/ covers the workflow side.

# GitHub Actions jobs in the production environment of company/reports, and nothing else,
# may assume ExportNorth, which can only write objects under exports/north/.
data "aws_caller_identity" "current" {}

resource "aws_iam_openid_connect_provider" "github" {
  url            = "https://token.actions.githubusercontent.com"
  client_id_list = ["sts.amazonaws.com"]
}

data "aws_iam_policy_document" "export_north_trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/token.actions.githubusercontent.com"]
    }
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:sub"
      values   = ["repo:company/reports:environment:production"]
    }
  }
}

resource "aws_iam_role" "export_north" {
  name                 = "ExportNorth"
  assume_role_policy   = data.aws_iam_policy_document.export_north_trust.json
  max_session_duration = 3600
}

data "aws_iam_policy_document" "export_north" {
  statement {
    actions   = ["s3:PutObject"]
    resources = ["arn:aws:s3:::exports/north/*"]
  }
}

resource "aws_iam_role_policy" "export_north" {
  role   = aws_iam_role.export_north.id
  policy = data.aws_iam_policy_document.export_north.json
}

# Organization guardrail: no principal in member accounts may delete export objects,
# whatever its own policies allow. SCPs do not restrict the management account.
data "aws_iam_policy_document" "deny_export_delete" {
  statement {
    effect    = "Deny"
    actions   = ["s3:DeleteObject"]
    resources = ["arn:aws:s3:::exports/*"]
  }
}

resource "aws_organizations_policy" "deny_export_delete" {
  name    = "deny-export-delete"
  type    = "SERVICE_CONTROL_POLICY"
  content = data.aws_iam_policy_document.deny_export_delete.json
}

Prefer provider-supported workload identities and temporary credentials over distributing long-lived keys; the workload identity models guide at /domains/identity-crypto/identity/workload-identity-models/ compares them. Identify the exact issuer, intended audience, subject or workload binding used to obtain credentials. Restrict trust to the required repository, environment, service account or external principal as the provider supports; accepting an entire organization or generic issuer can be far broader than the feature needs.

Review who can change the trusted workload, identity binding or deployment definition. An attacker able to deploy code under a trusted identity may inherit its permissions without changing IAM. For cross-account or third-party access, defend against the confused deputy: require sts:ExternalId in a role a vendor assumes for you, and add aws:SourceArn and aws:SourceAccount conditions when an AWS service acts on your resources, so another customer cannot direct the same service at your role or bucket. Do not treat a descriptive role name as an enforced environment boundary.

Google Cloud and Microsoft Entra ID express the same trust differently. A workload identity pool provider for GitHub must carry an attribute condition, and Google asks at least for the owner; the one below requires the exact subject. An Entra ID federated identity credential matches one exact subject and the audience api://AzureADTokenExchange. Checkov passed both and failed a Google provider whose condition only checked the repository owner. Its AWS check failed repo:* and a subject without a repository, but passed repo:company/*, and it skipped the policy entirely until the federated principal was written as an ARN it could recognize, so a passing scan is not a review.

# Google Cloud: the pool provider admits only tokens from that repository and environment
resource "google_iam_workload_identity_pool_provider" "github" {
  workload_identity_pool_id          = "ci"
  workload_identity_pool_provider_id = "github"
  attribute_mapping = {
    "google.subject"       = "assertion.sub"
    "attribute.repository" = "assertion.repository"
  }
  attribute_condition = "assertion.sub == 'repo:company/reports:environment:production'"
  oidc {
    issuer_uri = "https://token.actions.githubusercontent.com"
  }
}

# Microsoft Entra ID: a federated credential matches one exact subject
resource "azuread_application_federated_identity_credential" "github_production" {
  application_id = "/applications/00000000-0000-0000-0000-000000000000"
  display_name   = "github-reports-production"
  issuer         = "https://token.actions.githubusercontent.com"
  subject        = "repo:company/reports:environment:production"
  audiences      = ["api://AzureADTokenExchange"]
}

List required actions and resources, including indirect operations such as passing a role, changing a policy or reading an encryption key. Remove wildcard access where the service supports meaningful scoping. On AWS, effective access can involve identity policies, resource policies, permissions boundaries, organization controls and session policies; explicit denies and service-specific rules matter.

Review public resource exposure separately from authenticated role permissions. A private application role cannot compensate for a broadly readable storage resource. Protect deployment state and audit logs, and identify which administrators can weaken the controls. Provider analysis tools help discover access paths, but their scope and modeled conditions must be understood.

Use a disposable environment or an explicitly scoped simulator to test the intended action and forbidden neighboring resources. Attempt identity acquisition from the wrong environment and test behavior after revocation or credential expiry. Record principal, resource, action, context and outcome without storing credential material. A successful policy simulation should be followed by a controlled service call where the simulator cannot model the full resource path.

Temporary credentials reduce the duration of some exposures but are not harmless. A stolen active session can exercise its granted permissions until the provider’s relevant controls take effect. Removing future role-assumption permission and invalidating already-issued sessions are separate response questions; verify the provider’s revocation semantics and credential lifetime.

A simulator that evaluates one identity policy cannot establish the complete effective path if it omits resource-policy grants or conditions. Save the modeled policy set and context with its result. Follow with a controlled service request where necessary, and distinguish authentication failure, explicit denial and absence of a grant when diagnosing the result.

These outcomes belong to the worked model, which the Terraform above encodes; confirm them with real calls in a disposable account.

Repair the code

IAM trust policy lab: Evaluate a role trust policy against the confused deputy

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. AWS IAM security best practices
2. AWS policy evaluation logic
3. AWS Security Pillar
4. GitHub Docs: OpenID Connect
5. GitHub Docs: configuring OpenID Connect in Amazon Web Services
6. AWS IAM: OIDC federation roles
7. AWS IAM: the confused deputy problem
8. Google Cloud: workload identity federation with deployment pipelines
9. Microsoft Entra: workload identity federation

Reference information

Tags

Access controlWorkload identityCI/CD securityCloud securityInfrastructure as code

SDLC phase

ReleaseMaintenance

Role

DevelopersPlatform engineers and SREs

Download this guide as Markdown

Continue exploring