AWS CLI v2 AssumeRole Session Expiry Fix

The Incident (What Does the Error Mean?)

You ran a CLI command and got this:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation:
The security token included in the request is invalid.

or this variant:

An error occurred (ExpiredTokenException) when calling the AssumeRole operation:
Token included in the request is expired.

Immediate consequence: Every AWS API call authenticated via that profile is dead. If this is a deployment pipeline, your CI/CD run is blocked. If it's a production ops script, your on-call engineer cannot execute remediation commands. The credentials cache at ~/.aws/cli/cache/ or the AWS_SESSION_TOKEN env var is holding a stale token that STS is rejecting at the signature validation layer.

The Attack Vector / Blast Radius

This is not just an inconvenience — stale token handling is a security boundary failure with real blast radius:

1. Hardcoded or long-lived tokens in CI/CD env vars — When engineers "fix" this by extending MaxSessionDuration to 12 hours or exporting static AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN into environment variables, those tokens become long-lived secrets. A compromised CI runner, a leaked .env file, or a printenv in build logs exposes a fully-authenticated AWS session.

2. Cache poisoning window — The CLI cache directory (~/.aws/cli/cache/*.json) stores plaintext JSON with AccessKeyId, SecretAccessKey, and SessionToken. If an attacker has filesystem read access, they can exfiltrate a valid token before expiry. Extending TTL directly extends the exfiltration window.

3. Cascading pipeline failures — In multi-stage pipelines where stage 2 assumes a role from stage 1's token, a single expiry mid-pipeline causes all downstream stages to fail with cryptic errors, often misdiagnosed as permission errors rather than token expiry.

4. Silent failures in SDKs — Boto3 and other SDKs may silently retry and surface a generic ClientError, masking the real cause and delaying diagnosis by 20–40 minutes in a production incident.

Prevention in CI/CD

1. Checkov — Detect Hardcoded Session Tokens in IaC

Checkov rule CKV_AWS_46 flags hardcoded credentials. Add to your pipeline:

- name: Checkov IaC Scan
  run: checkov -d . --check CKV_AWS_46 --compact

2. OPA / Conftest Policy — Block Static Token Injection

# policy/no_static_session_token.rego
package main

deny[msg] {
  input.env[key]
  key == "AWS_SESSION_TOKEN"
  msg := "Static AWS_SESSION_TOKEN in pipeline env is forbidden. Use OIDC or instance role."
}

conftest test pipeline.yaml --policy policy/

3. `aws-vault` for Local Development

Replace all local ~/.aws/credentials static key usage with aws-vault, which stores credentials in the OS keychain and auto-rotates STS tokens:

brew install aws-vault
aws-vault add base-identity
aws-vault exec my-role -- aws s3 ls

4. Set a Token Expiry Monitor (CloudWatch + EventBridge)

For long-running assumed-role sessions in ECS tasks or EC2, configure a CloudWatch alarm on aws.sts GetCallerIdentity 4xx error rates. An uptick in InvalidClientTokenId errors at a predictable interval is a leading indicator of token refresh logic failure — catch it before it pages your on-call.

5. Enforce `MaxSessionDuration` via SCP

Do not set MaxSessionDuration above 4 hours without a documented justification. Use an SCP to enforce this org-wide:

{
  "Effect": "Deny",
  "Action": "iam:UpdateRole",
  "Resource": "*",
  "Condition": {
    "NumericGreaterThan": {
      "iam:MaxSessionDuration": "14400"
    }
  }
}

Longer sessions are not a fix for broken refresh logic — they are a security liability masquerading as a convenience.