Decrypting with only one of the encryption keys prints an error
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 23.1k
- Forks
- 1.1k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 9
Description
I have the following .sops.yaml, which uses both pgp and azure kv to encrypt kubernetes secrets. For decrypting, I am making only the PGP key available, so I receive this error on the first line and then the manifests are printed correctly. This makes it difficult to use kustomize build --load_restrictor none --enable_alpha_plugins secret/smc/dev-cluster | kubectl apply -f -. Is there a way to suppress it?
# .sops.yaml
creation_rules:
- path_regex: secret/.*/smc/.*\.sops\.yaml
encrypted_regex: '^(data|stringData)$'
azure_keyvault: https://smc.vault.azure.net/keys/sops-key/7asdfad50f6db
pgp: 'asdfasdfasdfasdfasdfasdf'
> kustomize build --load_restrictor none --enable_alpha_plugins secret/smc/dev-cluster
[AZKV] ERRO[0001] Decryption failed error="keyvault.BaseClient#Decrypt: Failure responding to request: StatusCode=401 -- Original Error: autorest/azure: Service returned an error. Status=401 Code=\"Unauthorized\" Message=\"AKV10032: Invalid issuer. Expected one of https://sts.windows.net/csdfasdf/, https://sts.windows.net/adfadasdf/, https://sts.windows.net/e2d51f4/, found https://sts.windows.net/9237badsfasd09ee6014ac4/.\"" key=sops-key version=7b377fdef4c24098a0b7ef3fed50f6db
apiVersion: v1
kind: ServiceAccount
metadata:
....
Appreciate your help.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue using the shown .sops.yaml and the kustomize build command while only the PGP key is available. Trace the decryption error handling for the Azure Key Vault and PGP paths; done means manifests still print correctly without an unwanted error on stderr, while genuine decryption failures remain visible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, go
- Domain
- cloud, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100