Bidirectionally restrictive permissions

[rix0rrr]

Bidirectionally restrictive permissions

[rix0rrr]

I do have a use case for it right now, which is secrets--definitely only want those to be readable by designated users.

[rix0rrr]

I wonder if it's better to strip resource policies out right now, release without them, and tighten up later as people ask for it?

[rix0rrr]

This also ties into meeting compliance requirements for service teams/enterprises: customer data should never be accessible by humans, and it's very likely that humans have role access to the account, potentially with ":" policies attached to the role.

Maybe the solution is that we have a boolean to mark certain resources sensitive: true, and that controls whether permissions are role-only or bidi.

[rix0rrr]

To make matters worse, IAM policies don't even work how I thought they worked :(

[rix0rrr]

I think the logic will have to be:

• Attach to identity policy; UNLESS
  • that's not possible because of principal type (because the principal is not an IAM Identity. Examples of non-identity principals are Account Root or Service Principal) => attach to resource instead
  • the grant is cross-account => attach to both

[rix0rrr]

Soo... S3 policies are definitely additive (as in, you can do the action as long as either the resource policy or IAM policy gives you the permission), but KMS policies seem not to be?

I have an identity that has "*:*" yet I still cannot use the key to decrypt as long as I don't have an explicit resource grant.

[rix0rrr]

I guess this makes sense for KMS and it appears to be documented (https://docs.aws.amazon.com/kms/latest/developerguide/determining-access.html) but we now have to contend with that IAM evaluation rules might be different for different resources.

[SomayaB]

@rix0rrr This is from 2018. Is it still relevant or can we close it?

[rix0rrr]

Mmyeah, let's close it.