Wie können wir ein Dienstkonto so beschränken, dass es nur Objekte erstellen, auflisten, löschen usw. kann, die innerhalb eines bestimmten Namespaces eine bestimmte Bezeichnung haben?
Wir haben eine Hierarchie von Diensten (die Kubernetes-Namespaces zugeordnet sind) und Komponenten (die durch ein personaLabel auf verschiedenen Objekten dargestellt werden) entwickelt und sie so in Vault integriert, dass die Geheimnisse, auf die Sie Zugriff haben, spezifisch für ein Dienst-Komponenten-Paar sind. Dies hilft bei der Trennung. Stellen Sie sich beispielsweise ein Team vor, das eine Reihe von Bereitstellungen verwaltet und nur einige davon PII-Daten verarbeiten. Wir können dieses Label verwenden, um selektiv Zugriff auf diese Geheimnisse zu gewähren.
# only approximatively k8s objects
---
kind: Deployment
metadata:
name: backend
namespace: banana
labels:
persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
name: frontend
labels:
persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar
Das bedeutet jedoch, dass wir nicht nur ein Servicekonto erstellen möchten, das verwalten kannallePods in diesem Namespace – wenn das Geheimnis zu diesem Dienstkonto durchsickert, könnte ein Angreifer es verwenden, um einen Pod mit einem schädlichen Image und Zugriff auf PII zu starten.
Ich hätte also gerne etwas wie: (bitte beachten Sie, dass mein Wissen über Dienstkonten, Rollen und Rollenbindungen äußerst begrenzt ist)
# even more approximatively so k8s objects
kind: Role
metadata:
name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
selector:
labels:
persona: frontend
# even if compromised, this service account cannot access banana§backend secrets
Es scheint wie k8skönnteunterstützen Sie etwas Ähnliches, z. B. indem Sie eine Liste spezifischer Ressourcennamen bereitstellen (#), aber dass dies ansonsten derzeit nicht von k8s unterstützt wird? Oder übersehe ich etwas?
Ist unsere einzige Alternative, ein clusterweites Servicekonto mit umfassendem Zugriff auf alles einzurichten und dann einen Webdienst zu starten, der seine eigene benutzerdefinierte Authentifizierungs- und Autorisierungsroutine durchführt, bevor das Token verwendet wird? Wenn ja, wie können wir den Umfang dieses „Gott-Kontos“ so weit wie möglich einschränken?
Antwort1
Kubernetes hat keine Möglichkeit, dieListeVerb nach Objekt. Wenn Sie eine Sammlung auflisten können, können Sie alle Objekte in dieser Sammlung lesen.
Vielleicht wird sich das eines Tages ändern, aber im Moment funktioniert Kubernetes in Bezug auf Sammlungen und Lesezugriff so. Dazu gehört auch der Lesezugriff auf Secrets …
Wenn Sie jedoch einschränken möchtenschreibtfür Objekte, das können Sie tun. Sie können die Schreibberechtigung für bestimmte benannte Objekte einschränken, indem Sie Folgendes verwenden:
- ein externer Webhook zur Validierung der Zulassung
- eine (Beta) ValidatingAdmissionPolicy
- ein Autorisierungs-Webhook
oder mithilfe sorgfältig ausgearbeiteter RBAC-Regeln.
Etwas, das Ihnen bei der Zugriffsverwaltung helfen könnte, isthierarchischer Namespace-Controller, sodass ein Team eineSatzvon Namespaces, die jeweils ihre eigenen Einschränkungen haben. Wenn Ihr Cluster ValidatingAdmissionPolicies unterstützt, können Sie diese verwenden, um den Zugriff weiter zu delegieren und den Schreibzugriff einzuschränken (das ist allerdings ein ziemlich kompliziertes Thema).
Wenn Sie einen ServiceAccount haben möchten, der bestimmte Dinge tun kann, aber die Kontrolle über diese Dinge delegieren möchten, können Sie in jedem Zielnamespace einen ServiceAccount mit einer Rollenbindung erstellen und dann dem allgemeinen ServiceAccount erlauben, die Identität der spezifischen ServiceAccounts zu übernehmen. Auch das ist eine ziemlich komplexe Angelegenheit, aber es ist möglich.