Skip to main content

Cross-Account Trust Relationships

Last Updated: 2026-03-02 Source: innovation-sandbox-on-aws, ndx-try-aws-lza, IAM role discovery Captured SHA: cf75b87 (ISB), 6d70ae3 (LZA)

Executive Summary​

The NDX:Try AWS platform uses three cross-account trust mechanisms: GitHub OIDC for CI/CD deployments from GitHub Actions, ISB intermediate roles for hub-to-pool-account operations, and LZA/Control Tower execution roles for infrastructure management. Five GitHub Actions OIDC roles are configured in the hub account, scoped to specific co-cddo repositories. ISB Lambda functions assume an intermediate role to perform operations in the 110 sandbox pool accounts.

Trust Architecture Overview​

1. GitHub OIDC Provider​

PropertyValue
Provider ARNarn:aws:iam::568672915267:oidc-provider/token.actions.githubusercontent.com
Provider URLhttps://token.actions.githubusercontent.com
Audiencests.amazonaws.com
Account568672915267 (Hub)

The OIDC provider enables GitHub Actions workflows to obtain temporary AWS credentials without storing long-lived secrets. All trust relationships use sts:AssumeRoleWithWebIdentity with repository-scoped conditions.

Trust Policy Pattern​

All GitHub Actions roles use this trust policy structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::568672915267:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:co-cddo/<repo-name>:*"
        }
      }
    }
  ]
}

2. GitHub Actions IAM Roles​

Role NameTrusted RepositoryPurpose
github-actions-innovation-sandbox-on-aws-deployer-deployco-cddo/innovation-sandbox-on-aws-deployerDeploy ISB Deployer CDK stack
GitHubActions-Approver-InfraDeployco-cddo/innovation-sandbox-on-aws-approverDeploy Approver CDK infrastructure
GitHubActions-NDX-ContentDeployco-cddo/ndxDeploy NDX website content to S3
GitHubActions-NDX-InfraDeployco-cddo/ndxDeploy NDX website CDK infrastructure
GitHubActions-NDX-InfraDiffco-cddo/ndxCDK diff for NDX pull request reviews

Repository-to-Role Mapping​

Repositories Without OIDC Roles in Hub​

The following repositories do not have visible GitHub Actions OIDC roles in the hub account. They may deploy to different accounts, use alternative authentication, or deploy manually:

  • innovation-sandbox-on-aws-billing-seperator
  • innovation-sandbox-on-aws-costs
  • innovation-sandbox-on-aws-utils
  • ndx_try_aws_scenarios
  • ndx-try-aws-lza (deployed via LZA pipeline in org management)
  • ndx-try-aws-scp (deployed via Terraform to org management)
  • ndx-try-aws-terraform

3. ISB Operational Cross-Account Roles​

Hub-to-Pool Account Access​

The ISB core uses two role chains for cross-account operations:

Intermediate Role (General Operations)​

PropertyValue
Role NameInnovationSandbox-ndx-IntermediateRole
LocationHub account (568672915267)
Assumed ByISB Lambda functions (Accounts, Leases, Monitoring, Cleaner)
PurposeAssume spoke roles in pool accounts

The intermediate role is a jump role -- ISB Lambdas first assume this role, then use it to assume the spoke role in the target pool account:

ISB Lambda -> IntermediateRole (hub) -> SpokeRole (pool account)

Deployer Role (CloudFormation Deployment)​

PropertyValue
Role Nameisb-deployer-role-prod
LocationHub account (568672915267)
Assumed ByISB Deployer Lambda
PurposeDeploy CloudFormation stacks in pool accounts

Pool Account Spoke Roles​

Each pool account contains roles that trust the hub account:

RolePurposeTrust
InnovationSandbox-ndx-SpokeRoleISB operational access (OU moves, SCP application)Hub intermediate role
OrganizationAccountAccessRoleFull administrative accessOrg management account
AWSControlTowerExecutionControl Tower provisioningControl Tower
stacksets-exec-*CloudFormation StackSets executionHub account

Hub-to-Org Management Access​

PurposeMechanism
Cost Explorer queriesISB Cost Reporting Lambda assumes role in org management (955063685555)
Account registrationISB Accounts Lambda calls Organizations API via org management role
OU managementISB Account lifecycle Lambda moves accounts between OUs

4. Billing Separator Roles​

The billing separator service has its own role chain for quarantine operations:

RolePurpose
isb-billing-sep-scheduler-role-ndxEventBridge Scheduler for timed unquarantine
isb-billing-separator-hub-QuarantineLambdaServiceRole-*Lambda that moves accounts to Quarantine OU
isb-billing-separator-hub-UnquarantineLambdaServiceRole-*Lambda that moves accounts back to Available OU
isb-billing-separator-hub-LogRetentionaae0aa3c5b4d4-*CloudWatch log retention management

5. LZA / Control Tower Execution Roles​

Landing Zone Accelerator and Control Tower use privileged execution roles across all accounts:

RolePresent InPurpose
AWSControlTowerExecutionAll accountsControl Tower baseline provisioning
AWSAccelerator-*All accountsLZA stack deployment and management
cdk-accel-*All accountsCDK bootstrap for LZA

These roles are exempted from all SCPs to ensure infrastructure management continues to function.

6. SCP Exemption Pattern​

All ISB and infrastructure SCPs use a common exemption pattern for privileged roles:

{
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalARN": [
        "arn:aws:iam::*:role/InnovationSandbox-ndx*",
        "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*AWSReservedSSO_ndx_IsbAdmins*",
        "arn:aws:iam::*:role/stacksets-exec-*",
        "arn:aws:iam::*:role/AWSControlTowerExecution"
      ]
    }
  }
}

This ensures that ISB control plane operations, ISB admin SSO sessions, StackSets execution, and Control Tower provisioning are never blocked by ISB-managed SCPs.

Cross-Account Access Flow Summary​

Security Observations​

  1. Repository Scoping: All OIDC roles are scoped to specific co-cddo/* repositories using StringLike conditions, preventing cross-repository impersonation.

  2. Audience Validation: All OIDC roles validate aud: sts.amazonaws.com.

  3. No Long-Lived Credentials: GitHub Actions use short-lived OIDC tokens; ISB uses STS temporary credentials.

  4. Role Naming Inconsistency: Mix of github-actions-* (lowercase) and GitHubActions-* (PascalCase) naming patterns. Consider standardising.

  5. CDK Random Suffixes: Many ISB core roles have CDK-generated random suffixes, making audit harder. The role purpose must be inferred from the prefix pattern.

Generated from IAM role analysis and CDK source inspection on 2026-03-02. See 00-repo-inventory.md for full inventory.