sops_decrypt_file failed: error decrypting key - AccessDeniedException on kms:Decrypt

TL;DR: The run is trying to decrypt a KMS key in another account or region, and your role isn't allowed to. This almost always means stack discovery walked into an environment you shouldn't be parsing. Scope the run to your environment; don't widen KMS access to fix a discovery problem.

ERROR  Call to function "sops_decrypt_file" failed:
ERROR  * error decrypting key: ... arn:aws:kms:[region]:[account]:key/[key id]:
ERROR    AccessDeniedException: User: arn:aws:sts::[caller account]:assumed-role/[ci role]/...
ERROR    is not authorized to perform: kms:Decrypt on the resource ... because the resource
does not exist in this Region, no resource-based policies allow access, or a
resource-based policy explicitly denies access

Steps

1. Identify whose key it is: the key ARN's account/region vs your role's account.

Expected: it's another environment's key (e.g. prod key while you work in dev).

1. Check whether the run should be parsing that environment at all. If not, narrow discovery with --filter so the runner pool stays in your environment.

Expected: the foreign sops_decrypt_file is never evaluated.

1. If the run LEGITIMATELY needs that environment's secrets, grant your role kms:Decrypt on that key (key policy or IAM policy) in the right region.

Expected: decryption succeeds.

1. Re-run.

Expected: no more AccessDenied.

When this applies

• sops_decrypt_file fails naming a KMS key ARN in a different account or region.
• CI roles are scoped per-account/per-environment.

When it doesn't apply

• Age-based SOPS (no KMS involved): check the age key file / SOPSAGEKEY env var instead.
• The key is in YOUR account and region: then it's a genuine policy gap; add the kms:Decrypt grant.

Tool versions

All Terragrunt versions with sops_decrypt_file.

Why it happens

sops_decrypt_file evaluates at config-parse time, so merely discovering a unit decrypts its secrets. A per-account CI role hitting another account's key gets AccessDenied before Terragrunt ever decides whether that unit was in scope.

Edge cases

• "does not exist in this Region" sometimes literally means region mismatch: the key exists, but your SDK is pointed at the wrong region. Check AWS_REGION before rewriting policies.
• KMS grants are eventually consistent; a just-added grant can still AccessDenied for a few minutes.