Sind Kubernetes Secrets standardmäßig verschlüsselt?

Das Wort „Secret“ und der undurchsichtige Base64-Block im Manifest vermitteln trügerische Sicherheit. Die Frage prüft, ob Sie wissen, was Kubernetes standardmäßig tatsächlich tut.

Was die Dokumentation sagt

Kubernetes Secrets werden standardmäßig unverschlüsselt im zugrunde liegenden Datenspeicher des API-Servers, etcd, abgelegt. Jeder mit API-Zugriff kann ein Secret abrufen oder ändern, ebenso jeder mit etcd-Zugriff. Außerdem kann jeder, der in einem Namespace Pods erstellen darf, damit jedes Secret dieses Namespace lesen, auch indirekt über ein Deployment.

Base64 ist keine Verschlüsselung

Die Werte im data-Feld eines Secrets sind Base64-kodiert, damit Binärdaten in YAML/JSON passen. Jeder kann das mit einem Befehl umkehren; es bietet keine Vertraulichkeit.

Was zu tun ist

Die Dokumentation nennt mindestens: Verschlüsselung im Ruhezustand aktivieren, RBAC mit minimalen Rechten für Secrets konfigurieren, Secret-Zugriff auf bestimmte Container beschränken und externe Secret-Store-Anbieter erwägen (etwa über den Secrets Store CSI Driver).

Warum die Distraktoren scheitern

• „Base64 verschlüsselt“ verwechselt Kodierung mit Verschlüsselung.
• „Schlüssel pro Namespace“ ist erfunden; ein solcher Standard existiert nicht.
• „Namespaces isolieren vollständig“ — sie helfen beim Eingrenzen von RBAC, aber den Zugriff bestimmen die vergebenen Rechte, einschließlich Pod-Erstellung.

Was Interviewer hören wollen

„Nicht standardmäßig — Verschlüsselung im Ruhezustand aktivieren, RBAC verriegeln (auch wer Pods erstellen darf) und einen externen Store erwägen.“