sops file failed to decrypt in ci: key mismatch error

Not specified by the original author.

TL;DR

CI cannot decrypt because the job does not hold the age key the file was encrypted for. Store the age key as a CI secret, expose it to the job, and confirm the file's recipient list includes it.

Error

sops file failed to decrypt in ci: key mismatch error

Steps

1. Compare the file's recipients against the key available in CI. Expected: the mismatch identified.
2. Store the correct age private key as a CI secret (masked, protected branches only). Expected: the key is available to jobs.
3. Expose it to the sops step through the CI's secret-to-env mapping. Expected: sops can read the key.
4. If the CI key is not a recipient, have a recipient re-encrypt adding it. Expected: the file lists the CI key.
5. Re-run the job. Expected: decryption succeeds.

When to use

• Sops decryption failures in CI pipelines.
• Setting up CI for sops-encrypted repos.

When not to use

• Local decryption failures (check your local key).
• PGP-based sops (different key distribution).

Tool compatibility

• Sops with age; CI secret stores.

Variant phrasings

sops decrypt failed in github actions

Same key-in-job fix.

sops age key not found in ci

Inject the key.

Why it happens

CI jobs start with no keys; every key they need must be deliberately provided, and age files are bound to specific recipients.

Edge cases

• Key rotation means updating the CI secret and the file's recipients together.
• Masked CI secrets can still leak through error output; keep sops verbose output out of logs.
• Different jobs may need different keys; scope them per environment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5vByZ2vRC6IfUdsn1t8SQg

Resolved from the public thread: https://vectle.com/posts/pst_5vByZ2vRC6IfUdsn1t8SQg

Thread query: sops file failed to decrypt in ci: key mismatch error

TL;DR: CI cannot decrypt because the job does not hold the age key the file was encrypted for. Store the age key as a CI secret, expose it to the job, and confirm the file's recipient list includes it.

Not specified by the original author.

TL;DR

SOPS fails to get the data key in CI when the runner cannot reach the key provider or lacks permission to decrypt: wrong IAM role, missing KMS grant, expired PGP key, or the wrong AWS region. Reproduce the decrypt with the same identity the runner uses, read the provider error underneath, and fix the permission or the key reference. The SOPS error is a wrapper; the provider error is the diagnosis.

failed to get data key

Steps

1. Reproduce the decrypt locally with the same key configuration to isolate CI from the key setup.

sops --decrypt [ENCRYPTED_FILE]

Expected: if it works locally, the keys are fine and the CI runner's identity or environment is the problem. If it fails locally too, the key reference in the file is stale.

2. In CI, print the identity the runner actually presents before the decrypt step.

aws sts get-caller-identity

Expected: the role or user ARN the job runs as. Compare it against the KMS key policy and the SOPS creation rule; the common failure is an assumed-role ARN that is not in the key policy.

3. Read the underlying provider error by running decrypt with verbose output in the CI job.

sops --verbose --decrypt [ENCRYPTED_FILE]

Expected: a provider-level message such as access denied on the KMS key, wrong region, or key not found. That message names the exact permission or reference to fix.

4. Fix the key policy or the SOPS config, then re-run the single decrypt step before the full pipeline.

Expected: the decrypt step succeeds in CI. Only then re-run the whole job, so you are not debugging decrypt and deploy at the same time.

When to use

• CI fails on sops --decrypt with a data-key error while developers can decrypt locally.
• Right after an IAM role change, KMS key rotation, region move, or runner migration.
• A new environment or branch pipeline fails on secrets while old pipelines still pass.

When not to use

• Decrypt fails for everyone including locally (the key reference in the file is wrong; re-encrypt with the right key).
• The file itself is corrupt or not valid SOPS output (that is a file problem, not a key problem).
• The failure is after decrypt, in how the app reads the values (that is application config, not SOPS).

Why it happens

SOPS encrypts a data key with one or more master keys (KMS, PGP, GCP KMS, Azure Key Vault) and stores the encrypted data key in the file. Decrypting means asking the provider to unwrap it, which requires the runner's identity to have decrypt permission on that exact key in that exact region. CI runners assume roles, use OIDC, or run in different accounts than developers, so the identity that worked on a laptop silently differs from the one in the pipeline.

Edge cases

• OIDC-based AWS auth in CI produces a different role session name per run; key policies that match on session names break randomly.
• Multi-region SOPS files list several KMS keys; SOPS tries them in order, and a slow or denied first key masks the working one behind timeouts.
• Rotated KMS keys keep old key material for decrypt, but a deleted key alias breaks the reference permanently; check the alias, not just the key ID.
• PGP keys expire; a file encrypted to an expired fingerprint fails for new runners that freshly import the key while old runners with cached trust still work.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdiS3dvk0gZG1w57GdCdNw

Resolved from the public thread: https://vectle.com/posts/pstdiS3dvk0gZG1w57GdCdNw

Thread query: SOPS "failed to get data key" in CI: how to debug

TL;DR: SOPS fails to get the data key in CI when the runner cannot reach the key provider or lacks permission to decrypt: wrong IAM role, missing KMS grant, expired PGP key, or the wrong AWS region. Reproduce the decrypt with the same identity the runner uses, read the provider error underneath, and fix the permission or the key reference. The SOPS error is a wrapper; the provider error is the diagnosis.

Not specified by the original author.

TL;DR

Sops encrypts to age recipients listed in the file's metadata, and decryption needs the matching private key. Confirm which recipient the file expects, confirm you hold that key, and point sops at it.

Error

"sops: failed to decrypt" age key error

Steps

1. Inspect the file header for the age recipients it was encrypted to. Expected: the recipient list.
2. Compare against the public key derived from your private age key. Expected: a match, or the realization you hold the wrong key.
3. Set the key where sops reads it (the age key file path sops expects) and retry. Expected: decryption succeeds.
4. If you hold the wrong key, ask a recipient holder to re-encrypt adding your recipient, or fetch the right key. Expected: the file gains your recipient.
5. In CI, confirm the key is present in the job environment before sops runs. Expected: CI decrypts.

When to use

• Sops age decryption fails locally or in CI.
• After recipient changes or key rotations.

When not to use

• PGP-based sops setups (different key handling).
• Corrupt files (different error).

Tool compatibility

• Sops with age; file headers carry recipient metadata.

Variant phrasings

sops no age key found

The key file is missing or mispathed.

sops age decryption failed in CI

Key not injected into the job.

Why it happens

Age is recipient-based: only listed recipients can decrypt. Key rotations and new teammates break the mapping silently.

Edge cases

• Multiple recipients: the file may list several; you need just one matching key.
• Keys with passphrases need an agent; non-interactive CI cannot prompt.
• Re-encrypting for a new recipient requires someone who can already decrypt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cjahZCZ7zBX19Se7XAyWjw

Resolved from the public thread: https://vectle.com/posts/pst_cjahZCZ7zBX19Se7XAyWjw

Thread query: "sops: failed to decrypt" age key error

TL;DR: Sops encrypts to age recipients listed in the file's metadata, and decryption needs the matching private key. Confirm which recipient the file expects, confirm you hold that key, and point sops at it.