AWS IAM Advanced: Roles, Policies, STS

An IAM role is an AWS identity with permission policies that determine what the role can do, but it is not uniquely associated with one person or service. Instead, trusted entities — such as IAM users, AWS services (EC2, Lambda), or users from another AWS account — assume the role to obtain temporary security credentials. Roles eliminate the need to share or embed long-term access keys. They are the foundation of secure credential management in AWS.

When an entity assumes a role, the following occurs:

1. The entity calls the AWS STS AssumeRole API (or AssumeRoleWithWebIdentity, AssumeRoleWithSAML, etc.). 2. AWS STS validates that the entity has permission to assume the role (checked via the entity's IAM policy and the role's trust policy). 3. STS generates a temporary security credential set consisting of: - Access Key ID (string) - Secret Access Key (string) - Session Token (string) - Expiration (timestamp, default 1 hour, max 12 hours for most roles) 4. These credentials are returned to the entity, which can then use them to make AWS API calls. The credentials are valid until the expiration time.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
    "Action": "sts:AssumeRole"
  }]
}

When a request is made using temporary credentials, AWS evaluates all applicable policies:

The decision is based on an explicit deny override: if any policy explicitly denies the action, the request is denied. If no policy explicitly allows and no explicit deny, the request is denied by default (implicit deny).

An EC2 instance can assume a role by launching it with an IAM instance profile. The instance profile is a container for a role. AWS automatically rotates the temporary credentials inside the instance via the instance metadata service (IMDS). The instance retrieves credentials from http://169.254.169.254/latest/meta-data/iam/security-credentials/rolename. These credentials are automatically renewed before expiration.

To grant access to resources in Account A from Account B:

These are predefined roles linked directly to an AWS service. The service defines the trust policy and permissions. You cannot modify them, but you can create and delete them as needed. Example: Amazon Redshift uses a service-linked role to access S3 for data loading.

To allow a user to pass a role to an AWS service (e.g., when launching an EC2 instance with a role), the user must have iam:PassRole permission on that role. This prevents privilege escalation.

You can assume a role, then use the resulting temporary credentials to assume another role. This is called role chaining. However, the maximum chain depth is limited by AWS (usually not recommended due to complexity and security concerns).

When assuming a role, you can pass session tags that are propagated to the role's session. These tags can be used in attribute-based access control (ABAC). The role's trust policy must allow sts:TagSession for the principal to pass tags.

Use AWS CLI to test role assumption:

aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/MyRole" --role-session-name "TestSession"

Output:

{
    "Credentials": {
        "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEH...",
        "Expiration": "2025-03-20T12:00:00Z"
    }
}

To use these credentials, set environment variables:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=FwoGZXIvYXdzEH...

When a service assumes a role on behalf of a user, another service could trick it into accessing resources. To prevent this, use the aws:SourceArn condition key in the trust policy to restrict which resource can assume the role.

If a role has a permissions policy allowing s3:GetObject on bucket1/*, and the bucket has a resource-based policy denying s3:GetObject for that role, the request is denied (explicit deny overrides allow).

A large enterprise has multiple AWS accounts (Dev, Test, Prod) and a central logging account. They want EC2 instances in each account to send logs to an S3 bucket in the logging account. Solution: In the logging account, create an IAM role with a trust policy that allows the root user of each member account to assume it. Attach a permissions policy granting s3:PutObject on the central bucket. In each member account, create an IAM instance profile using that role. Launch EC2 instances with the instance profile. The instances automatically assume the cross-account role via STS and write logs. This avoids embedding keys and centralizes control. Common misconfiguration: forgetting to update the trust policy when adding a new account, leading to access denied errors. Performance: STS calls are low-latency; credentials are cached by the instance metadata service and renewed automatically, so no performance impact.

A company uses Okta for identity management. They want to grant temporary access to AWS resources (e.g., a specific S3 bucket) to external contractors. Solution: Create an IAM role with a trust policy that allows sts:AssumeRoleWithSAML from the Okta SAML provider. Attach a permissions policy scoped to the bucket. Contractors authenticate via Okta, which generates a SAML assertion. The assertion is exchanged with STS for temporary credentials. The contractors then access the bucket via AWS CLI or console. This provides fine-grained, time-limited access without creating IAM users. Common issue: the SAML assertion must include the correct role ARN and session duration; otherwise, STS rejects the request. Scale: can support thousands of federated users.

A web application runs on an Auto Scaling group of EC2 instances. The instances need to read from DynamoDB and write to SQS. Instead of embedding access keys in the AMI or user data, attach an IAM role to the launch configuration. The role's permissions policy grants dynamodb:GetItem and sqs:SendMessage. As instances scale up, they automatically assume the role via the instance profile. No manual key management. Misconfiguration: if the role's permissions are too broad (e.g., dynamodb:*), an attacker who compromises an instance could delete tables. Best practice: use the most restrictive policy and use condition keys like aws:ResourceTag to limit access to specific tables. Performance: credential rotation is handled by the EC2 metadata service with no application impact.