Resource-based policies are JSON-based policies that you attach to AWS resources rather than to IAM users, groups, or roles. These policies define who has access to a specific resource and what actions they can perform on it.
Unlike identity-based policies that are attached to IAM principals, reso…Resource-based policies are JSON-based policies that you attach to AWS resources rather than to IAM users, groups, or roles. These policies define who has access to a specific resource and what actions they can perform on it.
Unlike identity-based policies that are attached to IAM principals, resource-based policies are embedded within the resource itself. Common AWS services that support resource-based policies include S3 buckets, SNS topics, SQS queues, Lambda functions, and KMS keys.
A resource-based policy contains a Principal element that specifies which AWS accounts, IAM users, IAM roles, or AWS services can access the resource. This is a key distinction from identity-based policies, which do not include a Principal element since they are already attached to a specific identity.
Resource-based policies enable cross-account access, allowing principals from other AWS accounts to access resources in your account. When a principal from another account needs access, the resource-based policy must explicitly grant permission to that principal's ARN.
The structure of a resource-based policy includes Version, Statement, Effect (Allow or Deny), Principal, Action, Resource, and optional Condition elements. For example, an S3 bucket policy might allow a specific IAM role from another account to perform GetObject and PutObject operations.
Resource-based policies and identity-based policies work together. When both policy types apply, AWS evaluates them using a logical OR - if either policy allows the action and neither policy denies it, the action is permitted. However, for cross-account access, both the resource-based policy on the target resource AND the identity-based policy on the requesting principal must allow the action.
For developers, understanding resource-based policies is essential for implementing secure architectures, managing cross-account access patterns, and following the principle of least privilege when configuring AWS resources.
Resource-based Policies in AWS
What are Resource-based Policies?
Resource-based policies are JSON policy documents that you attach to a resource such as an S3 bucket, SQS queue, SNS topic, Lambda function, or KMS key. Unlike identity-based policies that are attached to IAM users, groups, or roles, resource-based policies are attached to the resource itself and define who can access that resource and what actions they can perform.
Why are Resource-based Policies Important?
Resource-based policies are crucial for several reasons:
• Cross-account access: They enable you to grant access to principals in other AWS accounts, making cross-account resource sharing possible.
• Service principal access: They allow AWS services to access your resources on your behalf.
• Simplified permissions: They provide a centralized way to manage access at the resource level rather than managing multiple identity policies.
• Anonymous access: For services like S3, they can grant public access when needed (though this should be done carefully).
How Resource-based Policies Work
Resource-based policies contain a Principal element that specifies who is allowed or denied access. This is different from identity-based policies which do not have a Principal element since they are attached to the principal itself.
Key components include:
• Principal: The account, user, role, or service that is allowed or denied access • Action: The specific API operations permitted or denied • Resource: The specific resource ARN the policy applies to • Effect: Allow or Deny • Condition: Optional conditions for when the policy applies
When a principal in Account A tries to access a resource in Account B:
• The identity-based policy in Account A must allow the action • The resource-based policy in Account B must also allow the principal from Account A • Both policies must grant permission for access to succeed
Exception: If the resource-based policy grants access to a specific IAM role or user (not the root account), and that role or user is in the same account as the resource, only the resource-based policy needs to allow access.
Exam Tips: Answering Questions on Resource-based Policies
• Cross-account scenarios: When you see questions about granting access to resources from another AWS account, think resource-based policies first.
• Principal element: Remember that resource-based policies require a Principal element - this distinguishes them from identity-based policies.
• S3 bucket policies: These are the most common resource-based policy type on the exam. Know that they can grant public access or cross-account access.
• Lambda permissions: When AWS services need to invoke Lambda functions, resource-based policies (function policies) are used to grant that permission.
• KMS key policies: KMS is unique - key policies are the primary way to control access to KMS keys and are required for any access to work.
• Policy evaluation: Understand that for cross-account access, both the identity policy and resource policy must allow the action. An explicit deny in either policy results in denial.
• STS AssumeRole alternative: Resource-based policies provide an alternative to assuming a role for cross-account access - the credentials do not need to be exchanged.
• Service principals: When granting access to AWS services, use service principals like lambda.amazonaws.com or s3.amazonaws.com in the Principal element.
• Look for keywords: Questions mentioning bucket policies, queue policies, topic policies, or function policies are referring to resource-based policies.