# Use Kix-managed secrets

Use `scope.mkSecret` when a package should create and own a Kubernetes Secret.
The returned resource includes helpers for environment variables, `envFrom`,
and volumes, with key names checked during evaluation.

This example uses non-sensitive development values. It assumes you already
have a local Kix package with a workload.

:::caution
Inline `stringData` is present in the Nix source and store. Do not put
production credentials there. Use an
[externally managed Secret](/docs/how-to/platform-capabilities/use-externally-managed-secrets/)
for values supplied by a secret manager or another controller.
:::

## Create the Secret

Add the Secret to the package's returned parts:

<Snippet {...managedSecret} />

When `keys` is omitted, Kix derives the declared key list from `stringData`.
Set `type` when the workload needs a Kubernetes Secret type other than
`Opaque`.

Always use `scope.mkSecret` for a Secret managed by Kix. Its `out` helpers
carry dependency information and validate key names.

## Add the values to a workload

Use `out.mkEnv` to map environment-variable names to Secret keys:

<Snippet {...managedSecretEnv} />

The generated Deployment refers to `managed-example-credentials` through
`secretKeyRef`. It also depends on the Secret, so Kix applies the Secret before
the workload.

For other consumption patterns, use:

- `secret.out.keyRef "key"` for one `valueFrom` entry.
- `secret.out.envFrom` to expose every key through `envFrom`.
- `secret.out.volume "credentials"` to create a Secret volume source.

## Check the package

Evaluate the example cluster:

<Command {...check} />

If the workload requests a key not declared by the Secret, evaluation fails
and lists the available keys. Fix the key name in the workload or add it to
the Secret before deploying.

:::note[Reference]
See [Secrets and Secret refs](/docs/reference/scope-helpers/secrets-and-secret-refs/)
for the complete `scope.mkSecret` arguments and `out` API.
:::