Cross-Account Role Security Model

CloudBooster uses an AWS cross-account IAM role to discover and import your existing infrastructure. This page documents the security model, the permissions that role holds, how access is scoped, and the operational procedures for managing it.

IAM Permissions

The CloudBooster CloudFormation template creates a cross-account IAM role with a curated set of permissions. Each action is scoped to the minimum set required for read-only infrastructure discovery.

What CloudBooster Does and Does Not Do

The cross-account role is used exclusively for read-only infrastructure discovery and import. The following table clarifies the boundaries of that access.

CloudBooster DOES

CloudBooster DOES NOT

Account ↔ Environment Binding Rule

CloudBooster enforces a strict one-to-one mapping between an AWS account and a CloudBooster environment.

Binding Rules

Why Duplicate-Account Binding Is Rejected

Allowing a single AWS account to be imported into multiple CloudBooster environments creates unacceptable risks:

1. State Conflicts — Two environments could generate conflicting provisioning instructions for the same physical resource.
2. Ownership Ambiguity — It becomes unclear which environment is the source of truth for a given resource's desired state.
3. Blast-Radius Expansion — A misconfiguration or destructive action in one environment could affect resources shared with another.

Setting Up Multiple Environments

If your organization needs multiple CloudBooster environments (e.g., staging and production), provision separate AWS accounts and run the CloudFormation template in each:

# Staging account
aws cloudformation create-stack \
  --stack-name cloudbooster-import-role \
  --template-url https://cloudbooster.io/cfn/cross-account-role.yaml \
  --parameters \
    ParameterKey=CloudBoosterExternalId,ParameterValue=extid-staging-001 \
  --capabilities CAPABILITY_IAM \
  --profile staging
 
# Production account
aws cloudformation create-stack \
  --stack-name cloudbooster-import-role \
  --template-url https://cloudbooster.io/cfn/cross-account-role.yaml \
  --parameters \
    ParameterKey=CloudBoosterExternalId,ParameterValue=extid-production-001 \
  --capabilities CAPABILITY_IAM \
  --profile production

Retention and Storage Policy

Metadata Retention

Encryption at Rest

All discovered metadata is encrypted at rest:

• Database encryption — AES-256-GCM using cloud-provider-managed keys (AWS KMS / GCP Cloud KMS).
• Object storage encryption — Server-side encryption (SSE-S3 or equivalent) for import snapshots and artifacts.
• Encryption in transit — All data moving between CloudBooster services and your AWS account is protected by TLS 1.3.

Rotation Playbook

Rotating the cross-account role and its external ID is a recommended security hygiene practice. The steps below ensure zero-downtime rotation without breaking CloudBooster tracking.

Prerequisites

• AWS CLI access to the target account with permissions to update CloudFormation stacks.
• CloudBooster admin access to the target environment.

Step 1: Generate a New External ID

In the CloudBooster portal:

1. Navigate to Environment Settings → AWS Import → Rotation.
2. Click Generate New External ID.
3. Copy the newly generated external ID (e.g., extid-2025-abc123).

Step 2: Update the CloudFormation Stack

aws cloudformation update-stack \
  --stack-name cloudbooster-import-role \
  --template-url https://cloudbooster.io/cfn/cross-account-role.yaml \
  --parameters \
    ParameterKey=CloudBoosterExternalId,ParameterValue=extid-2025-abc123 \
  --capabilities CAPABILITY_IAM

Wait for the stack update to complete:

aws cloudformation wait stack-update-complete \
  --stack-name cloudbooster-import-role

Step 3: Validate the Connection

1. Return to the CloudBooster portal.
2. Click Test Connection in the environment settings.
3. Confirm that the import wizard successfully lists resources from the updated role.

Step 4: Revoke the Old External ID

Once validation passes:

1. In the portal, click Revoke Old External ID.
2. The previous external ID is immediately invalidated.
3. Only the new external ID is accepted for future STS assume-role calls.

Threat Model Summary

What a Compromised CloudBooster Platform Could Do

If an attacker gained control of the CloudBooster platform and obtained valid STS credentials for your cross-account role, they could:

• Enumerate infrastructure — List VPCs, subnets, EC2 instances, RDS databases, S3 buckets, and Lambda functions.
• Read configurations — View security-group rules, IAM policies, route tables, and resource tags.
• Map dependencies — Understand how resources relate to each other (e.g., which instances are attached to which load balancers).

What a Compromised CloudBooster Platform Could NOT Do

The cross-account role is intentionally scoped to limit blast radius:

• No write access — The role does not include Create*, Put*, Update*, Delete*, or Modify* permissions.
• No data access — The role cannot read object contents from S3, query RDS tables, or access EBS volume data.
• No privilege escalation — The role does not include iam:PassRole, sts:AssumeRole, or permissions to edit its own trust policy.
• No lateral movement — The role is scoped to a single AWS account and cannot access other accounts in your organization.
• No long-lived credentials — STS credentials are short-lived (default 1 hour, minimum 15 minutes) and cannot be reused after expiration.

Mitigations