In AWS IAM (Identity and Access Management), inline policies and assume role policies (also known as trust policies) serve different purposes within the lifecycle of IAM roles. Here’s a breakdown of the key differences between the two:
1. Inline Policy:
- Purpose: An inline policy is a permission policy that is embedded directly into an IAM role, user, or group. It defines what actions the role can perform on AWS resources.
- Function: Controls what actions the role can take and on which resources.
- Policy Type: These are permission policies. They grant permissions to the entity (role, user, or group) they are attached to.
- Example Use Case: An inline policy for an IAM role might allow it to perform specific actions, such as listing all S3 buckets or launching EC2 instances.
Where It’s Stored: Inline policies are stored directly in the IAM role, user, or group they are attached to.
Control: Fine-grained control for individual users, roles, or groups.
2. Assume Role Policy (Trust Policy):
- Purpose: The assume role policy (or trust policy) defines who or what entity (user, service, or another AWS account) can assume the IAM role. This policy grants permission to another entity to assume the role and temporarily gain its permissions.
- Function: Controls who can assume the role and under what conditions.
- Policy Type: These are trust policies. They define the relationship between the role and the principal (like an IAM user, another role, or AWS service) that can assume it.
- Example Use Case: An EC2 instance might assume an IAM role that has permissions to write to an S3 bucket, but only if the trust policy allows the EC2 service to assume the role.
Where It’s Stored: The assume role policy is stored in the IAM role itself and determines who can assume the role.
Control: Controls who can assume the role, typically allowing a user or service (like EC2, Lambda, etc.) to use the role’s permissions.
Summary of Differences:
| Feature | Inline Policy | Assume Role Policy (Trust Policy) |
|---|---|---|
| Purpose | Grants permissions for actions on AWS resources | Defines who (user, service, AWS account) can assume the role |
| Type | Permission policy | Trust policy |
| Controls | What actions the role can perform | Who can assume the role |
| Attached To | Roles, users, or groups | IAM roles |
| Example Usage | Allow a role to list S3 buckets or start EC2 instances | Allow EC2 instances to assume a role and access its policies |
| Policy Example | "Action": "s3:ListBucket" | "Principal": "ec2.amazonaws.com" |
| Stored In | Embedded directly in the role, user, or group | Defined within the IAM role itself |
Key Takeaways:
- Inline policies grant permissions to the entity they are attached to.
- Assume role policies (trust policies) define who can assume the role and temporarily gain its permissions.
Mentor for DevOps - DevSecOps - SRE - Cloud - Container & Micorservices at Software AG
Join my following certification courses...
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
Latest posts by Rajesh Kumar (see all)
- AWS Tutorials: IAM – Difference of inline policies and assume role policies (also known as trust policies) - October 18, 2024
- How to Build a Successful Shopify Store: Dos and Don’ts for Your Business - October 17, 2024
- AWS Tutorials: How to visualize AWS Cloud resources – Workload Discovery - October 15, 2024
