Description

Explains why AWS Assume Role with STS and External ID is the security best practice for CMDB discovery, covering the risk of static access keys, the confused deputy attack, and how to configure cross-account access safely for multi-account environments.

AWS Assume Role for CMDB Discovery: Why Cross-Account Access Control Matters for Security

TLDR

Using static AWS Access Key ID and Secret Access Key for CMDB discovery is a security risk. AWS Assume Role with STS provides temporary credentials with scoped permissions. External ID prevents confused deputy attacks. For multi-account environments, Assume Role is the only scalable and secure approach to CMDB cloud discovery.

---

Table of Contents

• The Security Risk of Static AWS Keys
• How AWS Assume Role with STS Works
• External ID: Preventing the Confused Deputy Attack
• Cross-Account Discovery: Managing Multiple AWS Accounts
• Implementation Guidance
• Conclusion

The Security Risk of Static AWS Keys for CMDB Discovery

When an IT administrator configures AWS discovery in a CMDB tool for the first time, the path of least resistance is a service account with a static Access Key ID and Secret Access Key. The key pair goes into the CMDB discovery configuration, and discovery runs with the IAM permissions attached to that user.

This approach works — but it introduces three security problems that grow more severe as the environment scales.

1. Long-Lived Credentials Are a Persistent Exposure

Static IAM user keys do not expire by default. They remain valid until explicitly rotated or revoked. If the CMDB tool’s configuration is ever exposed — through a misconfigured repository, a support ticket with screenshots, or a compromised admin account — those keys can be used by an attacker for as long as they remain valid.

AWS Security Hub and CIS AWS Foundations Benchmark both flag IAM access keys older than 90 days as a finding. In practice, CMDB integration keys often go unrotated for years.

2. Static Keys Cannot Scale Across Multiple Accounts

A single static key pair is associated with one IAM user in one AWS account. For organizations managing multiple AWS accounts (development, staging, production, audit, etc.), static keys require either a separate key pair per account — a key management problem — or centralized credentials with complex cross-account trust relationships that are harder to reason about securely.

3. Key Proliferation Multiplies Blast Radius

Every additional service that holds a copy of a static key pair expands the blast radius of a key compromise. A CMDB discovery engine, a monitoring tool, and a reporting platform all holding copies of the same key means a single credential exposure compromises all three integrations simultaneously.

How AWS Assume Role with STS Works

AWS STS (Security Token Service) generates short-lived temporary credentials when a principal assumes a role. The temporary credentials include an Access Key ID, a Secret Access Key, and a Session Token — all of which expire after a configurable duration, typically 1 to 12 hours.

The Assume Role flow for CMDB discovery works like this:

1. The CMDB discovery engine authenticates with its own identity — an IAM user or role in the discovery account.
2. The discovery engine calls sts:AssumeRole with the ARN of a target role in the account to be discovered.
3. AWS STS returns temporary credentials scoped to that target role’s permissions.
4. The discovery engine uses those temporary credentials to enumerate resources in the target account.
5. When the credentials expire, the discovery engine requests a fresh set on the next run.

The target role in the discovered account has a trust policy that allows the discovery engine’s identity to assume it. The role’s permissions policy grants only the minimum permissions needed for discovery — read-only access to describe and list API calls.

Key security benefits of Assume Role:

• Temporary credentials expire automatically, eliminating persistent exposure
• Each role assumption is logged in AWS CloudTrail with the caller identity
• Role permissions are scoped to the minimum required for discovery
• No static keys need to be distributed to the CMDB tool

External ID: Preventing the Confused Deputy Attack

When a SaaS platform (like a CMDB tool) assumes roles in customer AWS accounts, a security vulnerability can arise: if the SaaS tool is compromised or tricked, an attacker could potentially instruct it to assume a role in any account that trusts the SaaS platform’s identity — including accounts belonging to other customers.

This is the confused deputy problem. AWS defines it formally: “The confused deputy problem is a security issue where an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action.” Source: AWS IAM Documentation

The External ID condition solves this problem by requiring the caller to provide a secret value as part of the Assume Role request. The trust policy in the target role includes a condition:

"Condition": {
  "StringEquals": {
    "sts:ExternalId": "customer-unique-value"
  }
}

If the caller does not supply the correct External ID, the role assumption fails.

For CMDB tools to implement this correctly:

• The CMDB tool generates a unique External ID for each customer account
• The customer adds the External ID to their role’s trust policy condition
• When the CMDB tool calls Assume Role, it passes the External ID
• AWS validates the External ID before issuing temporary credentials

Because each customer’s External ID is different, even if the CMDB tool’s integration layer is compromised, an attacker cannot use it to assume roles in other customers’ accounts without knowing their unique External IDs. Source: NCC Group — Demystifying AssumeRole and ExternalId

Cross-Account Discovery: Managing Multiple AWS Accounts in Your CMDB

For organizations using AWS Organizations, Assume Role with External ID is the foundation of a scalable multi-account discovery architecture.

Reference Architecture

Step 1: Create a dedicated Discovery Account (or designate an existing central management account). The CMDB discovery engine authenticates with an IAM role or user in this account.

Step 2: In each target account, create a read-only Discovery Role with:

• A trust policy that allows assumption from the Discovery Account’s identity
• A condition requiring the correct External ID
• A permissions policy granting read-only API access for the services to be discovered

Step 3: Configure the CMDB discovery tool with the Discovery Account credentials and a list of target account role ARNs plus the External ID.

Step 4: The discovery engine iterates through accounts, assuming each target role in turn and enumerating resources per account and region.

IAM Permissions for the Discovery Role

The discovery role needs read-only permissions scoped to the APIs used by the discovery tool. A representative set for general CMDB discovery:

• ec2:Describe* — EC2 instances, VPCs, subnets, security groups, NAT Gateways
• s3:ListAllMyBuckets, s3:GetBucketLocation, s3:GetBucketPolicy
• lambda:ListFunctions, lambda:GetFunction
• ecr:DescribeRepositories
• rds:DescribeDBInstances
• iam:ListRoles, iam:GetRole (for IAM resource inventory)

Scoping permissions to only the APIs used by the discovery tool follows the principle of least privilege and limits the blast radius of any cloud asset discovery credential issue.

Implementation Guidance for IT Managers

For Single-Account Environments

If your organization uses a single AWS account, Assume Role is still the recommended approach over static keys. Create a read-only Discovery Role and configure your CMDB to assume it rather than using a static IAM user. This gives you CloudTrail visibility into every discovery run and eliminates long-lived credential exposure.

For Multi-Account Environments

Deploy the reference architecture described above. Use AWS CloudFormation StackSets or Terraform to create the Discovery Role consistently across all accounts — manual per-account setup does not scale. Include the External ID in the trust policy from the start. Rotating the External ID periodically (annually or after personnel changes) is a security best practice.

For CMDB Tools That Support Assume Role

When evaluating or configuring CMDB discovery tools, verify that the tool supports:

1. Assume Role (not just static key authentication)
2. External ID in the Assume Role request
3. Multi-account configuration (a list of role ARNs rather than a single account)
4. Region selection (to scope discovery to regions where resources exist)

These four capabilities are what separate a secure, enterprise-grade cloud discovery integration from a basic proof-of-concept.

Virima 6.1.1 and AWS Assume Role Support

Virima 6.1.1 added native support for AWS Assume Role with External ID in the cloud discovery configuration. IT administrators configure a Discovery Role ARN and External ID per AWS account within Virima’s discovery settings, enabling CMDB discovery across multiple accounts without distributing static credentials.

When a discovery run executes, Virima uses STS to assume the configured role in each target account, retrieves temporary credentials, enumerates resources, and releases the credentials when the run completes. The External ID is unique per Virima account, protecting against confused deputy attacks. Every Assume Role call is logged in the target account’s AWS CloudTrail, providing a full audit trail of Virima’s discovery activity.

Conclusion

Static IAM access keys for CMDB discovery carry long-lived exposure risk, cannot scale across multiple accounts securely, and create key management overhead that most IT teams never adequately address. AWS Assume Role with STS and External ID solves all three problems: temporary credentials eliminate persistent exposure, the Assume Role pattern scales across accounts, and External ID prevents confused deputy attacks.

For IT teams managing AWS environments at scale, Assume Role is the architecture that makes multi-account CMDB discovery both operationally sustainable and defensibly secure.

Ready to configure secure AWS cloud discovery for your CMDB? Schedule a demo at virima.com and see Virima’s Assume Role-based multi-account cloud discovery in action.