Skip to content
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

Closed
rix0rrr opened this issue Jun 6, 2018 · 9 comments
Closed

Bidirectionally restrictive permissions #50

rix0rrr opened this issue Jun 6, 2018 · 9 comments
Assignees
Labels
closing-soon This issue will automatically close in 4 days unless further comments are made.

Comments

@rix0rrr
Copy link
Contributor

rix0rrr commented Jun 6, 2018

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.

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Jun 6, 2018

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

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Jun 6, 2018

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
Copy link
Contributor Author

rix0rrr commented Jun 6, 2018

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
Copy link
Contributor Author

rix0rrr commented Jun 7, 2018

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

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Jun 8, 2018

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
Copy link
Contributor Author

rix0rrr commented Jun 8, 2018

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
Copy link
Contributor Author

rix0rrr commented Jun 8, 2018

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 rix0rrr added the design label Jun 22, 2018
@SomayaB SomayaB added @aws-cdk/aws-iam Related to AWS Identity and Access Management and removed @aws-cdk/aws-iam Related to AWS Identity and Access Management labels Sep 24, 2019
@SomayaB
Copy link
Contributor

SomayaB commented Sep 24, 2019

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

@SomayaB SomayaB added the closing-soon This issue will automatically close in 4 days unless further comments are made. label Sep 24, 2019
@rix0rrr
Copy link
Contributor Author

rix0rrr commented Sep 25, 2019

Mmyeah, let's close it.

@rix0rrr rix0rrr closed this as completed Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closing-soon This issue will automatically close in 4 days unless further comments are made.
Projects
None yet
Development

No branches or pull requests

3 participants