External Secrets

Distr Secrets are encrypted at rest and filled in when a deployment is applied, but the controller still receives their values from Distr. A password, an API key or a certificate that should never leave the customer environment can be created there instead. The deployment then refers to it by name, and Distr only ever sees that name.

	Distr Secrets	External secrets
Where the value is stored	Encrypted in the Distr database	Only in the customer environment
Who manages it	Vendor or customer users in Distr	Whoever administers the environment
On a change	Distr redeploys the deployments that use it	Restarting the containers that read it is up to whoever changes it
Masked in logs sent to Distr	Yes	Only if it matches a common credential pattern

Both can be used in the same deployment, for example Distr Secrets for values the vendor provides and external secrets for credentials that belong to the customer.

Kubernetes

Create the Secret in the namespace of the deployment, with kubectl or a tool such as the External Secrets Operator that syncs it from a vault. Then pass its name to the chart in the Helm values. Put the value in a file rather than on the command line, so it does not land in the shell history or the process list. Delete the file once the Secret exists if you do not want a copy left on disk.

kubectl create secret generic my-app-db --namespace my-app --from-file=password=./db-password

postgresql:
  auth:
    existingSecret: my-app-db

Most charts offer a value like existingSecret for this, but its name and whether it exists depend on the chart. The Secret is not part of the Helm release, so uninstalling the deployment leaves it in place.

Docker Compose

Put the value in a file on the host that only root can read, and reference it in the secrets section of the Compose file. Docker mounts it into the container as /run/secrets/<name>.

services:
  backend:
    image: my-application-backend
    secrets:
      - db-password

secrets:
  db-password:
    file: /etc/my-application/db-password

The controller does not need access to the file. Compose passes the path to the Docker engine as a bind mount, and the engine reads it on the host. Compose cannot find the file inside the controller container, so the controller logs a warning that the secret file does not exist. You can ignore it. The path has to be absolute, since Compose resolves a relative one in the controller’s project directory and not on the host. Unlike an environment variable, the value does not show up in docker inspect, which only shows the path of the mount.

Logs

Distr masks the values of Distr Secrets and common credential patterns in the logs it receives. It cannot know the value of an external secret, so if application logs are collected, make sure the application does not log it. Data Sent to Distr lists everything a controller reports.