AWS Resource-based Policies
- Resource-based policies allow attaching a policy directly to the resource you want to share, instead of using a role as a proxy.
- Resource-based policies allow granting usage permission to other AWS accounts or organizations on a per-resource basis.
- 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
- S3 allows you to define Bucket policy to grant access to the bucket and the objects
- Simple Notification Service (SNS)
- Simple Queue Service (SQS)
- Glacier Vaults
- OpsWorks stacks
- Lambda functions
- API Gateway
- 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 the account by the resource owning account can be delegated.
S3 Bucket Policy
- S3 Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
- Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address).
- Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
- Policies can either add or deny permissions across all (or a subset) of objects within a bucket
- Only the bucket owner is allowed to associate a policy with a bucket
- Bucket policies can cater to multiple use cases
- Granting permissions to multiple accounts with added conditions
- Granting read-only permission to an anonymous user
- Limiting access to specific IP addresses
- Restricting access to a specific HTTP referer
- Restricting access to a specific HTTP header for e.g. to enforce encryption
- Granting permission to a CloudFront OAI
- Adding a bucket policy to require MFA
- Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
- Granting permissions for S3 inventory and Amazon S3 analytics
- Granting permissions for S3 Storage Lens
Glacier Vault Policy
- S3 Glacier vault access policy is a resource-based policy that can be used to manage permissions to the vault.
- A Vault Lock policy is a Vault Access policy that can be locked. After you lock a Vault Lock policy, the policy can’t be changed. You can use a Vault Lock Policy to enforce compliance controls.
KMS Key Policy
- KMS Key Policy helps determine who can use and manage those keys and is a primary mechanism for controlling access to a key.
- KMS Key Policy can be used alone to control access to the keys.
- A KMS key policy MUST be used, either alone or in combination with IAM policies or grants to allow access to a KMS CMK.
- IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
- IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.
API Gateway Resource Policy
- API Gateway resource policies are attached to an API to control whether a specified principal (typically an IAM role or group) can invoke the API.
- API Gateway resource policies can be used to allow the API to be securely invoked by:
- Users from a specified AWS account.
- Specified source IP address ranges or CIDR blocks.
- Specified virtual private clouds (VPCs) or VPC endpoints (in any account).
- Resource policies can be used for all API endpoint types in API Gateway: private, edge-optimized, and Regional.
Lambda Function Policy
- Lambda supports resource-based permissions policies for Lambda functions and layers.
- Resource-based policy can be used to allow an AWS service to invoke the function on your behalf.
- Resource-based policies apply to a single function, version, alias, or layer version.
EFS File System Policy
- EFS supports IAM resource policy using file system policy.
- EFS evaluates file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant.
- An “allow” permission on an action in either an IAM identity policy or a file system resource policy allows access for that action.
ECR Repository policy
-
- Repository policies are resource-based policies that can help control access to the repositories and the images within them.
- Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
- A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
- Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.
SNS Policy
- SNS policy can be used with a particular topic to restrict who can work with that topic e.g, who can publish messages to it, subscribe to it, etc.
- SNS policies can grant access to other AWS accounts, or to users within your own AWS account.
SQS Policy
- SQS policy system lets you grant permission to other AWS Accounts, whereas IAM doesn’t.
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.