Summary
Every AWS deploy that creates a new KMS CMK is currently blocked:
Error: creating KMS Key: AccessDeniedException: User: arn:aws:sts::909626172446:assumed-role/cudly-terraform-deploy/GitHubActions
is not authorized to perform: kms:TagResource because no identity-based policy allows the kms:TagResource action
with module.compute_lambda[0].aws_kms_key.signing,
on ../../modules/compute/aws/lambda/signing-key.tf line 8
Root cause
terraform/modules/compute/aws/lambda/signing-key.tf creates aws_kms_key.signing with tags = merge(var.tags, {...}). Per the AWS KMS CreateKey API reference ("Required permissions"), using the Tags parameter on CreateKey requires kms:TagResource in addition to kms:CreateKey.
terraform/environments/aws/ci-cd-permissions/policy_compute.tf does grant kms:TagResource, but only inside the KMSMutateTaggedOnly statement, gated on:
Condition = { StringEqualsIgnoreCase = { "aws:ResourceTag/Project" = "CUDly" } }
aws:ResourceTag is evaluated against tags already attached to an existing resource. At CreateKey time the key doesn't exist yet, so there is no resource tag in the request context; this condition can never be satisfied by a create call. AWS authorizes tag-on-create via the aws:RequestTag/aws:TagKeys condition keys instead (confirmed against the current AWS IAM "Controlling access during AWS requests" guide and the KMS CreateKey example policy).
Blast radius
Every AWS deploy of the lambda compute platform that needs to (re)create the OIDC signing KMS key is blocked, including fresh environment bootstraps and any key replacement (e.g. a future key-spec migration like #1480's RSA->ECC move). This is a same-day, drop-everything blocker.
Fix
A new aws:RequestTag-gated kms:TagResource statement, scoped with an aws:ResourceTag Null condition so it can only apply to not-yet-tagged (i.e. genuinely new) keys, preventing it from being used to self-tag and then hijack an existing unrelated KMS key via the existing KMSMutateTaggedOnly statement.
Important: this fix does not take effect until a privileged human re-applies terraform/environments/aws/ci-cd-permissions/ — the CI deploy role cannot grant itself new IAM permissions.
Summary
Every AWS deploy that creates a new KMS CMK is currently blocked:
Root cause
terraform/modules/compute/aws/lambda/signing-key.tfcreatesaws_kms_key.signingwithtags = merge(var.tags, {...}). Per the AWS KMSCreateKeyAPI reference ("Required permissions"), using theTagsparameter onCreateKeyrequireskms:TagResourcein addition tokms:CreateKey.terraform/environments/aws/ci-cd-permissions/policy_compute.tfdoes grantkms:TagResource, but only inside theKMSMutateTaggedOnlystatement, gated on:aws:ResourceTagis evaluated against tags already attached to an existing resource. AtCreateKeytime the key doesn't exist yet, so there is no resource tag in the request context; this condition can never be satisfied by a create call. AWS authorizes tag-on-create via theaws:RequestTag/aws:TagKeyscondition keys instead (confirmed against the current AWS IAM "Controlling access during AWS requests" guide and the KMSCreateKeyexample policy).Blast radius
Every AWS deploy of the
lambdacompute platform that needs to (re)create the OIDC signing KMS key is blocked, including fresh environment bootstraps and any key replacement (e.g. a future key-spec migration like #1480's RSA->ECC move). This is a same-day, drop-everything blocker.Fix
A new
aws:RequestTag-gatedkms:TagResourcestatement, scoped with anaws:ResourceTagNullcondition so it can only apply to not-yet-tagged (i.e. genuinely new) keys, preventing it from being used to self-tag and then hijack an existing unrelated KMS key via the existingKMSMutateTaggedOnlystatement.Important: this fix does not take effect until a privileged human re-applies
terraform/environments/aws/ci-cd-permissions/— the CI deploy role cannot grant itself new IAM permissions.