In Amazon Web Services (AWS), identity and resource policies are crucial components of the AWS Identity and Access Management (IAM) service, which helps you securely control access to AWS resources. They enable you to specify who is allowed to do what and under which conditions across all AWS resources. When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy.
Identity Policy
Identity policies are attached directly to IAM identities, which could be a user, group, or role. These policies grant permissions to the identity by defining what actions can be taken on which AWS resources and under what conditions.
For example, you can attach the policy to the IAM user named John, stating that he is allowed to perform the Amazon EC2 RunInstances action. The policy could further state that John is allowed to get items from an Amazon DynamoDB table named MyCompany. You can also allow John to manage his own IAM security credentials.
There are two main types of identity policies:
Managed Policies: These are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. They can be AWS managed or customer managed.
Inline Policies: These are policies that you create and manage and are embedded directly into a single user, group, or role.
A basic example of an identity policy might look like this in JSON format:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket"
}
]
}
This policy allows the identity it is attached to, to list the contents of "example-bucket" in Amazon S3.
Resource Policy
Resource policies are attached to AWS resources, not identities. They specify who (which principal, such as an IAM user or role) is allowed or denied access to the resource and under which conditions.
A well-known example of a resource policy is an S3 bucket policy. An example of an S3 bucket policy that allows all users in the account to perform any S3 action on the objects in a specific S3 bucket looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::account-id:root"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}
In this example, the policy is granting all S3 actions on the objects within "example-bucket" to all users within the specified AWS account.
You can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, VPC endpoints, and AWS Key Management Service encryption keys. For a list of services that support resource-based policies, see AWS services that work with IAM.
With resource-based policies, you can specify who has access to the resource and what actions they can perform on it. To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see What is IAM Access Analyzer?. Resource-based policies are inline only, not managed.
To learn how identity-based policies and resource-based policies interact within the same account, see Evaluating policies within a single account.
To learn how the policies interact across accounts, see Cross-account policy evaluation logic.
Deny overrides an Allow when evaluating policy logic. More info at Policy Evaluation Logic
Key Points to Note:
Evaluation: AWS uses a default-deny principle. So, unless explicitly allowed, access is denied. AWS evaluates all applicable policies (identity and resource) to determine whether a request is allowed or denied.
Policy Types: Resource policies are often used in services like Amazon S3, SNS, and SQS, whereas identity policies are commonly utilized across various AWS services.
Trust Policy: It is a type of resource policy attached to IAM roles that define which entities (users or services) are allowed to assume the role.
Both identity and resource policies are expressed in JSON format and can range from simple, granting wide permissions, to complex, allowing for fine-grained control and conditional permission granting based on various attributes like IP, VPC, or specific tags. Moreover, combining identity and resource policies provides a powerful mechanism to control access to AWS resources, allowing administrators to implement the principle of least privilege effectively.