Skip to content
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

fix(KeyStoreAdmin): Exceptions for Mutations when KMS Key is Disabled #1235

Open
wants to merge 2 commits into
base: mutations/mutations
Choose a base branch
from

Conversation

texastony
Copy link
Contributor

Issue #, if available:

Description of changes:

If the KMS Key involved in a Mutation is deleted or disabled,
along with any number of other KMS exceptions,
the Key Store Admin should attempt to classify the exception as To or From Mutation Exception,
rather than a generic Key Store Admin Exception.

Squash/merge commit message, if applicable:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@texastony texastony force-pushed the mutations/mutations branch 2 times, most recently from bc983e7 to 2fc52ac Compare January 22, 2025 18:47
@texastony texastony force-pushed the mutations/fix-kms-key-disabled-deleted-error branch from 4f44f76 to 3235093 Compare January 23, 2025 00:23
@texastony texastony force-pushed the mutations/fix-kms-key-disabled-deleted-error branch from a7ec15a to f180e85 Compare January 31, 2025 01:02
@texastony texastony marked this pull request as ready for review February 3, 2025 21:05
@texastony texastony requested a review from a team as a code owner February 3, 2025 21:05
Copy link
Contributor

@RitvikKapila RitvikKapila left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left one comment and one nit.

Comment on lines 149 to 150
message := "Invalid response from KMS GenerateDataKey:: Invalid Key Id")
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: We should make both these messages consistent.

Suggested change
message := "Invalid response from KMS GenerateDataKey:: Invalid Key Id")
);
message := "Invalid response from AWS KMS GenerateDataKey:: Invalid Key Id")
);

Comment on lines +105 to 106
returns (res: Result<KMS.GenerateDataKeyWithoutPlaintextResponse, KmsError>)
requires kmsClient.ValidState()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, this is a breaking change right?


}
}
if (kmsWithMsg) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both this and the last case in the if (kmsWithMsg && knownKmsStrat) { block (which never happens) indicate that the statement (kmsWithMsg && knownKmsStrat) { is always true so long as kmsWithMessage is true. We return some exception in each case. Are you sure that the error messages won't overlap? For instance, this line:

var hasEncrypt? := String.HasSubString(kmsErrorMessage?.value, "Encrypt");
Wouldn't this interfere with:

else if (hasTerminalArn?.Some?) {
        return Types.MutationToException(
            message := "Key Management denied access to the terminal KMS Key."
            + " Mutation is halted. Check encrypt access to KMS ARN: " + terminalKmsArn + "."
            + "\n" + errorContext
          );

Example -- If the KMS Message has hasTerminalArn? as true, and the message says you don't have Encrypt permissions, wouldn't this be returned in

case "Decrypt/Encrypt" =>

rather than

else if (hasTerminalArn?.Some?) {

I am also concerned that if all the if blocks in all the cases in

match kmsOperation {

are exhaustive, Line 194:

    if (kmsWithMsg) {

will never be triggered because in the previous if block (kmsWithMsg && knownKmsStrat) {, knownKmsStrat is always true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants