misleading property name: AWS::Logs::LogGroup.KmsKeyId

[tcheksa62]

Hello,

I got problem when I use this template to deploy KMSKey, KMSAlias and CW LogGroup :

Resources:
  KMSKey:
    Type: 'AWS::KMS::Key'
    Properties: 
      Description: KMS for CloudWatch Log group
      Enabled: true
      KeyPolicy: 
        Version: '2012-10-17'
        Id: key-default-1
        Statement:
        - Sid: Enable IAM User Permissions
          Effect: Allow
          Principal:
            AWS: !Sub arn:aws:iam::${AWS::AccountId}:root
          Action: kms:*
          Resource: '*'
        - Sid: Enable CWL Permissions
          Effect: Allow
          Principal:
            Service: !Sub logs.${AWS::Region}.amazonaws.com
          Action:
          - kms:Describe*
          - kms:Encrypt*
          - kms:Decrypt*
          - kms:ReEncrypt*
          - kms:ReEncrypt*
          Resource: '*'

  KMSAlias:  
    Type: 'AWS::KMS::Alias'
    Properties: 
      AliasName: alias/CloudWatchLogKMS
      TargetKeyId: !Ref KMSKey     
  LogMessage:
    Type: 'AWS::Logs::LogGroup'
    Properties: 
      LogGroupName: /var/log/messages
      RetentionInDays: 365
      KmsKeyId: !Ref KMSKey

Error message : Model validation failed (#/KmsKeyId: failed validation constraint for keyword [pattern])

In the doc of "AWS::KMS::Key" resource, return value is key ID. But "AWS::Logs::LogGroup" wait an ARN not a KeyID. The param himself if ambiguous "KmsKeyId" but in reality is KmsKeyArn

My workaround is to use "Fn::GetAtt" instead of Ref : KmsKeyId: !GetAtt KMSKey.Arn

Regards, Tcheksa

[PatMyron]

The param himself if ambiguous "KmsKeyId" but in reality is KmsKeyArn

Agreed, this problem stems from CreateLogGroup API naming itself. Unfortunately, we have to continue supporting that naming at this point, but the reference documentation for AWS::Logs::LogGroup.KmsKeyId has a note on this as well

[benbridts]

The API has the same problem, so the person who wrote the implementation copied that instead of thinking about how to make it better for CloudFormation users (and they will try to do better next time).

I know that "it's frustrating for everyone" doesn't really solve the issue.