Secrets
There are two ways an app gets secrets, and they compose. In both, the value never
enters kubrain.yaml, the rendered manifest, the image, or any tool output —
Kubrain records only key names, never values.
1 · Kubrain-managed secrets
Write a value straight into the deployment’s own Kubernetes Secret — from a file or an env var, never an inline argument:
kubrain deploy set-secret myapp DB_PASSWORD --value-file ./db-pass.txt
kubrain deploy set-secret myapp API_KEY --from-env API_KEY
kubrain deploy unset-secret myapp DB_PASSWORDEvery managed key is exposed to the workload as an env var automatically. Because secrets are referenced (not baked into the image), rollback and promotion keep working and pick up the current values on the next ship.
2 · Reference an existing Secret / ConfigMap
In kubrain.yaml, an env: entry can point at
something else that created a Secret or ConfigMap (an operator, an add-on, a
hand-applied Secret). Kubernetes resolves it at pod start.
Each env: entry is exactly one of four forms:
| Form | Syntax | Becomes |
|---|---|---|
| Literal | NAME: value | value: |
| Secret key | NAME: {secret: s, key: k} | secretKeyRef |
| ConfigMap key | NAME: {configMap: c, key: k} | configMapKeyRef |
| Addon credential | NAME: {addon: redis, key: url} | a resolved secretKeyRef |
env:
LOG_LEVEL: info # literal
DB_PASSWORD: {secret: db-app, key: password} # same namespace
DB_TOKEN: {secret: db-app, key: token, namespace: data} # another namespace *
REDIS_URL: {addon: redis, key: url} # a built-in addon
envFrom:
- secret: db-app # import every key
- addon: rediskey: defaults to the env var’s own name when omitted. namespace: — because
Kubernetes references can’t cross namespaces, naming one makes Kubrain mirror
that Secret into the app’s namespace at rollout (re-synced each deploy, so rotation
follows).
--value-file) or an env var (--from-env); write kubeconfigs and
bucket credentials to a path and use the file.