-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
SOPS already handles encryption well, supports multiple key backends, and has its own audit history. Embedding a crypto library would make Keyseal responsible for algorithm choices, key management, SOPS format compatibility, and security patches. Staying at the workflow layer means you can upgrade SOPS independently and Keyseal does not become a crypto maintenance burden.
For teams that use GitOps or want secrets to be version-controlled alongside application config, encrypted-in-Git is a practical pattern. Changes are auditable, rollback is possible, and there is no separate secrets server to operate.
The tradeoff is that the ciphertext is accessible to anyone with repository access. That is acceptable if your key management is sound - if your age private keys are protected, the ciphertext in Git has no value to someone without those keys.
This pattern is not appropriate for every organization. If you have specific audit, access control, or rotation requirements, a dedicated secrets platform is the right tool.
By design. add is the entry point for getting a new secret into the repository, and the only acceptable outcome is an encrypted file. Offering a plaintext scaffolding mode means one wrong flag away from committing unencrypted secrets - a mistake that is easy to make under time pressure and hard to fully undo once pushed. The add command intentionally has no escape hatch here.
If you need to inspect the document schema before encrypting, read Secret File Format directly. To modify an existing secret's values, use keyseal edit, which keeps everything inside SOPS.
Yes, for Barkway's Git-backed SOPS secret workflow. The core workflow (init, add, edit, updatekeys, render, exec, doctor, verify) is production-ready, and the v1 keyseal.yaml plus kind: env secret document contracts are stable.
The profiles section of keyseal.yaml is not executed by any command yet. If you are depending on that feature, it is not available in the current implementation.
Those systems provide access control, dynamic credentials, audit logs, and rotation - things Keyseal does not provide. They also require infrastructure to operate (a Vault cluster, an AWS account with IAM, etc.).
Keyseal is for teams that want version-controlled, encrypted secrets with no additional infrastructure. If you need the properties that secrets servers provide, use one. Keyseal does not compete with them.
Not directly. Keyseal's keyseal.yaml and the generated .sops.yaml assume age-based encryption. Read-only decrypt uses the official SOPS Go library, and mutating commands use the external SOPS CLI. Other SOPS backends may work where the SOPS library and CLI support them, but Keyseal's documented deployment model is age key material for read-only servers and SOPS CLI for developer/admin mutation workflows.
The doctor placeholder check and the generated .sops.yaml template are age-specific. Other backends will not produce false positive placeholder warnings.
No. The outputs are dotenv files, JSON, YAML, or subprocess environments. Keyseal has no concept of Kubernetes resources, Helm values, or cloud-native secret injection. You can render to a file and consume it from a deployment script, but that wiring is outside Keyseal's scope.
Keyseal exits with the subprocess's exit code and prints nothing. Your process manager or CI system sees the child's exit code directly.
No. Keyseal looks for keyseal.yaml in the current working directory only. There is no support for nested configurations, workspace-style setups, or multiple roots.
To prevent implicit writes to unexpected locations. The defaults.output_dir in keyseal.yaml exists as a reference value and is checked by doctor, but render does not silently write there. Requiring an explicit destination flag means the output location is always visible at the point of invocation.
Getting Started
Reference
Operations
Development