Skip to main content

Ambient Credential Support for IRSA, IMDS, and ECS Task Roles

· 4 min read
Erik Osterman
Erik Osterman
Founder @ Cloud Posse

Atmos now supports ambient AWS credentials from IRSA, EC2 instance profiles, and ECS task roles via two new identity kinds: ambient (generic passthrough) and aws/ambient (AWS SDK default credential chain).

What's New​

Two new identity kinds make it possible to run Atmos natively in environments where credentials are already available:

  • ambient — A cloud-agnostic passthrough that preserves all environment variables as-is. No credential clearing, no IMDS disabling, no file overrides. Use this when you just want Atmos to leave the environment alone.

  • aws/ambient — An AWS-specific identity that resolves credentials through the AWS SDK's default credential provider chain. This supports environment variables, shared config files, IRSA web identity tokens, EC2 instance metadata (IMDS), and ECS container credentials. Unlike ambient, it returns real AWS credentials that can be used by chained identities like aws/assume-role.

Quick Start​

EKS Pod with IRSA​

# atmos.yaml
auth:
  identities:
    eks-deployer:
      kind: aws/ambient
      principal:
        region: us-east-1

That's it. The pod's IRSA-injected AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN environment variables are preserved and used by the AWS SDK when Terraform runs.

EC2 Instance Profile​

# atmos.yaml
auth:
  identities:
    instance-creds:
      kind: aws/ambient

The EC2 instance metadata service (IMDS) provides credentials automatically. No region needed if it's set elsewhere.

Simple Passthrough​

# atmos.yaml
auth:
  identities:
    passthrough:
      kind: ambient

Use this when credentials are pre-configured in the environment and you just want Atmos to pass them through without any modification.

Why This Matters​

Previously, Atmos auth explicitly disabled IMDS and cleared IRSA environment variables to prevent accidental credential leakage. This was the right default for developer workstations and interactive SSO flows, but it made it impossible to use infrastructure-provided credentials in:

  • EKS pods using IAM Roles for Service Accounts (IRSA)
  • EC2 instances with IAM instance profiles
  • ECS tasks with task roles
  • CI runners with pre-configured AWS credentials

Teams in these environments had to either bypass Atmos auth entirely (losing identity management, integrations, and audit trail) or maintain parallel credential management.

Chaining with Assume Role​

A common pattern in multi-account environments: use the pod's IRSA credentials to assume a role in another account.

# atmos.yaml
auth:
  identities:
    # Base: use the pod's IRSA credentials
    pod-base:
      kind: aws/ambient
      principal:
        region: us-east-1

    # Chain: assume a cross-account role using IRSA as the base
    cross-account-deployer:
      kind: aws/assume-role
      via:
        identity: pod-base
      principal:
        assume_role: "arn:aws:iam::999999999999:role/TerraformDeployRole"

The aws/ambient identity resolves the IRSA credentials, then aws/assume-role uses them to call sts:AssumeRole into the target account.

How It Works​

Every other AWS identity kind in Atmos calls a shared PrepareEnvironment() helper that:

  1. Clears credential env vars (AWS_ACCESS_KEY_ID, AWS_WEB_IDENTITY_TOKEN_FILE, etc.)
  2. Sets AWS_EC2_METADATA_DISABLED=true
  3. Points AWS_SHARED_CREDENTIALS_FILE and AWS_PROFILE to Atmos-managed files

The aws/ambient identity skips all of this. It creates a copy of the environment and returns it with only an optional region override. This allows the AWS SDK's full default credential chain to work naturally.

The ambient identity is even simpler — it returns the environment completely unchanged.

When to Use Each​

Identity KindUse When
aws/ambientRunning on AWS infrastructure (EKS/EC2/ECS) where you need chaining support
ambientAny environment where credentials are pre-configured and you want zero interference
aws/assume-role via SSODeveloper workstations, interactive flows
aws/assume-role via GitHub OIDCGitHub Actions CI/CD

Get Started​