(aws-kms): grant permission not working for kms keys imported from alias name

[dannysteenman]

Describe the bug

When I import the kms key from alias name e.g. const snsKeyAlias = kms.Alias.fromAliasName(this, 'awsSnsKeyAlias', 'awsSnsTopicKey');

and want to grant my ecs task role km decrypt permission e.g.

snsKeyAlias.grantEncryptDecrypt(purchaseService.taskDefinition.taskRole);

The policy of the task role isn't updated with the kms decrypt permission.

Expected Behavior

I expect it to add the permission to the policy. For example, when I import the key from arn it works e.g.

const snsKeyArn = kms.Key.fromKeyArn(this, 'awsSnsKey', 'arn:aws:kms:eu-west-1:012345678901:key/');

Then grant permission like so: snsKeyArn.grantDecrypt(purchaseService.taskDefinition.taskRole);

Current Behavior

.

Reproduction Steps

Run the examples I supplied in the previous two paragraphs.

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.18.0

Framework Version

No response

Node.js Version

v16.14.2

OS

MacOS

Language

Typescript

Language Version

4.6.3

Other information

No response

[skinny85]

Hi @dannysteenman,

thanks for opening the issue. This most likely stems from the fact that you can't use Aliases in IAM Policies - only the Key can be used in those.

Thanks, Adam

[dannysteenman]

Thanks for the response! I understand that you can't use an alias in a policy but it would be nice if cdk can translate it and turn it into an arn for the policy since cdk knows the arn of the imported keyalias.

The reason for this request is the following: I got multiple stages where I deploy kms keys and I'm adding a predictable keyalias for each stage so I can easily import it in another cdk app and apply conditions to my code to choose the proper key based on the stage.

Now I need to copy the arn of each stage and put it in the code which makes it way more cumbersome and less human readable. If you need an example, please let me know.

[skinny85]

Unfortunately, I don't think there's anything we can do here. Remember that CDK doesn't do any service calls when using methods like fromAliasName(), so there's no way to find out the ARN of the Key just based on the Alias.

Any reason you need to share the Keys between multiple CDK apps? If you managed the Keys in the same app as uses them, you wouldn't run into this problem.

[skinny85]

I'm resolving this one, please comment if you need anything else from our side.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[kamzil]

How is this resolved? Why can't this code

const keyAlias = Alias.fromAliasName(this, 'my-key-alias', 'my/key/alias')
keyAlias.grantDecrypt(lambdaFunc)

function as a short-hand for:

lambdaFunc.role?.addToPrincipalPolicy(
  new PolicyStatement({
    actions: [
      "kms:Decrypt",
    ],
    resources: ['*'],
    conditions: {
      StringEquals: {
        "kms:RequestAlias": "my/key/alias",
      },
    },
  }),
)

?

Why would this need any service calls?

[skinny85]

@kamzil you can't do that, because you cannot use Key aliases in IAM policies. Only Key ARNs.

[bruecktech]

This information may be outdated. It is possible to use kms:ResourceAlias now. See the docs here.
It allows controlling access to KMS keys based on the alias configured on the key no matter how the key is accessed (alias, arn, ID). So it would be great if keyAlias.grant... would translate to the respective policies including the conditions.

[snorberhuis]

This issue is related: https://github.com/aws/aws-cdk/issues/22697

[avoidik]

could you please consider to reopen this issue?