Internal

AWS Credentials: Authentication Methods, Configuration, and Security

Learn how AWS credentials authenticate users and workloads, configure the AWS CLI safely, use IAM roles and federation, audit access, and respond to exposed keys.

AWS credentials are authentication material used to prove an identity to AWS. They allow the AWS CLI, SDKs, and applications to sign requests or establish an authenticated session. Authentication answers who is making the request; authorization answers what that identity is allowed to do.

A credential can identify a principal such as the root user, an IAM user, an IAM role, a federated user, or a workload identity. IAM policies then determine whether that principal may perform an action on a resource. Possessing valid credentials does not automatically grant permission to use every AWS service.

Credential Types in AWS

Long-term access keys

A long-term programmatic access key contains an access key ID and a secret access key. The access key ID is an identifier; the secret access key is confidential signing material. Long-term keys remain valid until they are disabled, deleted, or otherwise restricted.

They may still be required for a carefully controlled legacy integration or a user-independent system that cannot use federation. They should not be the default for people or AWS-hosted workloads because a leaked key can remain usable for a long time.

Temporary security credentials

Temporary security credentials contain three values: an access key ID, a secret access key, and a session token. The session token is required in addition to the two key values. These credentials have an expiration time and are commonly issued by AWS Security Token Service (STS) when a principal assumes an IAM role.

Temporary credentials reduce the damage window of exposure and support automatic rotation. Applications must use a credential provider that can refresh them before expiration.

Interactive sign-in methods

A console password and multi-factor authentication (MFA) support interactive sign-in. They are not substitutes for programmatic access keys. Human users commonly authenticate through AWS IAM Identity Center or an external identity provider and then receive short-lived AWS role credentials.

IAM Users, Roles, and Federation

IAM users

An IAM user is an AWS identity historically used for an individual or a program. An IAM user may have a console password, access keys, or both. Shared IAM users make accountability difficult, and long-term user keys are easy to copy. For these reasons, IAM users should not be the default method for human access.

They may remain appropriate for a narrow compatibility requirement, but each user and key should have an owner, limited permissions, a documented purpose, and a rotation or retirement plan.

IAM roles

An IAM role is an assumable identity. It normally does not have a permanent password or permanent access key. When a trusted principal assumes the role, STS returns temporary security credentials.

A role has two important policy concepts:

• Trust policy: identifies principals that may assume the role and can impose conditions such as MFA, an external ID, or specific identity claims.
• Permissions policy: specifies the actions and resources available after the role is assumed.

Role assumption commonly occurs when a user selects a permission set, when one AWS account accesses another account, or when an AWS service acts for an application. In a cross-account flow, the source principal needs permission to call sts:AssumeRole, and the target role trust policy must trust that source principal.

Federation and IAM Identity Center

Federation connects an external identity system to AWS. AWS IAM Identity Center provides workforce single sign-on and assigns users or groups permission sets in one or more accounts. An external identity provider can also issue a trusted token that AWS exchanges for role credentials.

Federation gives people individual identity, centralized access removal, and short-lived sessions without distributing IAM user keys.

Long-Term Versus Temporary Credentials

Prefer temporary credentials wherever the environment supports them. Expiration is not a complete security control: an exposed session may still be abused until it expires or is otherwise contained. Do not omit the session token when configuring temporary credentials.

Credential Provider Chains

A credential provider chain is the ordered set of sources an AWS SDK or tool checks for usable credentials. Common sources include explicit application configuration, environment variables, shared credentials files, shared configuration files, IAM Identity Center profiles, web identity token files, container credentials, and EC2 instance metadata.

Exact precedence differs by SDK, language, and version. Consult the documentation for the tool in use. Conflicting sources are a common cause of unexpected identity selection: for example, an old environment variable can override the profile you intended to use.

AWS CLI Configuration

The AWS CLI commonly uses two files. The shared credentials file stores profile credentials, while the shared configuration file stores regions, output formats, SSO settings, and role-assumption settings. Their usual locations are ~/.aws/credentials and ~/.aws/config, although environment variables and CLI options can change the locations.

The default profile is used when no other profile is selected. A named profile is a labeled configuration entry such as development or workforce.

aws configure --profile development
aws s3 ls --profile development
aws sts get-caller-identity --profile development

For one shell session, select a profile with an environment variable:

export AWS_PROFILE=development
aws sts get-caller-identity

IAM Identity Center profiles use workforce authentication instead of a static IAM user key:

aws configure sso --profile workforce
aws sso login --profile workforce
aws sts get-caller-identity --profile workforce

A role-based profile can use a source profile to obtain a role session. The source identity and target role must be authorized separately.

[profile production-deploy]
role_arn = arn:aws:iam::123456789012:role/DeploymentRole
source_profile = workforce
region = us-east-1

Before an administrative or deployment command, verify the active account and principal:

aws sts get-caller-identity

Do not print secret values while diagnosing configuration. Review profile names, file paths, regions, and non-secret settings instead.

Environment Variables

Common AWS variables include:

• AWS_ACCESS_KEY_ID: access key ID.
• AWS_SECRET_ACCESS_KEY: secret access key.
• AWS_SESSION_TOKEN: required for temporary credentials.
• AWS_REGION or AWS_DEFAULT_REGION: default region selection.
• AWS_PROFILE: named profile selection.

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."
export AWS_REGION="us-east-1"

Environment variables are useful for local experiments and controlled CI jobs, especially when a secret manager injects values at runtime. They can also leak through shell history, process inspection, debug output, logs, crash reports, and inheritance by child processes. Prefer federation, role credentials, or secret-management integrations over hardcoding values or placing them in scripts.

Credentials for AWS Compute Workloads

An ECS task role grants permissions to application containers. An ECS task execution role grants the ECS agent permissions needed to start the task, such as pulling images or writing logs. These roles serve different purposes.

Applications running on AWS should use the runtime's credential provider and obtain temporary role credentials automatically. They should not contain access keys.

CI/CD and External Workloads

OpenID Connect (OIDC) federation allows a CI system to present a signed identity token to AWS. STS validates the token and issues temporary credentials for an IAM role. This avoids storing a permanent AWS access key as a repository secret.

The role trust policy should restrict the trusted OIDC provider and claims such as repository, branch, project, environment, or workflow. Grant separate roles for deployment, read-only inspection, and administration, and apply least privilege to each role.

Compared with a static CI key, OIDC provides shorter sessions, identity claims, centralized revocation, and less secret distribution. A broad trust policy or broad role permissions can still create serious risk, so both must be scoped.

Secure Credential Handling

• Never place secrets in source code, client-side applications, public repositories, container images, templates, or plaintext shared documents.
• Use least privilege: grant only the actions and resources needed for a task.
• Separate development, test, and production identities and accounts where appropriate.
• Prefer short-lived sessions and refresh-capable providers.
• Protect the root user, avoid root access keys, and enable MFA for privileged access.
• Store a secret that is genuinely required in a managed service such as AWS Secrets Manager or Systems Manager Parameter Store.
• Use secret scanning, repository protection, build-artifact controls, and careful logging.
• Remove unused IAM users, keys, profiles, roles, and cross-account trust relationships.

Rotation, Revocation, and Incident Response

For a long-term key that must remain in use, create a replacement before disabling the old key. Update applications, CI variables, deployment systems, and secret stores; validate the replacement; then deactivate and eventually delete the old key. This avoids downtime while limiting the overlap period.

If a key is exposed, treat it as compromised:

1. Identify the IAM user and access key.
2. Deactivate the exposed key promptly, or apply the appropriate containment action for the credential type.
3. Review CloudTrail and related monitoring data for use of the principal.
4. Replace the key in every dependent application, CI system, and secret store.
5. Remove the secret from repositories, artifacts, logs, and distribution channels, understanding that history may retain copies.
6. Investigate unauthorized activity and correct the process that allowed exposure.
7. Migrate the system to a role or federated temporary credentials where possible.

Changing permissions alone does not necessarily invalidate already-issued temporary sessions in every context. Use the applicable AWS containment and revocation controls, disable exposed long-term keys, restrict role trust or permissions when necessary, and investigate active sessions.

Inspecting and Auditing Credentials

Use STS to identify the current caller:

aws sts get-caller-identity

For an IAM user, inspect access key status and last-used information where applicable:

aws iam list-access-keys --user-name example-user

Credential reports help review account-wide IAM user credential state. IAM Access Analyzer identifies unintended access and risky trust relationships. CloudTrail records API activity that can connect actions to a principal, while security monitoring services can identify suspicious behavior, exposed keys, and unusual access.

Service control policies (SCPs) in AWS Organizations are account-level guardrails. They complement identity and resource policies; an SCP does not grant permissions, and an identity having an Allow does not bypass an applicable SCP Deny.

Common Security Anti-Patterns

• Using root access keys for ordinary work.
• Giving administrator permissions to routine applications or deployment jobs.
• Sharing one IAM user or static key across people or systems.
• Embedding keys in application code, images, templates, or build output.
• Using long-lived CI keys when OIDC-based temporary credentials are available.
• Leaving unused users, keys, profiles, roles, or cross-account trust relationships active.

Troubleshooting AWS Credential Problems

Credentials cannot be found

Check that a profile or supported environment source exists, that the intended profile is selected, and that an AWS-hosted application has its expected role. Inspect credential and configuration files without exposing secret values. Confirm the identity with the intended profile:

aws sts get-caller-identity --profile development

Correct malformed or inaccessible files, then use IAM Identity Center or an IAM role when appropriate.

Expired token

Temporary credentials or an IAM Identity Center session may have expired, or a process may have cached old values. Re-authenticate the profile, refresh the provider, and restart or reconfigure the process if it does not reload credentials.

AccessDenied

Credentials may be valid but belong to the wrong principal, or a policy may deny the action. Confirm the caller identity and account, then review identity policies, resource policies, permissions boundaries, session policies, SCPs, and explicit denies. CloudTrail and IAM policy simulation can help locate the governing decision.

Cross-account role assumption fails

Review both sides: the source identity needs permission for sts:AssumeRole, and the target role trust policy must trust the source principal. Check the role ARN and requirements such as an external ID, MFA, principal tags, or OIDC claims.

A key was exposed

Identify the key, deactivate it immediately, review its use in CloudTrail, replace all dependencies, remove copies from distribution channels, and migrate to temporary credentials. Test the replacement with STS before running production commands.

Practical Credential Selection Guide

• Human local development: use IAM Identity Center and a named profile.
• Local legacy integration: use a narrowly permitted key only when role or federation support is unavailable, and rotate it.
• EC2, ECS, Lambda, or EKS: use the runtime's IAM role or workload identity mechanism.
• CI/CD: use OIDC federation and a narrowly scoped deployment role.
• Cross-account administration: authenticate to a source identity and assume a target role with a constrained trust policy.
• Application secret such as a database password: store it in an appropriate managed secret or parameter service; do not confuse that secret with AWS API credentials.

Key Takeaways

• Credentials authenticate a principal; IAM policies authorize actions.
• Temporary role credentials are generally safer than long-term access keys.
• Temporary credentials require the session token and must be refreshed.
• Use profiles and STS identity checks to prevent commands from running as the wrong principal.
• Use workload roles, IAM Identity Center, and OIDC instead of embedding static keys.
• Least privilege, MFA, monitoring, rotation, and prompt revocation are complementary controls.

Continue with AWS credentials configuration and security review when you need to apply these patterns to a specific environment.