MemberMarch 20, 2022 at 2:14 am
I have an issue with the answers/explanation of one question.
The answer states “Create a customer-managed KMS key using the Bring Your Own Key (BYOK) feature and store it in AWS CloudHSM.”, but according to AWS documentation (https://docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html) “Importing key material into KMS keys” is NOT supported when using custom key stores (CloudHSM).
Even the link your provide in the description (https://aws.amazon.com/blogs/security/how-to-byok-bring-your-own-key-to-aws-kms-for-less-than-15-00-a-year-using-aws-cloudhsm/) explains a solution where you create the key material in cloudhsm then imported via BYOK to KMS and then delete the CloudHSM cluster, so finally the key is NOT stored on CloudHSM.
Provided that the question states “Federal Information Processing Standards (FIPS) 140-2 Level 3” (meaning key should be stored in CloudHSM), could you change the accepted answer to something stating that the key is created in CloudHSM and not imported to KMS using BYOK.
Please correct me if I have understood something wrong.
- This discussion was modified 1 year, 11 months ago by konker.
AdministratorMarch 22, 2022 at 3:46 am
Thanks for your feedback.
Your understanding of custom key stores is correct. There are 3 key origins to choose from when creating a KMS key: KMS, External (import your own), and custom key store (CloudHSM). When I created this question, I imagined a scenario in which KMS keys are to be generated from key materials generated by a CloudHSM cluster — a setup similar to the one described in this blog, except that the cluster is to be maintained rather than deleted. This is technically possible, but it foregoes the advantage of easy integration with other services such as Amazon S3. So the best possible answer in the scenario’s case is to just create a CloudHSM-backed KMS key. We will revise this item.
Let me know if you have further questions.
Carlo @ Tutorials Dojo
Log in to reply.