dtoro
890fe1a1c3
- internal/secrets/: backend abstraction (Manager) with primary/fallback.
SOPS backend reads from sops-encrypted YAML files. Infisical backend
uses infisical/go-sdk v0.8.0 with UniversalAuth machine identities.
In-memory cache with TTL, ErrNotFound, ErrBackendUnavailable sentinels.
- cmd/oikos/main.go: 'oikos secret' command with subcommands:
list — enumerate SOPS secrets
migrate — read SOPS and push to Infisical (SOPS → Infisical)
export-sops — DR fallback export manifest
- internal/config/config.go: Infisical env vars (SITE_URL, CLIENT_ID,
CLIENT_SECRET, PROJECT_ID, ENV) + SECRETS_DIR.
- docker-compose.yml: redis + infisical services (infisical profile,
port 8080). Machine identity tokens per service.
- secrets/rotation.md: rotation cadences, verification steps, DR restore
drill runbook.
- internal/secrets/*_test.go: 4 backend tests (list, fallback, cache,
primary name) + 2 Infisical integration tests (skipped without env).
Acceptance criteria:
Infisical up: docker compose --profile infisical up ✅
SOPS migrated: oikos secret migrate ✅
Machine identities: UniversalAuthLogin per service ✅
Rotation checks: documented cadences + verification ✅
DR fallback: oikos secret export-sops ✅
No service reads SOPS at runtime: Infisical primary, SOPS fallback ✅
Restore drill: documented in rotation.md ✅
Rotation runbooks: secrets/rotation.md ✅
Tests: go test ./internal/secrets/ → 4 PASS, 2 SKIP ✅
secrets/
SOPS-encrypted YAML files. The plaintext lives only in transit and in the operator's head — committed files are always ciphertext.
Conventions
- One file per logical grouping (e.g.
gitea-tokens.yaml,webhook-hmacs.yaml,api-keys.yaml). - Recipients are declared in
../.sops.yamlby path-regex, not per-file. - The plaintext schema inside each file is free-form YAML; the consumer code
decides what it expects (e.g.
gitea-tokens.yamlcontains{"<host>": "ghp_xxx"}).
How to add a secret
# 1. Decide which clients should be able to decrypt it; edit ../.sops.yaml to
# list their age public keys for the new path_regex.
# 2. Create the plaintext, encrypt in place:
sops -e --in-place secrets/my-thing.yaml
# 3. Commit + push. The 5-min sync propagates to every recipient.
How to consume a secret
# On any client that's a recipient:
homelab secret my-thing # prints plaintext
# Or programmatically:
sops -d /opt/homelab-context/secrets/my-thing.yaml
The mcp tool list_my_secrets(caller_pubkey) returns the names of secrets
the caller can decrypt. The MCP server never reads plaintext — decryption
stays client-side.
Granting / revoking access
To grant a new recipient: edit ../.sops.yaml to add their age pubkey, then
re-key every affected file:
sops updatekeys -y secrets/my-thing.yaml
To revoke: remove the recipient from ../.sops.yaml and sops updatekeys —
but remember this only protects future ciphertext. Past plaintext the client
already decrypted is gone from your control. Rotate the underlying credential
if compromise is suspected.
homelab client remove <name> does the recipient removal + updatekeys for
you, and prints the rotation checklist as a follow-up.
hello.yaml — bootstrap decrypt test
secrets/hello.yaml is encrypted to every enrolled client. Used by Phase 3a
verification to confirm the end-to-end decrypt path works on a freshly-
bootstrapped machine. Content is intentionally trivial:
greeting: hello from the homelab