AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
Alias CreateHandler is currently non-idempotent. If a transient error causes the CreateHandler to be retried after it already called CreateAlias, then all retries will fail will AlreadyExists errors.
This change follows CFN's recommendation fix for the non-idempotent behavior when an API doesn't support ClientToken parameters for idempotency. The strategy is to do a DescribeKey request on the alias prior to creation to verify whether it is pre-existing or not. If the alias exists, fail with AlreadyExists. If the alias does not exist, then mark in callback context that the pre-create check was done, and proceed to call CreateAlias (and retry any AlreadyExists errors from the API).
This change requires no new KMS permissions to call DescribeKey. This is because AccessDenied and a successful DescribeKey response are both indicators of an alias's existence within the same account of a caller.
Testing
Verified expected behavior by creating stacks with new/re-used aliases using a role with/without DescribeKey permissions.
cfn submit --set-default --no-role -v
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available: Internal
Description of changes
Alias CreateHandler is currently non-idempotent. If a transient error causes the CreateHandler to be retried after it already called CreateAlias, then all retries will fail will AlreadyExists errors.
This change follows CFN's recommendation fix for the non-idempotent behavior when an API doesn't support ClientToken parameters for idempotency. The strategy is to do a DescribeKey request on the alias prior to creation to verify whether it is pre-existing or not. If the alias exists, fail with AlreadyExists. If the alias does not exist, then mark in callback context that the pre-create check was done, and proceed to call CreateAlias (and retry any AlreadyExists errors from the API).
This change requires no new KMS permissions to call DescribeKey. This is because AccessDenied and a successful DescribeKey response are both indicators of an alias's existence within the same account of a caller.
Testing
Verified expected behavior by creating stacks with new/re-used aliases using a role with/without DescribeKey permissions.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.