AWS IAM Roles vs Resource Based Policies

~ Last updated on : ~ jayendrapatil
Table of Contents hide
AWS IAM Roles vs Resource-Based Policies
IAM Roles
Resource-based Policies
AWS Certification Exam Practice Questions

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 support
    • trust policy which helps determine who can access the resources and
    • permission policy which helps to determine what they can access.
  • Users who assume a role temporarily give up their own permissions and instead take on the permissions of the role. The original user permissions are restored when the user exits or stops using the role.
  • Roles can be used to provide access to almost all the AWS resources.
  • Permissions provided to the User through the Role can be further restricted per user by passing an 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 you want to share, instead of using a role as a proxy.
  • Resource-based policy specifies the Principal, in the form of a list of AWS account ID numbers, can access that resource and what they can access.
  • Using cross-account access with a resource-based policy, the User still works in the trusted account and does not have to give up their permissions in place of the role permissions.
  • Users can work on the resources from both accounts at the same time and this can be useful for scenarios e.g. copying objects from one bucket to the other bucket in a different AWS account.
  • Resources that you want to share are limited to resources that support resource-based policies
  • Resource-based policies need the trusted account to create users with permissions to be able to access the resources from the trusted 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

References

5 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.

  3. If a User has both an individual access policy to the AWS resources and is part of a Group where the Group plicy conflicts with his access policy … then what priviledge would the Individual ultimately have ?

Comments are closed.