Best Practices for Securely Managing Credentials with the AWS CLI

AWS CLI credentials can create, delete, and expose real cloud resources, so a leaked access key is not a small mistake. The safest setup gives humans short-lived credentials through IAM Identity Center and gives workloads temporary credentials through roles.

These best practices for securely managing credentials with the AWS CLI explain where the CLI looks for credentials, when to use profiles, and how to avoid long-lived static keys in scripts.

Understanding AWS CLI Credential Loading Order

The AWS CLI resolves credentials through a provider chain. The exact chain can vary by CLI version and configuration, but the practical order you will troubleshoot most often is:

1. Environment Variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and optionally AWS_SESSION_TOKEN.
2. Assume-role and web identity configuration: Profiles that tell the CLI to call AWS STS for temporary credentials.
3. IAM Identity Center credentials: Profiles created by aws configure sso or aws configure sso-session.
4. Shared credentials file: Usually ~/.aws/credentials.
5. Shared config file: Usually ~/.aws/config, including credential_process entries.
6. Container credentials: ECS task roles and compatible container credential endpoints.
7. EC2 instance profile credentials: Temporary credentials from the Instance Metadata Service (IMDS).

The AWS CLI does not use --access-key-id or --secret-access-key command-line flags for normal commands. If you see those in a script, it is probably confusing AWS CLI behavior with another tool or SDK.

1. Securing Credentials in Configuration Files (~/.aws/credentials)

The shared credentials file, typically ~/.aws/credentials, is convenient but should be a fallback for cases where you cannot use IAM Identity Center or roles. If you must store static keys there, protect the file and keep the permissions narrow.

File Protection and Permissions

It is vital to restrict read access to this file. On Linux/macOS systems, set permissions so only the owner can read or write the file:

chmod 600 ~/.aws/credentials

Using Profiles for Segregation

Using distinct profiles allows you to separate credentials for different environments (e.g., development, staging, production) or different accounts. This prevents accidental cross-environment actions.

Example ~/.aws/credentials:

[default]
aws_access_key_id = AKIAEXAMPLE000000000
aws_secret_access_key = exampleSecretAccessKeyDoNotUse

[production-user]
aws_access_key_id = AKIAEXAMPLE111111111
aws_secret_access_key = anotherExampleSecretDoNotUse

When using a named profile, you must specify it with the --profile flag:

aws s3 ls --profile production-user

2. Leveraging Environment Variables

Environment variables provide credentials to the current process and its child processes without editing AWS config files. They are useful for temporary sessions and CI jobs, but they can still leak through process environments, debug logs, or careless shell history.

Set the following variables in your shell session:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="temporary-session-token-if-using-sts"
export AWS_DEFAULT_REGION="us-east-1"

Important Note on Precedence: Credentials set via environment variables always override those found in the ~/.aws/credentials file, as they appear higher in the credential loading chain.

Security Warning: Be cautious when exporting environment variables, especially in shared terminals or scripts that might be logged. Always unset them immediately after use:

unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

3. Prefer IAM Roles for AWS Workloads

For workloads running on AWS infrastructure, such as EC2, Lambda, ECS, and EKS, avoid static credentials. Use IAM roles so AWS issues temporary credentials automatically.

On EC2, an instance profile exposes temporary credentials through IMDS. On ECS, task roles expose credentials through the container credential endpoint. On EKS, IAM Roles for Service Accounts use web identity tokens. The AWS CLI and SDKs know how to use these providers without storing long-lived keys on disk.

How it Works:

1. An EC2 instance is launched with an associated IAM role through an instance profile.
2. The CLI running on that instance queries the Instance Metadata Service (IMDS) for temporary credentials.
3. The CLI uses these temporary credentials for all subsequent API calls.

This eliminates the risk associated with long-lived access keys entirely.

4. Use IAM Identity Center for Human Access

For engineers using the AWS CLI from laptops, IAM Identity Center is usually safer than IAM user access keys. You sign in through a browser, choose an account and role, and the CLI uses cached short-lived credentials.

Configure it with:

aws configure sso

Then log in when your session expires:

aws sso login --profile <profile-name>

IAM Identity Center was formerly called AWS SSO, so you may still see sso in CLI commands and config keys.

5. Use credential_process for External Brokers

You can configure the CLI to call an external tool, such as a vault agent or enterprise credential broker, to fetch credentials dynamically. This is specified in ~/.aws/config:

Example ~/.aws/config:

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

This method is crucial when integrating with secrets management tools like HashiCorp Vault.

Best Practices Summary and Checklist

To maximize the security of your AWS CLI operations, adhere to these core principles:

• Principle of Least Privilege: Ensure all IAM users and roles have only the permissions strictly necessary to perform their jobs.
• Prefer Roles over Keys: Always use IAM Roles (Instance Profiles) when operating within AWS infrastructure.
• Use IAM Identity Center: For human interactive use, use IAM Identity Center to manage access to multiple accounts.
• Never Hardcode Keys: Avoid putting Access Keys directly into scripts, source code, or command history.
• Protect Credentials File: Restrict filesystem permissions (chmod 600) on ~/.aws/credentials.
• Rotate Keys Regularly: If static keys must be used, enforce a strict rotation schedule.

Your default should be temporary credentials: IAM Identity Center for people, IAM roles for workloads, and credential_process for brokered enterprise access. Use static access keys only when there is no better option, then scope them tightly, rotate them, and remove them as soon as the dependency is gone.