Aws

AWS Credentials

Learn how AWS credentials authenticate requests, how IAM users, roles, STS, and federation work, and how to manage credentials securely.

AWS credentials are information or tokens that establish the identity making a request to AWS. They let the AWS CLI, SDKs, console, and applications authenticate requests. AWS then evaluates authorization: whether that authenticated identity may perform the requested action on the specified resource.

Authentication answers “Who is making this request?” Authorization answers “What may that identity do?” Credentials alone do not grant permission. AWS evaluates them with IAM identity policies, role policies, resource policies, permissions boundaries, session policies, AWS Organizations service control policies, and other controls. An explicit deny can override an allow.

Credential types at a glance

AWS account root user credentials

The AWS account root user is the account-level identity created when an AWS account is opened. Its sign-in credentials are the account email address and password. The root user has unrestricted account-level authority and is not an ordinary IAM identity.

Routine root use is unsafe because a mistake or stolen password can affect the entire account. Do not use the root user for everyday administration, application access, or automation. Enable MFA for the root user, store recovery information securely, and eliminate root access keys. If root access keys exist, delete them unless there is a documented exceptional requirement.

Some account tasks may require root access, such as changing certain account settings, closing the account, restoring IAM permissions in unusual recovery situations, or completing tasks that AWS explicitly designates as root-only. Sign in only for that task, then sign out.

IAM users and long-term access keys

An IAM user is a long-lived identity created inside an AWS account. An IAM user can have a console password, programmatic access keys, or both. A console password is used for interactive sign-in. Programmatic access uses an access key ID and a secret access key to sign API requests.

The access key ID identifies the key. The secret access key is confidential signing material and is displayed only when the key is created. If it is lost, create a replacement rather than expecting AWS to display it again. Never place it in source code, container images, deployment manifests, logs, tickets, chat, or public repositories.

Access keys have an activation state. Administrators should create them only when necessary, deactivate them during investigation or planned suspension, rotate them when they cannot be replaced by temporary credentials, delete obsolete keys, and audit their age and last-use information. Long-term IAM user keys should be avoided whenever a role, federation, or another temporary credential source is available.

Temporary security credentials and AWS STS

Temporary security credentials are time-limited credentials issued for a session. AWS Security Token Service, commonly called AWS STS, issues them when a principal assumes a role, uses federation, or exchanges a web identity token.

A normal temporary credential set contains an access key ID, secret access key, and session token. The session token is required in addition to the two key values. Temporary credentials have an expiration time and are safer than permanent keys because their useful lifetime is limited, secret distribution is reduced, and they support federation and role assumption.

Session duration depends on the credential source, role configuration, and service limits. Applications must refresh credentials before expiration. SDK role providers normally refresh automatically; custom code that copies credentials into environment variables or configuration must implement an equivalent refresh process.

IAM roles

An IAM role is an assumable identity containing a permission set. Unlike an IAM user, a role is not normally used with a permanent password or permanent access key. A trusted principal assumes the role and receives temporary credentials.

Every role has two important policy concepts:

• Trust policy: specifies which principals may assume the role and under what conditions.
• Permissions policy: specifies the AWS actions and resources available after the role is assumed.

Common role scenarios include an AWS service calling another service, an application running on EC2, ECS, EKS, or Lambda, cross-account administration, and human access through federation. A role assumption creates a role session with its own temporary credentials, session name, and potentially source identity or session tags.

Federated access and IAM Identity Center

Federation means using an external or centralized workforce identity instead of creating a separate IAM user for every person. An identity provider authenticates the person, and AWS grants access based on the federated identity and its assigned permissions.

AWS IAM Identity Center is a common service for centrally managing workforce access to AWS accounts and applications. Administrators create permission sets, then assign users or groups to accounts with those permission sets. A permission set describes the permissions and session settings a workforce identity receives in an account.

SAML is commonly used to exchange authentication assertions with an enterprise identity provider. OpenID Connect, or OIDC, provides token-based federation and is widely used for workload identity. Web identity federation exchanges an external identity token for temporary AWS credentials through STS. In normal federation designs, users and workloads receive temporary credentials rather than permanent IAM user keys.

Credential provider chains

AWS SDKs and the AWS CLI use an ordered credential provider chain. They check possible credential sources and use the first usable source according to the tool's documented precedence. Exact details can vary by SDK and configuration, so provider precedence matters whenever several sources exist.

When debugging, first identify the active caller rather than guessing which profile was selected:

aws sts get-caller-identity

The response identifies the AWS account and ARN of the resolved identity. Also inspect the selected profile, AWS_PROFILE, and relevant environment variables. An unintended environment variable can override the profile you expected to use.

Local profiles and credential storage

An AWS profile is a named set of CLI or SDK settings. The default profile is used when no profile is selected; named profiles separate environments such as development, testing, and production.

On many systems, shared credential data is stored in a credentials file under the user's AWS configuration directory, while non-secret settings such as regions, role relationships, and SSO configuration are stored in a separate configuration file. Exact locations vary by operating system and tool configuration. These files are convenient, but they are not a complete secrets-management solution: protect file permissions, avoid copying them into images, and do not commit them to source control.

aws configure --profile development
aws configure list-profiles
aws s3 ls --profile development
aws sso login --profile workforce-admin

Use aws configure only with an approved credential source. Prefer IAM Identity Center or temporary role credentials over creating persistent local keys. Environment variables can be useful for short-lived local development, but they may be exposed to child processes, shell history, logs, crash reports, or diagnostic tools. When using temporary credentials, include all three values:

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

Use a secrets manager for application secrets such as database passwords, API tokens, or encryption material. Do not use a secrets manager as a reason to store permanent AWS access keys when the application can use an IAM role instead.

Credentials for AWS workloads

Workloads should receive temporary credentials through attached roles rather than embedded keys.

• EC2: Attach an IAM role through an instance profile. The instance metadata service makes temporary role credentials available to applications on the instance.
• ECS: Assign an ECS task role for permissions used by application containers. The separate task execution role lets the ECS agent perform tasks such as pulling images or writing logs; it is not the application container's permission set.
• EKS: Use workload identity, such as IAM roles for service accounts or the current AWS-recommended workload identity mechanisms available for the cluster. Bind permissions to the intended Kubernetes service account or workload rather than distributing node-wide keys.
• Lambda: Assign a Lambda execution role. The function receives temporary credentials for that role while it runs.

Cross-account role assumption

To access another AWS account, a caller commonly assumes a role in the target account. Both sides must permit the operation: the caller's identity policy must allow sts:AssumeRole, and the target role's trust policy must trust the caller. The role's permissions policy then controls what the assumed session can do.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ReadOnlyAudit \
  --role-session-name audit-session

STS returns temporary credentials, including a session token. A role session name helps identify activity in logs. Source identity provides a persistent identity value for traceability, while session tags can carry attributes used for auditing or attribute-based access control.

For third-party access, an external ID is a value included in the trust relationship and the assumption request. It helps address the confused-deputy problem, in which a vendor could otherwise accidentally use its authority on behalf of the wrong customer.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
    "Action": "sts:AssumeRole",
    "Condition": {"StringEquals": {"sts:ExternalId": "example-vendor-id"}}
  }]
}

Use a more narrowly scoped principal than an account principal when possible. The role also needs a separate permissions policy. For example, a narrowly scoped read permission could target only a required object prefix:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::example-private-bucket/reports/*"
  }]
}

Credential security practices

• Apply least privilege: grant only the actions and resources required for the task.
• Require MFA for privileged human access and add MFA conditions where appropriate.
• Prefer temporary credentials, federation, and workload roles over static secrets.
• Keep credentials out of source code, images, manifests, logs, tickets, chat, and public repositories.
• Use secret scanning in repositories and CI/CD systems.
• Rotate access keys when they cannot be avoided; rotation does not change permissions, so review permissions separately.
• Use short, appropriate session durations and refresh sessions before expiration.
• Use conditions such as MFA, source IP, principal tags, external IDs, and session tags when they match the access design.
• Use CloudTrail to audit API activity, IAM Access Analyzer to identify unintended access, and credential reports or equivalent account reviews to find stale or risky credentials.

Credential lifecycle

Manage credentials through a complete lifecycle: create or obtain them, distribute them through an approved channel, use them, monitor their activity, rotate or refresh them, deactivate them when necessary, and delete or replace them when no longer needed.

Credential rotation replaces a secret while usually preserving the intended access design. Permission changes are separate: an identity can keep the same credential while its policies change, or receive a replacement credential that still has excessive permissions. Review both the secret lifecycle and authorization policies.

Exposed credential response

Troubleshooting credential problems

AccessDenied

First run aws sts get-caller-identity. The active identity may not be the one expected. Then review identity policies, role permissions, resource policies, permissions boundaries, session policies, service control policies, and explicit denies. For role assumption, check the trust policy as well as the caller's sts:AssumeRole permission. CloudTrail and service-specific authorization messages can reveal the blocked policy layer.

Credentials cannot be located

Run aws configure list and aws configure list-profiles. Check AWS_PROFILE and other relevant environment variables, then confirm that the shared files are readable. For workloads, verify that the expected role is attached and that the container or instance credential endpoint is reachable. Configure an approved profile or attach the correct role; do not embed permanent keys as a quick fix.

ExpiredToken or invalid session

Temporary credentials may have expired, an IAM Identity Center session may require reauthentication, or an application may not refresh role credentials. Confirm the expiration time, reauthenticate when needed, ensure all three temporary values are present, and check the system clock. Use an SDK provider that renews role credentials rather than copying a session into permanent configuration.

Wrong account or role

Environment variables can override a profile, a default profile may be selected unintentionally, or a cached federation session may still be active. Run aws sts get-caller-identity, inspect AWS_PROFILE and the credential variables, use an explicit --profile, and check the SDK's provider precedence.

Cross-account assumption fails

Verify the caller identity, caller policy, target role ARN, target trust policy, external ID, session name, MFA requirements, and organization-level controls. Both the caller permission and target trust relationship must align.

Exam-relevant notes

• Authentication proves identity; authorization evaluates permissions.
• IAM roles have separate trust and permissions policies.
• Temporary credentials normally contain an access key ID, secret access key, and session token.
• EC2 uses an instance profile to associate a role with an instance.
• ECS task roles grant application permissions; task execution roles support ECS agent operations.
• Federation and IAM Identity Center normally produce temporary credentials.
• Provider precedence can cause an environment variable to override the profile you intended to use.
• For an exposed access key, contain it first, investigate activity, replace dependent systems, and remove exposed copies.