AWS IAM Roles vs Resource Based Policies

Easter Sale is here! Courses start at just $11.99!

AWS IAM Roles vs Resource Based Policies

AWS allows granting cross-account access to AWS resources, which can be done using IAM Roles or Resource Based policies

IAM Roles

  • Roles can be created to act as a proxy to allow users or services to access resources
  • Roles supports trust policy which helps determine who can access the resources and permission policy which helps to determine what they can access
  • User who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. When the user exits, or stops using the role, the original user permissions are restored.
  • Roles can be used to provision access to almost all the AWS resources
  • Permissions provided to the User through the Role can be further restricted per user by passing optional policy to the STS request. This policy cannot be used to elevate privileges beyond what the assumed role is allowed to access

Resource based Policies

  • Resource based policy allows you to attach a policy directly to the resource that you want to share, instead of using a role as a proxy.
  • Resource-based policy specifies who, as a Principal in the form of a list of AWS account ID numbers, can access that resource and what they can access
  • With Cross-account access with a resource-based policy, User still works in the trusted account and does not have to give up her user permissions in place of the role permissions.
  • User can work on the resources from both the accounts at the same time and this can be useful for scenarios for e.g. copying of objects from one bucket to the other
  • Resource that you want to share are limited to resources which support resource-based policies
    • Amazon S3 allows you to define Bucket policy to grant access to the bucket and the objects
    • Amazon Simple Notification Service (SNS)
    • Amazon Simple Queue Service (SQS)
    • Amazon Glacier Vaults
    • AWS OpsWorks stacks
    • AWS Lambda functions
  • Resource based policies need the trusted account to create users with permissions to be able to access the resources from the trusting account
  • Only permissions equivalent to, or less than, the permissions granted to your account by the resource owning account can be delegated

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What are the two permission types used by AWS?
    1. Resource-based and Product-based
    2. Product-based and Service-based
    3. Service-based
    4. User-based and Resource-based
  2. What’s the policy used for cross account access? (Choose 2)
    1. Trust policy
    2. Permissions Policy
    3. Key policy

3 thoughts on “AWS IAM Roles vs Resource Based Policies

  1. I am trying to write policy that will allow user to delete only user owned keypairs. User “A” should not be able to delete keypair owned by user “B”?

    Any ideas.

  2. It’s worth pointing out that when using roles within an application the idea of being a user and temporarily giving up permissions to assume a role doesn’t really apply. You instead have credentials which you can use as required for each action you want to take. You can switch between these credentials for each action e.g. you can read from an s3 bucket using the default application credentials and then post to an SNS topic using the credentials of an assumed role. The credentials tells AWS who you are in each case and so you have the ability to act like multiple users assuming multiple roles without ever losing permissions.

    It’s not like this if you are a user logging in to the web console. Assuming a role means everything you can do is limited by the role. You have to then switch back out of the role to get your regular account permissions. But you can see the same effect on the CLI where your credentials file can hold multiple sets of keys and by setting the –profile parameter each command can execute using different credentials.

    Assuming a role in the application or on the CLI means being given a set of temporary credentials that you then provide with each action or request. You can immediately revert to another set of credentials for the next action. The important thing to note is that this isn’t limiting your application in any way.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.