feat(kms): `trustAccountIdentities` avoids cyclic stack dependencies #5575

moofish32 · 2019-12-29T08:07:49Z

The default KMS policy is designed for two approaches:

IAM User based key administration
Situations in which the stack containing the key is created after the stacks
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:

    new Key(stack, 'MyKey', {enablePolicyControl: true});

Then the kms key policy will be:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": "kms:*",
  "Resource": "*"
}

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 dependencies

Add 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.

moofish32

naming is difficult, and I'm not sure I have it right yet for this property.

moofish32 · 2019-12-29T08:11:06Z

packages/@aws-cdk/aws-kms/lib/key.ts

+   *
+   * @default false
+   */
+  readonly enablePolicyControl?: boolean;


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.

moofish32 · 2019-12-29T08:11:35Z

packages/@aws-cdk/aws-kms/lib/key.ts

+    const actions = enablePolicyControl ?
+      ['kms:*'] :
+      [
+        "kms:Create*",


these permissions are un-altered just moved.

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-cdk-automation · 2019-12-29T08:41:55Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

solshark · 2019-12-29T10:40:09Z

Looking very much forward for this.

rix0rrr · 2020-01-02T12:35:27Z

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 allowAccountToAdmin(). I'd rather see a new method. To me it seems like the change comes down to the following:

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 key.grantDecrypt()?

The same could be achieved by use of addToResourcePolicy() after creating the key, or we could even have a wrapper for it:

key.grantUsageToAnyoneInThisAccount();

Which looks appropriately scary.

If the problem is about downstream consumers, a better alternative would be to make a custom resource KeyPolicy which behaves in the same way as AWS::S3::BucketPolicy and AWS::SQS::QueuePolicy, which can be attached from a downstream stack (or we can petition CloudFormation to add this 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, AWS:arn:aws:iam::123456789012:root (and also AWS:123456789012) mean the latter. Or is this is a difference in KMS vs other services?

rix0rrr · 2020-01-02T12:43:57Z

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:

One to allow anyone to manage
One to allow anyone to use

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;

rix0rrr · 2020-01-02T12:58:35Z

Created a feature request for CloudFormation: aws-cloudformation/cloudformation-coverage-roadmap#322

moofish32 · 2020-01-03T09:41:48Z

(*) 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, AWS:arn:aws:iam::123456789012:root (and also AWS:123456789012) mean the latter. Or is this is a difference in KMS vs other services?

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 kms:* on resources [*] to arn:aws:iam::123456789012:root. If I create a role for a lambda function and do not include any kms key permissions, then lambda will not be able to use the key.

For this reason I would propose a comment change

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

Setting this to true adds a default statement which delegates
key access control completely to the identity's IAM policy
(similar to how it works for other AWS resources).

I'd still like to see this as an additive operator to the existing key management policy. There will be 2 statements:

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 ImportKeyMaterial, TagResource, & UntagResource for management. GenerateDataKey I would think is key usage, but perhaps there is some dependency I don't know about. If we are opting into IAM management is there a new permission that we would not want to manage? I will implement which ever path the you want here.

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.

rix0rrr · 2020-01-03T15:11:21Z

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:

I'd rather have 2 private methods to add the statements, rather than that argument to the current method.
Not a fan of the property names you've suggested or the one I came up with. Let's see if we can find a better one.

rix0rrr · 2020-01-03T15:15:25Z

Y'know what I have a hard time coming up with a better name. My current suggestion would be to pluralize, to controlAccessViaIdentityPoliciesAlone which I feel is slightly more correct.

Also interested in sourcing the opinions of my team mates, @eladb, @RomainMuller, @nija-at ?

rix0rrr · 2020-01-15T10:05:26Z

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:

controlAccessViaIdentityPoliciesAlone
onlyNeedIdentityPolicy
permissiveKeyPolicy
... ?

nija-at · 2020-01-15T10:35:01Z

controlAccessViaIdentityPoliciesAlone does sound a bit long.

I'll add one to the suggestion list - identityPolicyAccessControl

rix0rrr · 2020-01-15T10:53:33Z

trustAccount
trustAccountIdentities

moofish32 · 2020-01-15T21:57:25Z

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.

rix0rrr · 2020-01-17T08:56:17Z

When the boolean has been switched on, the grant...() methods need to switch on that boolean to avoid adding resource policy statements. We then need to switch to Grant.addToIdentityOrResource isntead of addToIdentityAndResource.

moofish32 · 2020-01-20T05:34:55Z

trustAccount

trustAccountIdentities

I'm leaning towards trustAccountIdentities

I could see trustAccountIdentityPolicies but I preferred the shorter because identities have to have policies.

aws-cdk-automation · 2020-01-20T05:57:51Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

…ccountIdentities for identity based kms key control

aws-cdk-automation · 2020-01-20T08:02:13Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

aws-cdk-automation · 2020-01-20T17:15:30Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

moofish32 · 2020-01-20T21:07:56Z

@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.

moofish32 · 2020-01-20T21:08:34Z

cc/ ⬆️ @nija-at

rix0rrr · 2020-01-24T13:36:52Z

Let's not make a breaking change right now, we can discuss that in a separate PR.

Pull request has been modified.

aws-cdk-automation · 2020-02-18T23:45:06Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 55a28be
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

mergify · 2020-02-19T09:32:55Z

Thank you for contributing! Your pull request is now being automatically merged.

aws-cdk-automation · 2020-02-19T10:12:04Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 965c402
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

aws-cdk-automation · 2020-02-19T10:15:35Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 86a38b1
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

rix0rrr · 2020-02-19T14:51:16Z

Uhhh

npm ERR! notarget No matching version found for @aws-cdk/[email protected].

Pull request has been modified.

rix0rrr · 2020-02-20T10:38:22Z

Wow the system really doesn't want to cooperate with this one.

Pull request has been modified.

aws-cdk-automation · 2020-02-20T11:22:03Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: 99aad54
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

mergify · 2020-02-20T13:09:01Z

Thank you for contributing! Your pull request is now being automatically merged.

aws-cdk-automation · 2020-02-20T13:51:42Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: e26d6dd
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

aws-cdk-automation · 2020-02-20T14:28:41Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
Commit ID: ad75758
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

mergify · 2020-02-20T14:29:08Z

Thank you for contributing! Your pull request is now being automatically merged.

moofish32 · 2020-02-20T15:57:38Z

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) (#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*

feat(kms): add property to enable IAM policy key administration

b8f3066

moofish32 requested a review from rix0rrr as a code owner December 29, 2019 08:07

moofish32 commented Dec 29, 2019

View reviewed changes

SomayaB assigned rix0rrr Dec 30, 2019

rix0rrr requested review from eladb and nija-at January 3, 2020 15:15

Merge branch 'master' into feature/kms-iam-control

b438544

fix: update key policies to include admin functions, rename to trustA…

0232fc1

…ccountIdentities for identity based kms key control

moofish32 added 2 commits January 20, 2020 09:06

fix(s3): updating bucket tests for new default kms key policy

0a145c3

Merge branch 'master' into feature/kms-iam-control

da6c461

rix0rrr previously approved these changes Feb 19, 2020

View reviewed changes

mergify bot added 2 commits February 19, 2020 09:34

Merge branch 'master' into feature/kms-iam-control

86a38b1

Merge branch 'master' into feature/kms-iam-control

965c402

Merge branch 'master' into feature/kms-iam-control

74d379e

Merge branch 'master' into feature/kms-iam-control

99aad54

rix0rrr previously approved these changes Feb 20, 2020

View reviewed changes

rix0rrr approved these changes Feb 20, 2020

View reviewed changes

mergify bot added 2 commits February 20, 2020 13:09

Merge branch 'master' into feature/kms-iam-control

e26d6dd

Merge branch 'master' into feature/kms-iam-control

ad75758

mergify bot merged commit 03f4ef2 into aws:master Feb 20, 2020

njlynch mentioned this pull request Dec 7, 2020

feat(kms): change default key policy to align with KMS best practices (under feature flag) #11918

Merged

feat(kms): trustAccountIdentities avoids cyclic stack dependencies #5575

feat(kms): trustAccountIdentities avoids cyclic stack dependencies #5575

Conversation

moofish32 commented Dec 29, 2019 • edited by rix0rrr Loading

Commit Message

moofish32 left a comment

Choose a reason for hiding this comment

moofish32 Dec 29, 2019

Choose a reason for hiding this comment

moofish32 Dec 29, 2019

Choose a reason for hiding this comment

moofish32 Dec 29, 2019

Choose a reason for hiding this comment

aws-cdk-automation commented Dec 29, 2019

AWS CodeBuild CI Report

solshark commented Dec 29, 2019

rix0rrr commented Jan 2, 2020

rix0rrr commented Jan 2, 2020 • edited Loading

rix0rrr commented Jan 2, 2020

moofish32 commented Jan 3, 2020

rix0rrr commented Jan 3, 2020

rix0rrr commented Jan 3, 2020

rix0rrr commented Jan 15, 2020

nija-at commented Jan 15, 2020

rix0rrr commented Jan 15, 2020

moofish32 commented Jan 15, 2020

rix0rrr commented Jan 17, 2020

moofish32 commented Jan 20, 2020

aws-cdk-automation commented Jan 20, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented Jan 20, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented Jan 20, 2020

AWS CodeBuild CI Report

moofish32 commented Jan 20, 2020

moofish32 commented Jan 20, 2020

rix0rrr commented Jan 24, 2020

aws-cdk-automation commented Feb 18, 2020

AWS CodeBuild CI Report

mergify bot commented Feb 19, 2020

aws-cdk-automation commented Feb 19, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented Feb 19, 2020

AWS CodeBuild CI Report

rix0rrr commented Feb 19, 2020

rix0rrr commented Feb 20, 2020

aws-cdk-automation commented Feb 20, 2020

AWS CodeBuild CI Report

mergify bot commented Feb 20, 2020

aws-cdk-automation commented Feb 20, 2020

AWS CodeBuild CI Report

aws-cdk-automation commented Feb 20, 2020

AWS CodeBuild CI Report

mergify bot commented Feb 20, 2020

moofish32 commented Feb 20, 2020 via email

feat(kms): `trustAccountIdentities` avoids cyclic stack dependencies #5575

feat(kms): `trustAccountIdentities` avoids cyclic stack dependencies #5575

moofish32 commented Dec 29, 2019 •

edited by rix0rrr

Loading

rix0rrr commented Jan 2, 2020 •

edited

Loading