Vault Dynamic AWS Credentials: Short-Lived IAM Keys (2026)

Vault’s dynamic AWS credentials feature allows applications to obtain IAM credentials on demand, reducing the need to embed static keys in code or configuration.

Let’s see this in action. Imagine an application running on EC2 that needs to read from an S3 bucket. Instead of pre-configuring an IAM user with access keys and storing them in the EC2 instance’s user data or a secret manager, we can use Vault.

First, we configure Vault to act as an IAM principal. This involves telling Vault its own AWS access key and secret key (which it will use to create other IAM entities) and the AWS region it’s operating in.

# vault write auth/aws/config \
#     access_key="YOUR_VAULT_IAM_ACCESS_KEY" \
#     secret_key="YOUR_VAULT_IAM_SECRET_KEY" \
#     region="us-east-1"

Next, we define a "role" in Vault that maps to a specific IAM policy and an IAM role that Vault will create. This role in Vault dictates what permissions the dynamically generated credentials will have.

# vault write auth/aws/role/s3-reader \
#     credential_type="iam_user" \
#     policy_document='{
#         "Version": "2012-10-17",
#         "Statement": [
#             {
#                 "Effect": "Allow",
#                 "Action": [
#                     "s3:ListBucket",
#                     "s3:GetObject"
#                 ],
#                 "Resource": [
#                     "arn:aws:s3:::my-app-bucket",
#                     "arn:aws:s3:::my-app-bucket/*"
#                 ]
#             }
#         ]
#     }' \
#     iam_role_arn="arn:aws:iam::123456789012:role/vault-dynamic-aws-role-s3-reader" \
#     iam_user_max_ttl="1h" \
#     iam_user_ttl="30m"

In this configuration:

• credential_type="iam_user": We’re instructing Vault to create an IAM user.
• policy_document: This is the IAM policy that will be attached to the generated IAM user. It grants s3:ListBucket and s3:GetObject permissions on my-app-bucket.
• iam_role_arn: This is the ARN of an existing IAM role that Vault will assume to perform actions in AWS (like creating IAM users/roles, attaching policies). This role needs permissions like iam:CreateUser, iam:AttachUserPolicy, iam:CreateAccessKey, iam:DeleteUser, iam:DeleteAccessKey, etc.
• iam_user_max_ttl: The maximum time an IAM user generated by this role can exist.
• iam_user_ttl: The default time-to-live for an IAM user generated by this role.

Now, an application (or any client authenticated to Vault) can request temporary AWS credentials. The client needs to authenticate to Vault first, for example, using its EC2 instance identity.

# Example using Vault CLI (assuming client is authenticated to Vault)
# vault read auth/aws/creds/s3-reader

This command triggers Vault. Vault uses its own configured AWS credentials to:

1. Create a new IAM user in AWS.
2. Attach the specified policy_document to this new IAM user.
3. Create an IAM access key and secret key for this new user.
4. Return these temporary AWS access key ID and secret access key to the client.

The client then uses these temporary credentials to interact with AWS. When the TTL expires, the credentials become invalid. Vault also periodically cleans up these short-lived IAM users.

The core problem this solves is the lifecycle management of sensitive credentials. Instead of static, long-lived keys that are a prime target for compromise, you get short-lived, automatically rotated credentials that are generated only when needed and expire quickly. This significantly reduces the attack surface. The IAM role ARN specified in the Vault role (iam_role_arn) is a crucial piece; it’s the identity Vault uses to act in your AWS account, and it needs broad permissions to manage IAM entities.

The most surprising thing about Vault’s dynamic secrets for AWS is that it doesn’t just generate IAM users; it can also generate temporary IAM role credentials. When you configure a Vault role with credential_type="iam_role", Vault will assume the specified iam_role_arn and then use AWS STS’s AssumeRole API to generate temporary credentials that assume that same role. This means your application can directly assume a specific IAM role without Vault needing permissions to create IAM users or access keys.

The next concept you’ll likely explore is how to automate the Vault client authentication process, often using the EC2 auth method or other identity-based authentication mechanisms, so that applications can obtain credentials without manual intervention.