SOPS — 🚧 store ready, decrypt-at-apply planned

SOPS encrypts values in YAML/JSON files while keeping keys readable. Wardn has a sops/age secret store for the key side — what isn't wired yet is the apply-time decrypt in the manifest pipeline.

Status

Piece	Status
`sops/age` secret store	✅ registered — `Test` does an encrypt/decrypt round-trip
Apply-time decrypt of `.sops.yaml` files	📋 not wired — encrypted manifests apply as-is
KMS / GCP KMS / Vault Transit / PGP providers	📋 not registered — `400` on create

Today the store validates keys, nothing more. If you commit a .sops.yaml-encrypted Secret, the operator applies the ENC[…] values literally. Keep plaintext-out-of-git via env.store (vault/ESO) until decrypt-at-apply lands.

Configure the store

Via the API

curl -X POST http://localhost:8080/api/v1/secret-stores -b cookies.txt \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dev-age",
    "type": "sops",
    "provider": "age",
    "credentials": {"privateKey": "AGE-SECRET-KEY-1XYZ…"}
  }'

Via the UI

Secret Stores → Add Store → sops / age — paste the age private key; the provider schema drives the form.

POST /api/v1/secret-stores/{id}/test runs an actual encrypt/decrypt round-trip — connected means the key works end-to-end.

Intended apply-time flow (📋)

┌─────────────┐  encrypted  ┌──────────┐  decrypt   ┌──────────────┐
│  Developer  │────────────▶│   Git    │───────────▶│   Operator   │
│  (sops -e)  │             │  Repo    │  at apply  │ (store key)  │
└─────────────┘             └──────────┘            └──────┬───────┘
                                                           │
                                                           ▼
                                                   ┌──────────────┐
                                                   │  K8s Secret  │
                                                   │  (plaintext) │
                                                   └──────────────┘

When wired, the manifest pipeline will detect sops:-marked files under source.git.path and decrypt them against the registered age store before apply.

Working with SOPS today (client-side)

You can still encrypt and version secrets in Git — the decrypt happens on your side:

Step 1: Generate an age key

age-keygen -o key.txt
# public key printed to stderr: age1abc…

Step 2: Encrypt the secret file

sops --encrypt --age age1abc… --in-place manifests/secret.yaml

Step 3: Register the key with Wardn

curl -X POST http://localhost:8080/api/v1/secret-stores -b cookies.txt \
  -H "Content-Type: application/json" \
  -d '{"name":"dev-age","type":"sops","provider":"age","credentials":{"privateKey":"…"}}'

Step 4: Use `.sops.yaml` creation rules

creation_rules:
  - path_regex: manifests/production/.*\.yaml
    age: age1prod…
  - age: age1dev…

sops -e --in-place then picks the right key per path.

What works vs what doesn't

Capability	Status
Store an age private key	✅ sealed via `WARDN_CREDENTIALS_KEY`
Round-trip `Test`	✅
Auto-detect + decrypt on apply	📋
`sops`-aware health (`Secret` exists with `ENC[…]` values → warn)	📋

Security Notes

Never commit the private key — .sops.yaml goes to git; key.txt never does
Sealed at rest — the store row encrypts to enc:v1: keyed by WARDN_CREDENTIALS_KEY
Session-only writes — creating/rotating the store requires a session, not an API key

Secret Management Overview — compare the three layers
External Secrets Operator — working alternative today
Secret Stores API — manage stores via API

SOPS

On this page