# Use externally managed secrets

Use `scope.mkSecretRef` when another system creates the Kubernetes Secret. Kix
does not render or update the Secret data, but it validates the keys your
package expects and waits for them before applying dependent resources.

This guide assumes the external system creates the Secret in the workload's
namespace.

## Declare the Secret reference

Add a reference to the package's returned parts and list every key the package
will consume:

<Snippet {...externalSecretRef} />

The example expects `Secret/billing-api-credentials` in the package namespace.
`scope.mkSecretRef` emits an import marker rather than a Secret manifest.

Keep the reference in the build function's returned attrset, as shown by the
`credentials` part above. A reference used only in a `let` binding is not
collected into the cluster artifact.

## Consume declared keys

Use the same `out` helpers available on a Kix-managed Secret:

<Snippet {...externalSecretEnv} />

`out.mkEnv` validates `api-key` during evaluation and adds the dependency edge
from the Deployment to the import marker.

## Check the wiring

Evaluate the cluster before connecting to Kubernetes:

<Command {...check} />

Inspect the graph when you need to confirm the deploy ordering:

<Command expandable {...graph} />

The `secret-ref-external-example-billing-api-credentials` import appears
before `Deployment/external-example`.

## Verify the external Secret

Confirm that the provider has created the Secret in the expected namespace:

<Command
  commands={[
  "kubectl get secret billing-api-credentials -n secret-examples",
]}
/>

During `kix deploy`, Kix checks that the Secret exists and contains the
declared keys before applying the dependent Deployment. A missing Secret or
key fails that deploy wave rather than starting the workload with an invalid
reference.

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