Grant Docker Compose secrets only to services that need them

Review both the secret definition and each consuming service when replacing environment-based credentials in Linux containers.

Source facts

Docker documents a two-step Compose secrets model: define a secret at the top level and grant access explicitly to the services that need it. A granted secret is exposed as a file under /run/secrets in the container. Docker contrasts this with the accidental disclosure risks of environment variables. The documented file-mount approach applies to Linux containers; application-specific examples do not make every image consume secret files automatically.

Source: Docker — Use secrets in Compose.

Applicability

Use this for the cited local Docker Compose workflow. Confirm the container operating system and the application’s supported credential-file mechanism before changing configuration.

DSE recommendation

DSE recommends a small inventory linking each secret to its host source, authorized services, application setting, owner, and rotation procedure. Grant only the required services access. Protect the host source and exclude live values from repositories, tickets, and screenshots. Check how the application actually reads the file instead of assuming a variable-name convention is universal. Plan rotation and rollback with the application owner, including whether a restart is required in that application’s supported procedure.

Verification

In a test stack, verify that the intended service can read its credential and perform its task. Confirm that an ungranted service lacks that secret file. Inspect sanitized logs for accidental values and record the successful rotation procedure before production rollout.

Official reference

Docker — Use secrets in Compose. Reviewed October 14, 2026.