-
Notifications
You must be signed in to change notification settings - Fork 4.3k
feat(kms): Adds support for hmac and sm2 key spec #23866
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
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
Great to see another PR on this issue. There are a few differences :-) I viewed the code and have a few remarks:
I like the fact that your PR is a lot simpler than mine. I had to go through changing the context provider for kms keys which leads to all kinds of trouble... |
@Jacco What a coincidence that we both have pushed this in the same time. Thank you very much for the valuable feedback. I agree that the grantVerify and grantGenerate methods do not check if the key is a HMAC one. But I'm not sure if I have to throw an error since the methods specifically tell what's happening and do not hide something. I guess the overhead in code/logic is not worth the benefit. In the end the policy is just extended. Regarding the check of the key rotation I just wanted to have a good error message :-) And regarding the default usage I think this is a very good idea and I will definitely add this to the code. Thanks again! ❤️ |
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.
Usually I only provide feedback on the older PR when there's a duplicate, but since y'all are conversing on this issue, I'm going to provide feedback on both so that maybe in collaboration we can come to a better solution.
Just one comment inline but it has pretty major repercussions on the PR. Let me know what you think, please.
@@ -966,16 +967,40 @@ describe('key specs and key usages', () => { | |||
}); | |||
}); | |||
|
|||
test('invalid combinations of key specs and key usages', () => { | |||
test.each([ |
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.
This really concerns me. I know you didn't write this original contract but this many invalid options that won't be discovered until synth time makes me uneasy. Is there a contract update we can make here to enforce the valid combos better?
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.
Maybe it would be better to create a separate class for Hmac keys? Maybe there actually should be a few classes:
SymmetricKey
- only one to have enableKeyRotation in props
- usage is always ENCRYPT_DECRYPT
HmacKey
- usage is always GENERATE_VERIFY_MAC
ShaKey
- usage is always SIGN_VERIFY
RsaKey
- usage options SIGN_VERIFY or ENCRYPT_DESCRYPT
But also the base needs some (breaking?) refactorings because I think a key that has no ENCRYPT_DECRYPT usage should not have grantDescrypt/grantEncrypt methods.
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.
@Jacco How can we ensure backwards compatibility with this separation?
When someone upgrades to a potential version with a class for each key, how will the Basic Key class behave?
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.
@TheRealAmazonKendra Do you mean extending the tests to make the invalid combinations clearer? Or changing the logic inside the production code?
Maybe it would be better to create a separate class for Hmac keys? Maybe there actually should be a few classes: SymmetricKey
HmacKey
ShaKey
RsaKey
But also the base needs some (breaking?) refactorings because I think a key that has no ENCRYPT_DECRYPT usage should not have grantDescrypt/grantEncrypt methods. |
@daschaa yeah I know, will be hard. Maybe in a new package? aws-kms-v2? I actually haven't seen anything like that happening in the cdk project. |
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
Pull request has been modified.
@TheRealAmazonKendra I have changed the tests so that a test case for every deny list entry is added. It's not yet perfect, because I decided to not export the deny list from the I'm looking forward for your feedback and I hope I understood your review correctly 😄 |
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.
I agree that the grantVerify and grantGenerate methods do not check if the key is a HMAC one. But I'm not sure if I have to throw an error since the methods specifically tell what's happening and do not hide something. I guess the overhead in code/logic is not worth the benefit. In the end the policy is just extended.
I would like to hear a third opinion from someone of the CDK Team on this - I'm not sure what's best practice.
So usually if we have the ability to detect an incompatible combination during synth, than we will and throw an error. So if the user is able to call grantGenerateMac
and grantVerifyMac
on keys where that policy doesn't make sense, I do think we should throw an error there.
Otherwise I feel like this looks pretty good. Agreed that invalid combination issue is annoying and would be nice if we could fix but I don't see a way without breaking changes. |
Pull request has been modified.
@MrArnoldPalmer I added a guard statement to the |
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.
Just a leftover console.log and a question.
Pull request has been modified.
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.
Looks good, thank you @daschaa
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Fixes aws#23727 I have not added an integration test for SM2 because i can not deploy in the China Region. ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Construct Runtime Dependencies: * [ ] This PR adds new construct runtime dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Fixes #23727
I have not added an integration test for SM2 because i can not deploy in the China Region.
All Submissions:
Adding new Construct Runtime Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license