sops --encrypt: Encrypt Secret Files for Git
sops --encrypt encrypts the values in a structured file (YAML, JSON, env) while keeping the keys in plaintext so diffs stay readable.
sops encrypts secrets in place so they can live in Git. It encrypts values, not keys, which keeps reviews meaningful.
What it does
sops --encrypt encrypts the leaf values of a structured file using a key from a recipient you specify (age, KMS, PGP, etc.), leaving the keys and structure visible. -i edits the file in place. A .sops.yaml in the repo can supply creation rules so you do not repeat recipients on the command line.
Common usage
# encrypt with an age recipient, in place
sops --encrypt --age age1qz... --in-place secrets.yaml
# only encrypt values whose key matches a pattern
sops --encrypt --encrypted-regex '^(data|stringData)$' \
--age age1qz... secret.yaml > secret.enc.yamlOptions
| Flag | What it does |
|---|---|
| -e, --encrypt | Encrypt the input file |
| -i, --in-place | Write the encrypted result back to the file |
| --age <recipient> | Encrypt to one or more age public keys |
| --kms <arn> | Encrypt to an AWS KMS key |
| --encrypted-regex <re> | Only encrypt values under matching keys |
| --unencrypted-regex <re> | Leave matching keys in plaintext |
In CI
Commit a .sops.yaml with creation_rules so contributors just run sops -e -i file and the right recipients are applied automatically. For Kubernetes Secrets, set --encrypted-regex '^(data|stringData)$' so only the secret values are encrypted and the rest of the manifest stays plain for tooling like Flux's kustomize-controller.
Common errors in CI
"sops metadata not found" appears when you try to encrypt a file that lacks a config and no recipient is given; pass --age/--kms or add a .sops.yaml rule. "no matching creation rules found" means the file path does not match any path_regex in .sops.yaml. "Failed to get the data key required to decrypt" later means the recipient key is unavailable to whoever decrypts.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes