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.
Description of changes:
Remove tagging update soft fail logic when a customer attempts to modify tags
so that customers know that they are missing tagging permissions, and that their tagging update failed
We currently ignore all access denied errors during tagging updates. This means that when a customer is missing tagging permissions, and they update their resource tags in their CFN template, the operation will appear to succeed, when it really failed due to an access denied exception. Soft failing is required so that we do not break customers that created their resources prior to the tagging feature being added to the Key resource. Instead of always soft failing, we should selectively soft fail, only when the customer has not requested any updates to their tags. We should be able to do this by comparing the current resource model with the previous resource model that is provided in our Key handler’s context.
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: N/A
Description of changes: Remove tagging update soft fail logic when a customer attempts to modify tags so that customers know that they are missing tagging permissions, and that their tagging update failed
We currently ignore all access denied errors during tagging updates. This means that when a customer is missing tagging permissions, and they update their resource tags in their CFN template, the operation will appear to succeed, when it really failed due to an access denied exception. Soft failing is required so that we do not break customers that created their resources prior to the tagging feature being added to the Key resource. Instead of always soft failing, we should selectively soft fail, only when the customer has not requested any updates to their tags. We should be able to do this by comparing the current resource model with the previous resource model that is provided in our Key handler’s context.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.