DevOps Glossary

AWS IAM Role is an identity in Amazon Web Services that has permissions but no long-term password or access keys. IAM stands for Identity and Access Management. In practical terms, a role lets an AWS service, user, application, CI/CD job, or external identity temporarily assume permissions to access AWS resources.

What an AWS IAM Role does

An IAM role defines what actions are allowed and which resources those actions apply to. A role can allow tasks such as reading objects from an S3 bucket, writing logs to CloudWatch, pulling images from ECR, or managing infrastructure through an automation tool.

Roles are central to secure access design in AWS because they avoid hardcoded credentials. Instead of storing access keys in an app, you attach or assign a role and let AWS issue temporary credentials when needed.

How it works

An AWS IAM Role has two main permission layers:

• Trust policy: Defines who or what is allowed to assume the role. This can be an AWS service, another AWS account, an IAM user, a SAML identity provider, an OIDC provider, or a Kubernetes service account through IRSA.
• Permissions policy: Defines what the role can do after it is assumed, such as s3:GetObject, logs:PutLogEvents, or eks:DescribeCluster.

When a principal assumes a role, AWS Security Token Service, or STS, returns temporary security credentials. These credentials usually include an access key ID, secret access key, and session token with a limited lifetime.

You can learn more about the broader permission model in AWS IAM.

Common use cases

• Service roles: Let AWS services act on your behalf, such as a Lambda function writing logs to CloudWatch or an ECS task reading secrets from Secrets Manager.
• EC2 instance profiles: Give EC2 instances temporary credentials without placing access keys on the server.
• Cross-account access: Let a user, service, or automation process in one AWS account access resources in another account.
• CI/CD pipelines: Allow systems such as GitHub Actions, GitLab CI, Jenkins, or Argo CD to deploy infrastructure and applications using short-lived credentials.
• Kubernetes workloads: Map Kubernetes service accounts to IAM roles, often used with Amazon EKS and IAM Roles for Service Accounts.
• Infrastructure automation: Give Terraform, Pulumi, Crossplane, or custom deployment tools scoped access to create and update cloud resources.

Key parts of an IAM Role

• Role ARN: The unique identifier for the role, such as arn:aws:iam::123456789012:role/app-deploy-role.
• Trust relationship: The policy that controls which principals can assume the role.
• Attached policies: Managed or inline policies that grant permissions.
• Session duration: The maximum time temporary credentials remain valid.
• Permissions boundary: An optional limit that caps the maximum permissions the role can receive.
• Session tags: Optional tags passed when assuming a role, useful for audit trails and attribute-based access control.

Simple example

Suppose you run an API on Amazon EKS. The API needs to read files from an S3 bucket named company-prod-invoices. Instead of placing AWS access keys in a Kubernetes Secret, you can create an IAM role with permission to call s3:GetObject on that bucket.

You then configure the EKS service account so the pod can assume that role. When the pod starts, AWS provides temporary credentials to the workload. If the pod is compromised, the credentials expire and the role can be restricted to only the exact S3 actions and bucket paths the app needs.

This same pattern appears in production platform workflows, such as deploying data platforms on AWS Elastic Kubernetes Service or managing AWS resources from Kubernetes using Crossplane.

AWS IAM Role vs IAM User

• IAM User: Represents a specific person or workload and can have long-term credentials such as a password or access keys.
• IAM Role: Represents a set of permissions that another identity can assume temporarily.

For production systems and automation, roles are usually safer than long-lived IAM user access keys because they reduce credential exposure and make rotation easier. IAM users may still appear in older systems, break-glass access flows, or cases where a tool does not support role assumption well.

AWS IAM Role vs IAM Policy

An IAM policy is a permissions document. An IAM role is an identity that can have policies attached to it. The role answers “who can receive these permissions?” and the policy answers “what can this identity do?”

For example, a role named billing-report-reader might trust a specific analytics account. Its attached policy might allow s3:GetObject on a billing reports bucket and deny all write actions.

Benefits

• Short-lived credentials: Reduces risk compared with static access keys.
• Least privilege access: Lets you scope permissions by action, resource, account, condition, and session.
• Clear audit trails: CloudTrail records role assumption events and API calls made with the role session.
• Works well with automation: Useful for CI/CD, Kubernetes controllers, serverless functions, and infrastructure-as-code workflows.
• Supports cross-account access: Common in multi-account AWS setups for production, staging, security, and shared services accounts.

Tradeoffs and limitations

• Policy complexity: Trust policies, permission policies, boundaries, and conditions can become hard to reason about at scale.
• Overly broad roles are risky: Permissions such as *:* or broad resource access can create major blast radius.
• iam:PassRole needs care: A user or service that can pass a powerful role to another service may gain indirect access to those permissions.
• Debugging can take time: Access failures may come from the trust policy, permissions policy, service control policy, resource policy, or session policy.
• Role chaining has limits: Assuming one role from another can affect session duration and make audit paths harder to read.

Good practices

• Grant the smallest set of actions and resources the workload needs.
• Use separate roles for different apps, environments, and deployment pipelines.
• Add conditions where useful, such as account ID, source ARN, external ID, MFA, OIDC subject, or specific resource tags.
• Review CloudTrail logs to understand which permissions are actually used.
• Avoid storing access keys when a role-based option exists.
• Protect who can create roles, update trust policies, attach policies, and use iam:PassRole.

In short, an AWS IAM Role is the standard way to give temporary, scoped AWS access to services, workloads, users, and automation. For DevOps and platform teams, it is one of the core building blocks for secure deployments, multi-account access, and cloud-native workload identity.