-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bidirectionally restrictive permissions #50
Comments
I do have a use case for it right now, which is secrets--definitely only want those to be readable by designated users. |
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? |
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 |
To make matters worse, IAM policies don't even work how I thought they worked :( |
I think the logic will have to be:
|
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 |
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. |
@rix0rrr This is from 2018. Is it still relevant or can we close it? |
Mmyeah, let's close it. |
Let's reopen the discussion!
In some cases, bidirectional permissions are redundant (S3) but in others they are required (KMS).
Do we have to inventarize? At least we have to revisit our generic strategy.
The text was updated successfully, but these errors were encountered: