AWS Assume Role for CMDB Discovery: The Security Case for Temporary Credentials

The Security Risk of Static AWS Keys for CMDB Discovery

When you configure 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. However, it introduces three security problems that grow more serious as your environment scales.

1. Long-Lived Credentials Are a Persistent Exposure

Static IAM user keys do not expire by default. They stay valid until you explicitly rotate or revoke them. If your CMDB tool’s configuration is ever exposed, through a misconfigured repository, a support ticket screenshot, or a compromised admin account, an attacker can use those keys for as long as they remain valid.

AWS Security Hub and the CIS AWS Foundations Benchmark both flag IAM access keys older than 90 days as a finding. Without an active key rotation policy, this gap commonly extends well beyond that 90-day benchmark in practice.

2. Static Keys Cannot Scale Across Multiple Accounts

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

3. Key Proliferation Multiplies Exposure Scope

Every additional service that holds a copy of a static key pair expands the exposure scope of a key compromise. When a CMDB discovery engine, a monitoring tool, and a reporting platform all hold copies of the same key, a single credential exposure compromises all three integrations at once.

How AWS Assume Role with STS Works

AWS STS (Security Token Service) generates short-lived credentials when a principal assumes a role. These 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.

Here is how the AWS Assume Role CMDB discovery flow works in practice:

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 short-lived credentials scoped to that target role’s permissions.
4. The discovery engine uses those 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:

• Short-lived credentials expire automatically, removing persistent exposure from your configuration
• 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

Ready to see how Virima handles Assume Role-based discovery across multiple AWS accounts? Schedule a demo to see it in action.

External ID: Preventing the Confused Deputy Attack

When a SaaS platform (like a CMDB tool) assumes roles in customer AWS accounts, a specific vulnerability can arise. If the SaaS tool is compromised or tricked, an attacker could 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 directly: “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 like this:

“Condition”: {

  “StringEquals”: {

    “sts: ExternalId”: “customer-unique-value.”

If the caller does not supply the correct External ID, the role assumption fails. For CMDB tools, the correct implementation works like this:

• 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 short-lived 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 organisations using AWS Organizations, Assume Role with External ID is the foundation of a multi-account discovery architecture. You configure a central discovery account, then establish trust relationships to each target account, each with its own role, scoped permissions, and an External ID condition.

This architecture means you never distribute static credentials to each account. Instead, you maintain one discovery identity and let the trust relationships handle access control. For the full multi-account setup walkthrough, see our companion guide: AWS and Azure CMDB Discovery: Cloud Asset Visibility Guide.

Extending the Pattern Beyond AWS

Most enterprises that run AWS at scale also run Azure subscriptions in parallel. Assume Role is AWS’s specific mechanism for secure cross-account access. However, the underlying principle, short-lived, scoped, auditable credentials instead of static keys, applies equally to Azure’s service principals and managed identities.

When the goal shifts from “discover one AWS account” to “build a single source of truth across every cloud your business runs,” your architecture must account for both providers’ authentication models, region structures, and resource hierarchies in one discovery configuration. Virima’s Azure Discovery for CMDB and Service Mapping integration page covers how AWS and Azure asset visibility come together inside a single CMDB, including how service principal authentication on the Azure side feeds the same dependency map as Assume Role on the AWS side.

Reference Architecture for Multi-Account AWS Assume Role CMDB Discovery

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, a list of target account role ARNs, and the External ID for each account.

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 your discovery tool uses. 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: Describe Repositories
• rds: DescribeDBInstances
• iam: ListRoles, iam: GetRole (for IAM resource inventory)

Scoping permissions to only the APIs your discovery tool actually uses follows the principle of least privilege. It also limits the exposure scope of any discovery credential issue. For more on what Virima discovers across modern cloud services, including Kubernetes, Lambda, and PaaS, see Virima Cloud Discovery Coverage.

Implementation Guidance for IT Managers

For Single-Account Environments

If your organisation 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 removes long-lived credential exposure from your configuration.

For Multi-Account Environments

Deploy the reference architecture 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) adds an additional layer of protection.

For CMDB Tools That Support Assume Role

When you evaluate or configure CMDB discovery tools, verify that the tool supports all four of these capabilities:

• Assume Role (not just static key authentication)
• External ID in the Assume Role request
• Multi-account configuration (a list of role ARNs, not just a single account)
• Region selection (to scope discovery to regions where your resources actually exist)

These four capabilities separate a secure, enterprise-grade cloud discovery integration from a basic proof-of-concept. For a side-by-side look at how tools differ on AWS discovery, see Device42 AWS Discovery: Features, Process, and Alternative.

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, which enables 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 short-lived credentials, enumerates resources, and releases the credentials when the run completes. The External ID is unique per Virima account, which protects against confused deputy attacks. Every Assume Role call is logged in the target account’s AWS CloudTrail, so you have a full audit trail of every action Virima takes during discovery.

For teams managing cloud assets across both AWS and Azure, Virima also supports auto-import of AWS, Azure, and Intune assets into your CMDB, with discovery scheduling, import log monitoring, and CI lifecycle management built in.

Why Assume Role Is the Architecture That Makes Cloud Discovery Secure at Scale

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 fully address. AWS Assume Role with STS and External ID solves all three problems: short-lived credentials remove persistent exposure, the Assume Role pattern scales across accounts without distributing static keys, and External ID prevents confused deputy attacks at the SaaS layer.

For IT teams managing AWS environments across multiple accounts, AWS Assume Role CMDB discovery is the architecture that makes cloud discovery both operationally sustainable and defensibly secure. The steps are straightforward: a read-only Discovery Role, a trust policy with External ID, and a CMDB tool that supports multi-account Assume Role configuration.

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