{"id":47232,"date":"2024-10-18T04:27:00","date_gmt":"2024-10-18T04:27:00","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=47232"},"modified":"2024-10-25T07:35:04","modified_gmt":"2024-10-25T07:35:04","slug":"aws-tutorials-iam-difference-of-inline-policies-and-assume-role-policies-also-known-as-trust-policies","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/aws-tutorials-iam-difference-of-inline-policies-and-assume-role-policies-also-known-as-trust-policies\/","title":{"rendered":"AWS Tutorials: IAM Roles Complete Guide"},"content":{"rendered":"\n

Common terminologies used in IAM Roles<\/strong> and IAM Policies<\/strong> in AWS Identity and Access Management (IAM)<\/h2>\n\n\n\n
Term<\/strong><\/th>Description<\/strong><\/th><\/tr><\/thead>
IAM Role<\/strong><\/td>An IAM entity that defines a set of permissions for making AWS service requests. Roles can be assumed by users, applications, or services.<\/td><\/tr>
IAM Policy<\/strong><\/td>A document that defines permissions for IAM users, groups, and roles. Policies can be attached to roles or users to control access to AWS resources.<\/td><\/tr>
Trust Policy<\/strong><\/td>A policy attached to an IAM role that specifies who can assume the role. It establishes trust between the role and the entity assuming it.<\/td><\/tr>
Permissions Policy<\/strong><\/td>A policy attached to an IAM user, group, or role that defines what actions are allowed or denied on which AWS resources.<\/td><\/tr>
Principal<\/strong><\/td>The entity (user, role, service) that is allowed or denied access to AWS resources. It specifies “who” in IAM policies.<\/td><\/tr>
Action<\/strong><\/td>Specifies the specific AWS actions that can be allowed or denied (e.g., s3:PutObject<\/code>, ec2:StartInstances<\/code>).<\/td><\/tr>
Resource<\/strong><\/td>Specifies the AWS resources to which the policy applies (e.g., an S3 bucket, an EC2 instance).<\/td><\/tr>
Condition<\/strong><\/td>Additional conditions that must be met for a policy to apply, such as IP address restrictions, multi-factor authentication (MFA), or time constraints.<\/td><\/tr>
Assume Role<\/strong><\/td>The process by which an IAM principal (user or service) temporarily takes on the permissions of an IAM role.<\/td><\/tr>
Managed Policy<\/strong><\/td>A standalone policy created by AWS or by users that can be attached to multiple users, groups, or roles.<\/td><\/tr>
Inline Policy<\/strong><\/td>A policy embedded directly in a single IAM user, group, or role. It\u2019s specific to that entity and cannot be reused.<\/td><\/tr>
AWS Managed Policy<\/strong><\/td>A policy created and managed by AWS, which includes common permissions sets, such as AmazonS3ReadOnlyAccess<\/code>.<\/td><\/tr>
Customer Managed Policy<\/strong><\/td>A custom policy created by the user to provide specific permissions not covered by AWS Managed Policies.<\/td><\/tr>
Policy Document<\/strong><\/td>The JSON document that defines an IAM policy, specifying permissions, actions, resources, and conditions.<\/td><\/tr>
Policy Version<\/strong><\/td>IAM policies have versions to manage updates. Only one version can be the “default” version that is in effect at any time.<\/td><\/tr>
Session Policy<\/strong><\/td>A policy applied during the temporary session of a user who assumes a role, allowing for additional, session-specific permissions.<\/td><\/tr>
Role Session Name<\/strong><\/td>A unique identifier for a session when an IAM role is assumed, often used for logging and tracking purposes.<\/td><\/tr>
Policy Simulator<\/strong><\/td>A tool in IAM that allows testing of policies to see how they will affect access for a specific user or role.<\/td><\/tr>
STS (Security Token Service)<\/strong><\/td>Service that provides temporary credentials to assume roles, allowing short-term access to AWS resources.<\/td><\/tr>
Permission Boundary<\/strong><\/td>An advanced feature that sets a limit on the maximum permissions an IAM role or user can have, regardless of their other attached policies.<\/td><\/tr>
Temporary Security Credentials<\/strong><\/td>Short-term credentials provided by assuming a role, intended for temporary access to AWS resources.<\/td><\/tr>
Service-linked Role<\/strong><\/td>A role created by AWS services that allow those services to manage resources on the user\u2019s behalf (e.g., AWSServiceRoleForSupport<\/code>).<\/td><\/tr>
PassRole<\/strong><\/td>An IAM permission that allows one role to “pass” another role to an AWS service, used in scenarios like launching an EC2 instance with an IAM role.<\/td><\/tr>
Principal ARN<\/strong><\/td>The Amazon Resource Name (ARN) that uniquely identifies a principal entity, such as an IAM user or role, within AWS.<\/td><\/tr>
Effect<\/strong><\/td>Specifies whether the policy statement allows or denies access (e.g., \"Effect\": \"Allow\"<\/code> or \"Effect\": \"Deny\"<\/code>).<\/td><\/tr>
Federated Identity<\/strong><\/td>Allows external identities (e.g., from Google, Facebook, or corporate directory) to access AWS resources through IAM roles.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Difference of inline policies and assume role policies (also known as trust policies)<\/h2>\n\n\n\n

In AWS IAM (Identity and Access Management), inline policies<\/strong> and assume role policies<\/strong> (also known as trust policies<\/strong>) serve different purposes within the lifecycle of IAM roles. Here’s a breakdown of the key differences between the two:<\/p>\n\n\n\n

1. Inline Policy<\/strong>:<\/h3>\n\n\n\n
    \n
  • Purpose<\/strong>: An inline policy is a permission policy<\/strong> that is embedded directly into an IAM role, user, or group. It defines what actions the role can perform on AWS resources.<\/li>\n\n\n\n
  • Function<\/strong>: Controls what actions<\/strong> the role can take and on which resources.<\/li>\n\n\n\n
  • Policy Type<\/strong>: These are permission policies<\/strong>. They grant permissions to the entity (role, user, or group) they are attached to.<\/li>\n\n\n\n
  • Example Use Case<\/strong>: An inline policy for an IAM role might allow it to perform specific actions, such as listing all S3 buckets or launching EC2 instances.<\/li>\n<\/ul>\n\n\n\n

    Where It’s Stored<\/strong>: Inline policies are stored directly in the IAM role, user, or group they are attached to.<\/p>\n\n\n\n

    Control<\/strong>: Fine-grained control for individual users, roles, or groups.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    2. Assume Role Policy (Trust Policy)<\/strong>:<\/h3>\n\n\n\n
      \n
    • Purpose<\/strong>: The assume role policy (or trust policy) defines who<\/strong> or what entity<\/strong> (user, service, or another AWS account) can assume<\/strong> the IAM role. This policy grants permission to another entity to assume the role and temporarily gain its permissions.<\/li>\n\n\n\n
    • Function<\/strong>: Controls who can assume the role<\/strong> and under what conditions.<\/li>\n\n\n\n
    • Policy Type<\/strong>: These are trust policies<\/strong>. They define the relationship between the role and the principal (like an IAM user, another role, or AWS service) that can assume it.<\/li>\n\n\n\n
    • Example Use Case<\/strong>: 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.<\/li>\n<\/ul>\n\n\n\n

      Where It’s Stored<\/strong>: The assume role policy is stored in the IAM role itself<\/strong> and determines who can assume the role.<\/p>\n\n\n\n

      Control<\/strong>: Controls who<\/strong> can assume the role, typically allowing a user or service (like EC2, Lambda, etc.) to use the role’s permissions.<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Summary of Differences:<\/h3>\n\n\n\n
      Feature<\/th>Inline Policy<\/strong><\/th>Assume Role Policy (Trust Policy)<\/strong><\/th><\/tr><\/thead>
      Purpose<\/strong><\/td>Grants permissions for actions on AWS resources<\/td>Defines who (user, service, AWS account) can assume the role<\/td><\/tr>
      Type<\/strong><\/td>Permission policy<\/td>Trust policy<\/td><\/tr>
      Controls<\/strong><\/td>What actions the role can perform<\/td>Who can assume the role<\/td><\/tr>
      Attached To<\/strong><\/td>Roles, users, or groups<\/td>IAM roles<\/td><\/tr>
      Example Usage<\/strong><\/td>Allow a role to list S3 buckets or start EC2 instances<\/td>Allow EC2 instances to assume a role and access its policies<\/td><\/tr>
      Policy Example<\/strong><\/td>\"Action\": \"s3:ListBucket\"<\/code><\/td>\"Principal\": \"ec2.amazonaws.com\"<\/code><\/td><\/tr>
      Stored In<\/strong><\/td>Embedded directly in the role, user, or group<\/td>Defined within the IAM role itself<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Key Takeaways:<\/h3>\n\n\n\n
        \n
      • Inline policies<\/strong> grant permissions to the entity<\/strong> they are attached to.<\/li>\n\n\n\n
      • Assume role policies<\/strong> (trust policies) define who can assume<\/strong> the role and temporarily gain its permissions.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

        Common terminologies used in IAM Roles and IAM Policies in AWS Identity and Access Management (IAM) Term Description IAM Role An IAM entity that defines a set of permissions for… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-47232","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/47232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=47232"}],"version-history":[{"count":5,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/47232\/revisions"}],"predecessor-version":[{"id":47268,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/47232\/revisions\/47268"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=47232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=47232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=47232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}