-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(kms): trustAccountIdentities
avoids cyclic stack dependencies
#5575
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
naming is difficult, and I'm not sure I have it right yet for this property.
packages/@aws-cdk/aws-kms/lib/key.ts
Outdated
* | ||
* @default false | ||
*/ | ||
readonly enablePolicyControl?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be enableIamPolicyControl
I didn't like the way that reads with the capital I
and lower am
. However, I am not sure Policy is enough here because technically there is a Key Policy.
packages/@aws-cdk/aws-kms/lib/key.ts
Outdated
const actions = enablePolicyControl ? | ||
['kms:*'] : | ||
[ | ||
"kms:Create*", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these permissions are un-altered just moved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's interesting tagging and untagging permissions are not granted. This means that if you add or remove after the initial stack it will warn the user but not implement the change.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Looking very much forward for this. |
As far as I can tell, the change is to allow anyone in the account(*) to also USE the keys to encrypt/decrypt instead of only to administer the key. I don't like adding the parameter to if (props.enablePolicyControl) {
this.allowEveryoneInAccountToAdminOrUse();
} else {
this.allowAccountToAdmin();
} First of all, am I reading the change correctly? Is it simply to completely manage key use from the identity policies of the identities that might want to, without calling The same could be achieved by use of key.grantUsageToAnyoneInThisAccount(); Which looks appropriately scary. If the problem is about downstream consumers, a better alternative would be to make a custom resource (*) Does the use of "AccountRootPrincipal" here represent the actual "root" identity, or just it just mean "any identity in the account"? You're describing it to mean the former but according to the IAM docs, |
Hmm I see KMS roughly recommends the same practice here: https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html I'd still like to see this as an additive operator to the existing key management policy. There will be 2 statements:
The latter one can be added via a construction property and also via a method (but won't be added twice). For the property, I would propose something like: /**
* Allow access to this key using only the identity policy
*
* By default, permissions to use this key need to be added on the
* key policy as well as the identity policy.
*
* Setting this to `true` adds a default statement which will allow
* any identity in the same account to access the key, so that key
* access is controlled completely from the identity's IAM policy
* (similar to how it works for other AWS resources).
*
* You might be forced to use this if the identity that needs to access
* this key will be created in a different Stack, as there is no
* way to set up the permissions otherwise without creating a
* circular reference.
*
* @default false
* @see https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/322
*/
readonly controlAccessViaIdentityPolicyAlone?: boolean; |
Created a feature request for CloudFormation: aws-cloudformation/cloudformation-coverage-roadmap#322 |
The doc to me says can, but my understanding is that this is not defaulted. For example, I can create a kms key policy with For this reason I would propose a comment change
Setting this to
What is the benefit to the separation for this one? Also, the IAM permissions can change without much notice which leaves many docs in AWS out dated. For example, we are missing the I can get the name change up, 🏆 contender for longest property name in CDK. What are your final thoughts on custom resource and the permission separation above? If you are set with your initial position just drop that in a quick comment and I'll move on those. |
After reading up on the KMS docs some more this is what they more or less recommend themselves, after recognizing that they've made their permissions system hard to use. So I think I'm on board with your PR, with two changes:
|
Y'know what I have a hard time coming up with a better name. My current suggestion would be to pluralize, to Also interested in sourcing the opinions of my team mates, @eladb, @RomainMuller, @nija-at ? |
Nobody came to the bat signal. I confirmed that the right term for the policies is "Identity-based policy" (https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). In my mind, "identity policy" work as well. Let's try some alternatives:
|
I'll add one to the suggestion list - |
|
I'm looking at this holiday weekend to try to wrap this up, so the naming 🕐 isn't expired yet. Also I will not be offended if someone finishes this before me. |
When the boolean has been switched on, the |
I'm leaning towards I could see |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
…ccountIdentities for identity based kms key control
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@rix0rrr -- I changed the default admin policy to include what I think is the right administrative permissions. I've left GenerateDataKey only for backwards compatibility, but I strongly consider that a usage permission. As a result many tests down stream are breaking. If we don't want to make this policy change right now, then drop me a note so I can revert and avoid the pain of integ tests plus many other test updates. |
cc/ ⬆️ @nija-at |
Let's not make a breaking change right now, we can discuss that in a separate PR. |
Pull request has been modified.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Uhhh
|
Pull request has been modified.
Wow the system really doesn't want to cooperate with this one. |
Pull request has been modified.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
Thanks for the extra effort
…On Thu, Feb 20, 2020 at 6:29 AM mergify[bot] ***@***.***> wrote:
Merged #5575 <#5575> into master.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5575?email_source=notifications&email_token=AAFCFWGK2X4RSEZLSPVVOETRD2HTRA5CNFSM4KAYZW62YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWYWJH7Q#event-3056374782>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFCFWEF2OPLJE2MWZTCNDTRD2HTRANCNFSM4KAYZW6Q>
.
|
… (under feature flag) In #5575, a new flag (`trustAccountIdentities`) was introduced which -- when set -- changes the default key policy from a custom key admin policy to one that grants all access to the key to the root account user. This key policy matches the default policy when a key is created via the KMS APIs or console. For backwards-compatibility reasons, the default for `trustAccountIdentities` had to be set to `false`. Without the flag explicitly set, the default key policy is one that (a) doesn't match the KMS-recommended admin policy and (b) doesn't explicitly enable IAM principal policies to acccess the key. This means that all usage operations (e.g., Encrypt, GenerateDataKey) must be added to both the key policy and to the principal policy. This change introduces a new feature flag to flip the default behavior of the `trustAccountIdentities` flag, so new keys created will have the sane defaults matching the KMS recommended best practices. As a related change, this feature flag also changes the behavior when a user passes in `policy` when creating a Key. Without the feature flag set, the policy is always appended to the default key policy. With the feature flag set, the policy will *override* the default key policy, enabling users to opt-out of the default key policy to introduce a more restrictive policy if desired. This also matches the KMS API behavior, where a policy provided by the user will override the defaults. Marking this PR as `requires-two-approvers` to ensure this PR gets an appropriately-critical review. BREAKING CHANGE: change the default value of trustAccountIdentities to true, which will result in the key getting the KMS-recommended default key policy. This is enabled through the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag. fixes #8977 fixes #10575 fixes #11309
… (under feature flag) In #5575, a new flag (`trustAccountIdentities`) was introduced which -- when set -- changes the default key policy from a custom key admin policy to one that grants all access to the key to the root account user. This key policy matches the default policy when a key is created via the KMS APIs or console. For backwards-compatibility reasons, the default for `trustAccountIdentities` had to be set to `false`. Without the flag explicitly set, the default key policy is one that (a) doesn't match the KMS-recommended admin policy and (b) doesn't explicitly enable IAM principal policies to acccess the key. This means that all usage operations (e.g., Encrypt, GenerateDataKey) must be added to both the key policy and to the principal policy. This change introduces a new feature flag to flip the default behavior of the `trustAccountIdentities` flag, so new keys created will have the sane defaults matching the KMS recommended best practices. As a related change, this feature flag also changes the behavior when a user passes in `policy` when creating a Key. Without the feature flag set, the policy is always appended to the default key policy. With the feature flag set, the policy will *override* the default key policy, enabling users to opt-out of the default key policy to introduce a more restrictive policy if desired. This also matches the KMS API behavior, where a policy provided by the user will override the defaults. Marking this PR as `requires-two-approvers` to ensure this PR gets an appropriately-critical review. BREAKING CHANGE: change the default value of trustAccountIdentities to true, which will result in the key getting the KMS-recommended default key policy. This is enabled through the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag. fixes #8977 fixes #10575 fixes #11309
… (under feature flag) (#11918) In #5575, a new flag (`trustAccountIdentities`) was introduced which -- when set -- changes the default key policy from a custom key admin policy to one that grants all access to the key to the root account user. This key policy matches the default policy when a key is created via the KMS APIs or console. For backwards-compatibility reasons, the default for `trustAccountIdentities` had to be set to `false`. Without the flag explicitly set, the default key policy is one that (a) doesn't match the KMS-recommended admin policy and (b) doesn't explicitly enable IAM principal policies to acccess the key. This means that all usage operations (e.g., Encrypt, GenerateDataKey) must be added to both the key policy and to the principal policy. This change introduces a new feature flag to flip the default behavior of the `trustAccountIdentities` flag, so new keys created will have the sane defaults matching the KMS recommended best practices. As a related change, this feature flag also changes the behavior when a user passes in `policy` when creating a Key. Without the feature flag set, the policy is always appended to the default key policy. With the feature flag set, the policy will *override* the default key policy, enabling users to opt-out of the default key policy to introduce a more restrictive policy if desired. This also matches the KMS API behavior, where a policy provided by the user will override the defaults. Marking this PR as `requires-two-approvers` to ensure this PR gets an appropriately-critical review. BREAKING CHANGE: change the default value of trustAccountIdentities to true, which will result in the key getting the KMS-recommended default key policy. This is enabled through the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag. fixes #8977 fixes #10575 fixes #11309 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… (under feature flag) (aws#11918) In aws#5575, a new flag (`trustAccountIdentities`) was introduced which -- when set -- changes the default key policy from a custom key admin policy to one that grants all access to the key to the root account user. This key policy matches the default policy when a key is created via the KMS APIs or console. For backwards-compatibility reasons, the default for `trustAccountIdentities` had to be set to `false`. Without the flag explicitly set, the default key policy is one that (a) doesn't match the KMS-recommended admin policy and (b) doesn't explicitly enable IAM principal policies to acccess the key. This means that all usage operations (e.g., Encrypt, GenerateDataKey) must be added to both the key policy and to the principal policy. This change introduces a new feature flag to flip the default behavior of the `trustAccountIdentities` flag, so new keys created will have the sane defaults matching the KMS recommended best practices. As a related change, this feature flag also changes the behavior when a user passes in `policy` when creating a Key. Without the feature flag set, the policy is always appended to the default key policy. With the feature flag set, the policy will *override* the default key policy, enabling users to opt-out of the default key policy to introduce a more restrictive policy if desired. This also matches the KMS API behavior, where a policy provided by the user will override the defaults. Marking this PR as `requires-two-approvers` to ensure this PR gets an appropriately-critical review. BREAKING CHANGE: change the default value of trustAccountIdentities to true, which will result in the key getting the KMS-recommended default key policy. This is enabled through the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag. fixes aws#8977 fixes aws#10575 fixes aws#11309 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The default KMS policy is designed for two approaches:
containing IAM roles that will use the key (by adding a dependency)
The problem is that many AWS consumers do not allow or use IAM users. If you
also want to use infrastructure as code this style of management is difficult
because commonly Grants are used. Key grants are not supported directly in
CloudFormation, but do enable fine grain programmatic key control. Another
reason for this control policy is to prevent the ability for the root user
(which might be a shared credential for account admins) access to key usage
permisssions. Again, that issue is mitigated when consumers choose to follow the
best practice of never creating AWS Credentials for root users.
The second solution of stack dependencies creates a dependency challenge. The
stack with the KMS key must now be created after your stacks that have IAM
Roles that need to use the key. This can be very problematic if you want to use
default encryption on AWS S3 bucket and then create a second stack that has a
lambda function reading from this bucket. The lambda role needs permission to
the s3 bucket which isn't created before the role. Yes, resource ARN's can be
created for some resources that do not exist, but extremely counter intuitive
and many potential issues with custom resources.
The answer to these problems is to enable IAM policy control of the CMK as
described
here.
Since KMS keys, and specifically CMKs, should default to secure over
ergonomically pleasing the default option for IAM policy control is false. If a
user opts in via properties like below:
Then the kms key policy will be:
This would provide another solution for #5183 and reduce the likelihood of
hitting problems like #5190.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
Commit Message
feat(kms):
trustAccountIdentities
avoids cyclic stack dependenciesAdd a switch which will trust the entire account to use the key, subject to the identity policies of the identities making the calls (same as for all other AWS resources).
Since there is no way of updating a key policy after creating the key, AND bidirectional trust needs to be established between the resource and the identity, users are basically locked into creating both key and identities using the key in the same stack. The only way for cross-stack key usage where the key gets created first is by wildcarding. This switch allows that in an easy manner without introducing cyclic dependencies.