A CLI tool that simplifies creating Sealed Secrets for Kubernetes. It wraps kubectl and kubeseal to generate sealed secret YAML files either interactively or from a declarative configuration file.
git clone https://github.com/tscrond/kubeseal-helper.git
cd kubeseal-helper
go build -o kubeseal-helper .Or install directly:
go install github.com/tscrond/kubeseal-helper@latestkubeseal-helper [command] [flags]
| Command | Description |
|---|---|
interactive |
Create and seal a secret using a TUI wizard |
from-file |
Create and seal secrets from a declarative YAML file |
| Flag | Description |
|---|---|
--config |
Path to config file (default: $HOME/.kubeseal-helper.yaml) |
Launch a step-by-step terminal wizard that prompts you for all required values.
kubeseal-helper interactiveThe wizard will ask for:
- Number of secret variables
- Secret name
- Namespace (selected from live cluster namespaces)
- For each variable: key name, input method (literal value or file), and the value
- Secret type (
Opaqueorkubernetes.io/basic-auth)
The sealed secret is written to <secret-name>.yaml in the current directory.
Create one or more sealed secrets from a declarative YAML file.
kubeseal-helper from-file -f secrets.yaml| Flag | Short | Required | Description |
|---|---|---|---|
--file |
-f |
Yes | Path to the declarative secrets file |
IMPORTANT!!! Keep the secret configs with plain text passwords away from ANY version control system, ideally - store them in a password manager or use encryption
# Optional: override kubeContext / controller settings for this file
kubeContext: "my-context"
controllerName: "sealed-secrets"
controllerNamespace: "kube-system"
secrets:
- name: my-secret
namespace: "default"
type: Opaque # Optional, defaults to Opaque
data:
- key: API_KEY
value: "my-api-key" # literal value
- key: DB_PASSWORD
valueFromEnv: DB_PASSWORD # read from environment variable
- key: tls.crt
valueFromFile: "/path/to/tls.crt" # read from file (absolute or relative to the YAML file)Each data entry must define exactly one of value, valueFromEnv, or valueFromFile.
Each secret is written to <secret-name>.yaml in the current working directory.
See examples/secret-example.yaml for a full example:
kubeContext: "bl-prod"
controllerName: "sealed-secrets"
controllerNamespace: "kube-system"
secrets:
- name: secret1
namespace: "apps"
type: Opaque
data:
- key: GOOGLE_COOKIE_SECRET
value: "cookie-secret"
- key: DB_SECRET
value: "asodfpasdf"
- name: secret2
namespace: "apps"
type: Opaque
data:
- key: bucket-config.json
valueFromFile: "/home/user/bucket-auth.json"kubeseal-helper from-file -f examples/secret-example.yaml
# Sealed secret written to secret1.yaml
# Sealed secret written to secret2.yamlSettings can be provided via a config file, environment variables, or the secrets YAML file itself (for from-file). Precedence: secrets YAML file > environment variables > config file > defaults.
Place a file at ~/.kubeseal-helper.yaml:
kubeContext: "my-context"
controllerName: "sealed-secrets"
controllerNamespace: "kube-system"You can also merge the config file with different secrets YAML configurations (see secret-example.yaml):
kubeContext: "bl-prod"
controllerName: "sealed-secrets"
controllerNamespace: "kube-system"
secrets:
- name: secret1
namespace: "apps"
type: Opaque
data:
- key: GOOGLE_COOKIE_SECRET
value: "cookie-secret"
- key: DB_SECRET
value: "asodfpasdf"
- name: secret2
type: Opaque
namespace: "apps"
data:
- key: bucket-config.json
valueFromFile: "/home/tskr/wazne/bucket-auth.json"
| Variable | Setting |
|---|---|
KUBESEAL_HELPER_KUBE_CONTEXT |
kubeContext |
KUBE_CONTEXT |
kubeContext |
KUBESEAL_HELPER_CONTROLLER_NAME |
controllerName |
SEALED_SECRETS_CONTROLLER_NAME |
controllerName |
KUBESEAL_HELPER_CONTROLLER_NAMESPACE |
controllerNamespace |
SEALED_SECRETS_CONTROLLER_NAMESPACE |
controllerNamespace |
| Setting | Default |
|---|---|
controllerName |
sealed-secrets |
controllerNamespace |
kube-system |
| Secret type | Opaque |
MIT — see LICENSE.