IAM Roles vs Resource-Based Policies – Comparison

~ Last updated on : ~ jayendrapatil
Table of Contents hide
AWS IAM Roles vs Resource-Based Policies
Cross-Account Access Methods
IAM Roles
Resource-based Policies
Resource Control Policies (RCPs)
AWS Resource Access Manager (RAM)
IAM Roles vs Resource-Based Policies – Key Differences
Best Practices for Cross-Account Access
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. Understanding the differences between these two mechanisms is critical for designing secure, multi-account architectures.

Cross-Account Access Methods

  • AWS provides four primary ways to grant cross-account access using resource-based policies:
    • Method 1: Grant access to a specific IAM role using the Principal element (most granular, but role deletion breaks access)
    • Method 2: Grant access to an entire account using the Principal element (delegates access control to the other account)
    • Method 3: Grant access to a specific IAM role using the aws:PrincipalArn condition key (balanced approach — survives role recreation)
    • Method 4: Grant access to an entire AWS Organizations organization using aws:PrincipalOrgId condition key
  • AWS recommends using IAM roles with temporary credentials for cross-account access instead of IAM users with long-term credentials (access keys).

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 session policy to the STS request. This session policy cannot be used to elevate privileges beyond what the assumed role is allowed to access.
  • When a role ARN is specified in a resource-based policy’s Principal element, AWS maps it to the role’s unique ID. If the role is deleted and recreated with the same name, the new role will have a different unique ID and will not have access — this is an intentional security feature.
  • Using the aws:PrincipalArn condition key in resource-based policies (instead of specifying the role in the Principal element) allows access to survive role recreation, as the condition compares by ARN string rather than unique ID.

IAM Roles Anywhere

  • IAM Roles Anywhere extends the short-term credential model beyond the cloud, allowing on-premises and multi-cloud workloads to authenticate using X.509 certificates issued by your existing PKI (Public Key Infrastructure).
  • Eliminates the need for long-term access keys for on-premises workloads.
  • Supports credentials valid for up to 12 hours (extended from the original shorter duration).
  • Integrates with enterprise PKI so non-AWS workloads can use the same IAM policies and roles as AWS workloads.
  • Use cases include on-premises Kubernetes clusters, CI/CD pipelines running outside AWS, and hybrid cloud environments.

Confused Deputy Prevention

  • The confused deputy problem is a security issue where a less-privileged entity coerces a more-privileged service to perform actions on its behalf.
  • AWS recommends using the following global condition context keys in role trust policies and resource-based policies:
    • aws:SourceArn — restrict to a specific resource ARN (most effective)
    • aws:SourceAccount — restrict to a specific AWS account
    • aws:SourceOrgID — restrict to an AWS Organizations organization
    • aws:SourceOrgPaths — restrict to specific organizational units
  • These condition keys should always be used when granting service principals access to your resources.

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, IAM role ARNs, or IAM user ARNs, that can access that resource and what actions they can perform.
  • 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.
  • For same-account access, policy evaluation requires either the identity-based policy or the resource-based policy (but not both) to allow the request. For cross-account access, both an identity-based policy in the principal’s account and the resource-based policy on the resource must allow the request.
  • Resources that support resource-based policies include (but are not limited to):
    • Amazon S3 — Bucket policies for bucket and object access
    • Amazon SNS (Simple Notification Service)
    • Amazon SQS (Simple Queue Service)
    • Amazon S3 Glacier — Vault access policies
    • AWS Lambda — Function policies
    • AWS KMS — Key policies (required for KMS, every key must have one)
    • Amazon DynamoDB — Table, index, and stream policies (added 2024)
    • AWS Secrets Manager — Secret resource policies
    • Amazon EventBridge — Event bus policies
    • AWS Backup — Vault access policies
    • Amazon ECR — Repository policies
    • AWS CodeArtifact — Domain and repository policies
    • Amazon Bedrock AgentCore — Runtime and endpoint 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.

Resource Control Policies (RCPs)

  • Resource Control Policies (RCPs) are a new type of authorization policy in AWS Organizations, launched at re:Invent 2024.
  • RCPs provide central control over the maximum available permissions on AWS resources across your entire organization.
  • RCPs complement Service Control Policies (SCPs):
    • SCPs — set maximum permissions for IAM principals (users and roles)
    • RCPs — set maximum permissions for AWS resources
  • RCPs help establish a data perimeter by centrally restricting external access to your resources at scale.
  • Supported services include: Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager, Amazon Cognito, and Amazon CloudWatch Logs (expanding).
  • RCPs are applied organization-wide through AWS Organizations and can be attached to the organization root, OUs, or individual accounts.
  • AWS Sign-in now supports both resource-based policies and RCPs for the AWS Management Console, enabling restriction of console sign-in to expected networks.

AWS Resource Access Manager (RAM)

  • AWS RAM enables you to share resources with other AWS accounts or within your AWS Organization without using resource-based policies directly.
  • RAM eliminates the need to provision and manage duplicate resources in every account.
  • When sharing a resource, the receiving account’s IAM policies and permissions apply to the shared resource.
  • Supported resources include: VPC subnets, Transit Gateway, Route 53 Resolver rules, License Manager configurations, Aurora DB clusters, and many more.
  • RAM integrates with AWS Organizations to enable sharing without requiring individual account acceptance.

IAM Roles vs Resource-Based Policies – Key Differences

  • Permission Delegation: With IAM roles, the user gives up their original permissions and takes on role permissions. With resource-based policies, the user retains their original permissions.
  • Simultaneous Access: Resource-based policies allow users to work with resources in both accounts simultaneously. Roles do not.
  • Coverage: IAM roles can provide access to almost all AWS resources. Resource-based policies are limited to services that support them.
  • Session Policies: IAM roles support session policies for further restricting permissions. Resource-based policies do not support this concept.
  • Policy Evaluation: For cross-account access via roles, only the role’s identity-based policy determines effective permissions. For cross-account access via resource-based policies, both the caller’s identity-based policy and the resource policy must allow the action.

Best Practices for Cross-Account Access

  • Use IAM roles with temporary credentials instead of IAM users with long-term access keys.
  • Use the aws:PrincipalArn condition key in resource-based policies for a balance of security and availability.
  • Use the aws:PrincipalOrgId condition key to restrict access to your AWS Organization.
  • Use External ID in trust policies when granting access to third parties to prevent confused deputy attacks.
  • Implement the principle of least privilege in all cross-account policies.
  • Use RCPs to enforce organization-wide data perimeters on resources.
  • Regularly audit cross-account access using IAM Access Analyzer.
  • Consider using IAM Identity Center (formerly AWS SSO) with permission sets for centralized multi-account access management.

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. A company has two AWS accounts – Account A and Account B. Account A has an S3 bucket that Account B needs to access. The security team wants to ensure that if the IAM role in Account B is accidentally deleted and recreated, access is maintained. Which approach should be used in the bucket policy?
    1. Specify the IAM role ARN in the Principal element
    2. Specify the account number in the Principal element with an aws:PrincipalArn condition
    3. Specify the account number in the Principal element without any condition
    4. Use a service control policy
  4. An organization wants to centrally restrict external access to their AWS resources across all accounts. Which policy type should they use?
    1. Service Control Policies (SCPs)
    2. Identity-based policies
    3. Resource Control Policies (RCPs)
    4. Permission boundaries
  5. A developer needs to copy objects from an S3 bucket in Account A to an S3 bucket in Account B, and needs to access both buckets simultaneously. Which cross-account access method should be used?
    1. IAM Role in Account A
    2. IAM Role in Account B
    3. Resource-based policy on the S3 bucket in Account A
    4. AWS Resource Access Manager
  6. Which condition keys should be used to prevent the confused deputy problem when granting a service principal access to your resources? (Choose 2)
    1. aws:SourceArn
    2. aws:SourceAccount
    3. aws:PrincipalOrgId
    4. aws:RequestedRegion
  7. An on-premises server needs to access AWS resources using temporary credentials without managing long-term access keys. Which service should be used?
    1. AWS STS AssumeRole
    2. IAM User with MFA
    3. IAM Roles Anywhere
    4. AWS Directory Service

References

5 thoughts on “IAM Roles vs Resource-Based Policies – Comparison”

  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.