Vault AWS Secrets Engine: Issuing Temporary IAM Credentials for Production and Exams

The modern best practice is to stop using long-lived AWS access keys and instead dynamically issue STS credentials from Vault.

This article targets the Associate / Ops level exam while summarizing the practical know-how you need to get this running correctly with minimal friction.

Core Concepts and Key Exam Points

Vault's AWS secrets engine calls the AWS APIs (STS, IAM) to generate credentials dynamically. The most production-friendly option is assumed_role, which assumes an existing IAM role via STS AssumeRole.

Temporary credentials issued by Vault carry a lease and expire automatically once the TTL is exceeded. Since the AWS-side session is bounded by the role's MaxSessionDuration, Vault's TTL must always stay at or below the AWS-side limit.

Common exam topics include the difference from static secrets, how TTL/leases work, when to use assumed_role vs iam_user, and least-privilege design.

• Dynamic issuance: a fresh credential is generated on every read
• Lease management: Vault tracks TTL and revocation
• Prefer assumed_role: no long-lived keys; everything goes through STS
• Set TTL at or below the AWS role's MaxSessionDuration
• Early revocation: STS sessions generally can't be invalidated immediately (wait for expiry)

Conceptual flow between Vault and AWS STS

Choosing Between assumed_role and Other Methods (with Comparison Table)

In production, assumed_role is essentially the only choice. You don't hold long-lived keys, and issuance/revocation are contained within a session. Use iam_user only as an exception when external requirements specifically demand an access-key form. federation_token works for granting short-term, constrained access, but if you already have a role design in place, assumed_role is simpler.

• Default: prefer assumed_role (STS)
• Exception: use iam_user when legacy compatibility is mandatory
• Short-term, scoped access: attach a policy via federation_token for brief use

Least-Privilege IAM Design (Permissions Vault Needs)

Vault calls the AWS APIs with the credentials configured at aws/config/root. With assumed_role, the minimum setup is to grant Vault only sts:AssumeRole and to allow Vault's execution principal (an IAM user/role) in the target role's trust policy.

If you use iam_user, you additionally need iam:CreateUser, iam:CreateAccessKey, iam:DeleteAccessKey, and so on. Both in practice and on the exam, the key principle is to avoid including any unnecessary permissions.

• Vault's principal → only sts:AssumeRole (when using assumed_role only)
• Explicitly list Vault's principal in the target role's trust policy
• If you also use iam_user, add the IAM permissions and scope them with paths/tags

Example IAM policy for Vault (allowing only assumed_role)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeSpecificRoles",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::111122223333:role/ProdAppReadOnly",
        "arn:aws:iam::111122223333:role/ProdAppRW"
      ]
    }
  ]
}

-- Target role trust policy (excerpt) --
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/VaultRunner" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Setup Steps (Fastest Path to a Working Config)

Below is a minimal example using assumed_role. First, enable the AWS secrets engine in Vault and configure the AWS execution credentials in the root settings. Then create a Vault role that binds to the target IAM role you want to assume.

Specify default_sts_ttl and max_sts_ttl explicitly, keeping them at or below the AWS role's MaxSessionDuration. After issuance you can track the credential via lease_id.

• Configure aws/config/root with a least-privilege principal
• Specify role_arn and TTL explicitly on each Vault role
• Verify issuance, renewal, and revocation behavior with tests

Vault CLI (issuing credentials with a 30-minute TTL via assumed_role)

# 1) Enable the AWS Secrets Engine
vault secrets enable aws

# 2) Configure execution credentials (adjust region etc. for your environment)
vault write aws/config/root \
  access_key="AKIA..." \
  secret_key="<REDACTED>" \
  region="ap-northeast-1"

# 3) Create a Vault role (assumes the target IAM role)
vault write aws/roles/app-readonly \
  credential_type=assumed_role \
  role_arn="arn:aws:iam::111122223333:role/ProdAppReadOnly" \
  default_sts_ttl="30m" \
  max_sts_ttl="1h"

# 4) Issue temporary credentials
vault read aws/creds/app-readonly
#=> returns access_key, secret_key, security_token, lease_id, lease_duration, etc.

# 5) Renew the lease (cannot exceed the AWS role's MaxSessionDuration)
vault lease renew <lease_id>

# 6) Revoke (assumed_role can't be invalidated immediately; only stops future issuance)
vault lease revoke <lease_id>

Understanding Leases, TTL, and Revocation Correctly

Vault attaches a lease to issued credentials and automatically marks them expired once the TTL is exceeded. With assumed_role, the AWS-side session follows the DurationSeconds set at issuance, and early cancellation is generally not possible. Vault's revoke is an administrative expiration — saying that secret will no longer be distributed — and does not immediately invalidate an already-issued STS session.

With iam_user, you can invalidate immediately via DeleteAccessKey. Consider iam_user only when there's a strong requirement for immediate revocation.

• The TTL ceiling follows the AWS role's MaxSessionDuration
• Vault's renew only succeeds within the AWS-side limit
• Early invalidation of assumed_role isn't possible (design around shorter TTLs and frequent issuance)
• If immediate revocation is a hard requirement, use iam_user (with the added operational cost)

Operational Pitfalls and Exam Prep Checklist

Typical operational pitfalls include TTL/MaxSessionDuration mismatches, missing entries in the target role's trust policy, and misconfigured regions or endpoints. On the exam, you're most likely to be tested on assumed_role being the recommended option, Vault not being able to exceed the STS-side cap, and the boundary between static and dynamic key management.

• Keep TTL at or below the AWS role's limit; STS errors out if you exceed it
• Don't forget Vault's principal in the trust policy
• Use a least-privilege credential at aws/config/root and enable audit logging
• For multi-account setups, prepare a role per account and span them via Assume
• Error handling: design retries for STS rate limits and transient failures
• Exam keywords: dynamic secrets, leases, TTL, assumed_role, least privilege

Test Yourself

Frequently Asked Questions