Secrets und Konfiguration

Konfiguration liegt in ConfigMap-Objekten, Zugangsdaten in Secret-Objekten. Beides ist normales Kubernetes ohne Besonderheiten dieser Plattform, alles, was du schon kennst, gilt also.

Anlegen

kubectl create secret generic app-secrets \
  --from-literal=DATABASE_PASSWORD='...' \
  --from-literal=API_TOKEN='...'

kubectl create configmap app-config \
  --from-literal=LOG_LEVEL=info \
  --from-file=config.yaml

Ein Secret ist kodiert, nicht verschlüsselt

Base64 ist kein Schutz. Wer Secrets in deinem Namespace lesen darf, liest die Werte im Klartext, und das ist jeder mit deiner Kubeconfig. Halte Secrets aus Git heraus, und besonders aus einem Repository, das du mit Deployment aus Git synchronisierst, denn das muss öffentlich lesbar sein.

In einen Container bekommen

Einzelne Werte als Umgebungsvariablen, die häufigste Form:

env:
  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: DATABASE_PASSWORD
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: LOG_LEVEL

Alles auf einmal, wobei jeder Schlüssel zu einer gleichnamigen Variable wird:

envFrom:
  - secretRef:
      name: app-secrets
  - configMapRef:
      name: app-config

Als Datei, wenn deine Anwendung eine Konfigurationsdatei statt Variablen will:

volumeMounts:
  - name: config
    mountPath: /etc/myapp/config.yaml
    subPath: config.yaml
volumes:
  - name: config
    configMap:
      name: app-config

subPath mountet den einzelnen Schlüssel als Datei. Ohne die Angabe bekommst du ein Verzeichnis mit einer Datei pro Schlüssel, was meistens nicht gemeint ist.

Änderungen werden nicht automatisch übernommen

Eine ConfigMap zu ändern startet nichts neu. Werte, die als Umgebungsvariablen gesetzt werden, liest der Container einmal beim Start, der laufende behält also die alten, bis er ersetzt wird:

kubectl rollout restart deployment/myapp

Als Datei gemountete Werte werden irgendwann doch aktualisiert, aber nur dann wirksam, wenn deine Anwendung die Datei beobachtet.

Zugangsdaten für Object Storage

Buckets und Zugangsschlüssel legst du im Portal unter Storage an. In deinen Namespace wird nichts eingespielt, leg den Schlüssel also selbst in ein Secret:

kubectl create secret generic s3-credentials \
  --from-literal=AWS_ACCESS_KEY_ID='<access-key>' \
  --from-literal=AWS_SECRET_ACCESS_KEY='<secret-key>'

Danach referenzierst du es wie jedes andere Secret, den Endpunkt als normale Konfiguration:

env:
  - name: S3_ENDPOINT
    value: "https://storage.itsh.dev"
  - name: S3_BUCKET
    value: "my-bucket"
envFrom:
  - secretRef:
      name: s3-credentials

Jedes S3-kompatible SDK funktioniert gegen diesen Endpunkt.

Wie es weitergeht

• Erstes Deployment, wo das im Manifest hingehört
• Images und Pull-Secrets für den Registry-Fall