grantSendMessages of encrypted SQS to Lambda function not generating kms:Decrypt permission

[aherzog-trx]

General Issue

We deployed a SQS queue to Account-A that is encrypted with a CMK that resides in Account-B. Permissions of CMK are set to grant allow kms:* to AccountPrincipal('Account-A').
Then we instantiate ourLambda function that is granted write permissions to ourQueue using ourQueue.grantSendMessages(ourLambda).

const sqsKey = Key.fromKeyArn('arn:aws:kms:eu-central-1:0987654321:key/ourKeyId');

const ourQueue = new Queue(this, 'OurQueue', {
    encryption: QueueEncryption.KMS,
    encryptionMasterKey: sqsKey
});

const ourLambda = new Function(this, 'OurLambda', {...});

ourQueue.grantSendMessages(ourLambda);

This results in

"Action": [
    kms:Encrypt",
    kms:ReEncrypt*",
    kms:GenerateDataKey*"
],
"Resource": "arn:aws:kms:eu-central-1:0987654321:key/ourKeyId",
"Effect": "Allow"

being added to ourLambdaExecutionRoleDefaultPolicy.

Lambda function execution failed with KMS AccessDeniedException when sending a message to ourQueue.

After adding

sqsKey.grantDecrypt(ourLambda);

the lambda function executes successfully.

The Question

Is kms:Decrypt strictly necessary to execute sendMessage to an SSE enabled SQS queue? Is this due to the CMK residing in a seperate AWS account?
If so, should kms:Decrypt be added to the Lambda execution role policy when Queue.grantSendMessage(Lambda) is used?

Environment

• CDK CLI Version: 1.27.0 (build a98c0b3)
• Module Version: 1.27.0
• OS: Windows 10
• Language: TypeScript

Other information

Thanks for the good work!

[MrArnoldPalmer]

Good catch!
After some reading it looks like that accounts in other accounts require the kms:GenerateDataKey* to write to an encrypted queue.

My instinct is to automatically add this permission in the role passed to grantSendMessage when the queue is encrypted and in another account (I think we can detect this reliably).

Other option is to make sure this is documented somewhere that users who need it are going to find it. Probably both.

@rix0rrr knows some about this and may have some opinions.

[rix0rrr]

I think this is about the Lambda reading from the queue, right, rather than having to do with grantSendMessages() ?

[aherzog-trx]

The Lambda writing to the queue failed until we added

"Action": [
    kms:Decrypt"
],
"Resource": "arn:aws:kms:eu-central-1:0987654321:key/ourKeyId",
"Effect": "Allow"

to the Lambda's ExecutionRoleDefaultPolicy.

[ishassan]

I have the same issue.

Apparently grantSendMessage() isn't enough to send encrypted messages. You'd need to allow kms:Decrypt as well, which doesn't make a lot of sense to me.

[shreyasdamle]

Does kms:Decrypt action is required for every instance of grantSendMessage() to send encrypted messages or is it just required when CMK is in another account?

If it only requires for the second case, can we check if key is from the different account before granting kms:Decrypt permission for grantSendMessage() with something like this:

private isKeyFromAnotherAccount(key: kms.IKey): boolean {
  if (!(Construct.isConstruct(key))) {
    return false;
  }
  const bucketStack = Stack.of(this);
  const identityStack = Stack.of(key);
  return bucketStack.account !== identityStack.account;
}

[ishassan]

In my case, everything is in the same account, yet a decrypt permission is still required to send messages.