kryptos — Secret-Sealing CLI/TUI

kryptos started as a way to stop hand-running kubeseal and grew into a repo-agnostic tool: a small TOML file points it at any GitOps repo’s config tree and output layout. It reads a declarative config describing which secrets exist and how to produce them, resolves the values, seals them, and writes SealedSecrets ready to commit.

Configs declare intent, not material

Each application gets a YAML config listing its secrets, their keys, and how each value comes to be — a generator keyword (secure, strong, apikey, passphrase), a derived field, or an externally supplied value. A published JSON schema gives editors autocomplete and validation while writing them. No config ever contains a credential.

Deterministic value resolution

Non-interactive runs resolve every value through an explicit precedence chain: command-line --set beats a values file, which beats an environment variable, which beats the generator, which beats the default. Derived fields — htpasswd entries, JWT/HMAC material, self-signed TLS, SSH keypairs, rendered Go templates — evaluate in two passes, so a template can reference another derived value without fragile ordering rules.

Built to gate CI

validate checks every config against the schema, audit detects drift between configs and the sealed files in the GitOps tree, and diff previews exactly which keys a reseal would change — all offline, with no cluster access. That makes secret hygiene a pipeline gate instead of a convention. The tool itself releases through goreleaser on auto-cut SemVer tags, with a Makefile installer that fetches and checksum-verifies the right binary.