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

Question

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)?

Answer 1

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.

Answer 2

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