Secret Handling

Secrets werden nicht direkt im Image, nicht im Workspace und nicht als normale Umgebungsvariable in der compose.yml hinterlegt, sondern gezielt über Docker Compose Secrets bereitgestellt.

Damit wird erreicht, dass sensible Werte nur den Containern zur Verfügung stehen, die sie tatsächlich benötigen.

Secrets werden pro Service (Container) explizit freigegeben.

compose.yml

secrets:
  - github_auth_token

Ein Container erhält ein Secret also nur dann, wenn es in seiner Service-Definition ausdrücklich eingetragen ist.

Die zentrale Definition erfolgt im unteren Bereich der compose.yml:

compose.yml

secrets:
  github_auth_token:
    file: ./secrets/github_auth_token
  app_env:
    file: ./secrets/.env.app

Der deps-Container kann einen Personal Access Token benötigen, um im Falle einer privaten NPM-Registry Zugriff auf NPM-Pakete zu erhalten.

compose.yml

deps:
  ...
  secrets:
    - github_auth_token

Im Container wird das Secret nicht als Umgebungsvariable gepflegt, sondern bewusst aus /run/secrets/... gelesen:

compose.yml

GITHUB_AUTH_TOKEN="$(cat /run/secrets/github_auth_token)" exec npm ci --ignore-scripts

Der app-Container erhält mit app_env ein eigenes Secret für Laufzeitkonfiguration.

compose.yml

app:
  ...
  secrets:
    - app_env

Dieses Muster eignet sich für Anwendungs-Konfigurationen, die nicht in das Repository gehören¹, z.B.:

• API-Keys
• Datenbank-Zugangsdaten
• interne Runtime-Flags
• Umgebungsabhängige Konfiguration

Nicht jede environment-Variable ist ein Secret. Werte wie Cache-Pfade oder allgemeine Laufzeitoptionen sind technische Konfiguration:

compose.yml

environment:
  HOME: /tmp
  NPM_CONFIG_CACHE: /tmp/npm-cache

Solche Werte sind unkritisch und dürfen direkt in der Compose-Datei stehen.