CODEWITHSUNDEEP
amazon-web-servicesamazon-iam
joakim
joakim

Reputation: 4051

AWS IAM user-based policy vs resource-based policy vs both

Let's assume a user-based IAM policy i.e. one that can be attached to a user, group or role.

Let's say one that gives full access to a DynamoDB table:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-west-2:123456789:table/Books"
  }
}

Based on this policy, any user who somehow ends up with that policy attached to them (via assuming a role or directly for example) gets full access to that DynamoDB table.

Question 1: Is it worth having a resource-based policy on the other end i.e. on the DynamoDB table to complement the user-based policy?

Example:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:user/bob"},
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}

The motivation here is that the previous policy might end up being attached to someone by accident and using the resource-based one would ensure that only user Bob will ever be given these permissions.

Question 2: Is using the stricter resource-policy only preferable maybe?

Question 3: In general, are there any best practices / patterns for picking between user-based vs resource-based policies (for the services that support resource-based policies that is)?

Upvotes: 17

Views: 10448

Answers (4)

M Alok
M Alok

Reputation: 1081

Came across this when I was going through AWS EFS documentation to learn how to control access to the EFS file system,

https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html enter image description here

AWS doesn't require the permission to be granted on both kind of policies but you can definitely do it for having stricter security in place.

Upvotes: 0

user3811015
user3811015

Reputation: 31

It depends whether you are making a request within same aws account, or a cross-account request.

Within the same AWS account, meaning your user belongs to aws account that owns the resource (S3, SQS, SNS etc), you can have either identity-based (user, group, role) OR a resource-based policy (SQS, SNS, S3, API gateway). Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow

However when you are delegating access to different AWS accounts. It can vary. For API gateway, you need explicit allow from identity-based role and resource-based, for example.

source: API Gateway Authorization Flow

Upvotes: 3

Shubham Bansal
Shubham Bansal

Reputation: 391

The answer for all of your questions is it depends

Both IAM policies and Resource policies are equally important depends upon the usecase.

Let say you want to provide permission to AWS managed services like providing permissions to cloud front to read s3 bucket.. it's better to use resource policies ...

But for uploading/changing content, it's better to via IAM policies..

In simple terms it's better to use IAM policies when providing access from some user/external system/user managed instances.. and for providing access in between AWS managed services use resource policies.

Upvotes: 0

EkkardS
EkkardS

Reputation: 101

Answer 0: DynamoDB does not support resource-based policies.

The Console GUI looks like it, but the API does not have an operation for that. And the documentation is clear: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html#access-control-manage-access-resource-based

Answer 1: Do not use IAM and resource policies on the same resource

The challenge with access control is maintaining it over the long run:

  • Permissions for new hires must be set up correctly and swiftly (they want to work!)
  • Permissions for leavers must be removed swiftly (for whatever reason)
  • Someone has to regulary review the permissions and approve them

All of the 3 tasks above are much easier, if there is only a single location where to look for. And use "Effect": "Deny", if you want to restrict access. Any "accidental assignment" would be caught by the review.

Answer 1b:

Of course it depends on the use case (e.g. 4 eyes principle can demand it). And some permissions cannot be set in IAM, ( e.g. "Everyone") and must be set on the resource. Or if you destroy/recreate the resource, the resource-based permission disappears.

Answer 2: IAM policy is easier to manage

If the situation allows both IAM and resource policy, they have the same grammar and can be made equally strict, at least in your case. Assuming all other being equal, IAM policies are much easier to manage.

Answer 3: Best practice

Unfortunately, I am not aware of a best practice issued by AWS, apart from "minimal privileges" of course. I suggest you go with the best practice in terms of maintainability as for other permissions outside of AWS.

Upvotes: 10

Related Questions