Kinesis Stream encryption should support the Master Kinesis key

[ccurrie-amzn]

The L1 construct for Kinesis Stream accepts a string KeyId which can be any of arn, guid, or alias. The L2 construct only supports a keyArn, which hinders the use of Amazon-managed aliases such as alias/aws/kinesis.

This may be a change to EncryptionKey more than Kinesis, as EncryptionKey may need to understand the special nature of alias/aws keys, and make changes to such keys a no-op.

[rix0rrr]

Your issue may be solved in the latest release (0.9.2), as all attributes types have disappeared and are replaced with string.

That's not so say that EncryptionKey should not be smarter. Do you think we should model service default keys explicitly?

[ccurrie-amzn]

I expect you will be forced to; the L2 constructs are helpful in adding permissions to the resource policy for keys when required, but I suspect that will likely fail for service default keys.

[ccurrie-amzn]

I have retested this with 0.10, and it does break the stack build when trying to use the service default keys:

    const key = EncryptionKeyRef.import(this, "SystemKey", {
      keyArn: "alias/aws/kinesis"
    });

    const stream = new Stream(this, "EncryptedStream", {
      encryption: StreamEncryption.Kms,
      encryptionKey: key
    });

    const func = new Function(this, "Lambda", {
      code: Code.directory("dist"),
      handler: "lib/index.handler",
      runtime: Runtime.NodeJS810,
    });

    stream.grantRead(func.role);

This ultimately generates a PolicyStatement on the function role in the form:

-
  Action: 'kms:Decrypt'
  Effect: Allow
  Resource: alias/aws/kinesis

Which fails with the error: Resource alias/aws/kinesis must be in ARN format or "*".

1. I can work around this problem by changing the EncryptionKeyRef to:

    const key = EncryptionKeyRef.import(this, "SystemKey", {
      keyArn: new FnJoin(":", [
        "arn:aws:kms",
        new AwsRegion(),
        new AwsAccountId(),
        "alias/aws/kinesis"
      ]).toString(),
    });

2. That said, IIUC the PolicyStatement is not needed for system keys, and making policy mods to the key itself may not be allowed.

[lambrospetrou]

Are there plans to support this before the 1.0 release is out? We are creating lots of streams in my team and without this we had to fallback to the CfnStream construct and use the raw StreamEncryption that provides keyId.

In addition, in CfnStream the links to StreamEncryptionProperty are broken.

Thanks

[skinny85]

Now that Alias implements IKey, and can be used anywhere a KMS key can, is this issue now solved?

@lambrospetrou @ccurrie-amzn ?

[ccurrie-amzn]

We haven't updated the system that encountered this issue to the latest CDK, so it will be some time before I can verify that the use case is covered; that said, the fragment above isn't large, so perhaps I or someone else can rewrite it in the new syntax and verify the Cfn output.