Managing Dynamic AWS Secrets with HashiCorp Vault

Why Static Credentials Fail

Hardcoded AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY key pairs represent a persistent vulnerability in cloud infrastructure. Even when stored securely, long-lived credentials remain exposed to potential leaks or unauthorized exposure.

HashiCorp Vault's AWS secrets engine addresses this risk by generating ephemeral credentials on demand that expire automatically according to a configurable Time-To-Live (TTL).

Configuration via CLI

Configure Vault with the necessary permissions to manage IAM resources, then establish a role that issues temporary credentials:

# 1. Enable the AWS secrets engine
vault secrets enable -path=aws aws
# 2. Configure root credentials Vault will use with AWS
# Note: On EKS, use IRSA (IAM Roles for Service Accounts) to avoid static keys here.
vault write aws/config/root \
 access_key=$VAULT_AWS_ACCESS_KEY \
 secret_key=$VAULT_AWS_SECRET_KEY \
 region=us-east-1
# 3. Create a Vault role mapped to an IAM policy
vault write aws/roles/s3-readonly \
 credential_type=iam_user \
 policy_document=- <<EOF
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:GetObject",
 "s3:ListBucket"
 ],
 "Resource": "*"
 }
 ]
}
EOF

Provisioning Ephemeral Credentials

Applications authenticate to Vault (for example, utilizing Kubernetes service account tokens) and request temporary AWS access keys directly from the role path:

$ vault read aws/creds/s3-readonly
Key Value
--- -----
lease_id aws/creds/s3-readonly/f8a...
lease_duration 1h
access_key AKIA...
secret_key wJalr...
security_token 

Vault dynamically creates an IAM user within AWS, attaches the specified policy, and returns short-lived API keys. Once the lease duration expires (1 hour in this example), Vault automatically removes the temporary IAM user.