Wie erstellt man mit der RBAC API Benutzer / Gruppen, die auf den Namespace in Kubernetes beschränkt sind?

9

Problem

Ich würde gern viele verschiedene Entwickler (verschiedene Themen) aus der Dev-Gruppe herausfordern und ihnen allen erlauben, Dinge innerhalb des Dev-Namespace zu erstellen und zu ändern, aber nichts außerhalb davon zu berühren, und definitiv nicht sehe Geheimnisse außerhalb davon. Ich vermute, dass die Rollen, Rollenbindungen usw., die ich in Schritt 2 erstelle, nicht korrekt sind, kann jemand Korrekturen vorschlagen?

Versuch

  1. Implementiert Kubernetes mit API-Server-Flags zur Unterstützung der Berechtigungsmodi "RBAC, AlwaysAllow", legen Sie den RBAC-Superuser fest und aktivieren Sie die RBAC-API über --runtime-config .
  2. Erstellt eine Namespace-, Rollen- und Rollenbindung mit der Absicht, dass (a) Dienstkonten und Systemkomponenten effektiv immer noch "AlwaysAllow" -Zugriff haben können und (b) jede Entität in der Gruppe dev auf irgendetwas im Namespace% zugreifen kann co_de% mit dieser YAML-Datei . HINWEIS: Der Inhalt dieses Links hat sich geändert, siehe YAML-Dateien, die ich am Ende der Frage bearbeitet habe.
  3. Aktualisierte Kubernetes, um nur den "RBAC" Autorisierungsmodus zuzulassen.
  4. Generierte Client-TLS-Daten, für die das Zertifikat-Betreff-Flag (für openssl) dev .
  5. war
  6. Nach dem Template wurde eine kubeconfig-Datei erstellt.

Tatsächliches Ergebnis

Ich bekomme beim Ausführen folgende Fehler: -subj "/[email protected]/O=dev" :

%Vor%

Erwartetes Ergebnis

Erwartet, dass der busybox-Pod in kubectl -v 8 --kubeconfig=/tmp/dev-kube-config.yml create -f /tmp/busybox.yml namespace erstellt wird.

Zusätzliche Details:

BEARBEITEN: Arbeitslösung basierend auf Antwort und Kommentaren

Basierend auf Jordans Antwort unten habe ich ein Upgrade auf Kubernetes v1.5.1 durchgeführt und dann die folgenden zwei YAML-Dateien erhalten, um den Namespace und alle korrekten RBAC-Ressourcen zu erstellen, damit alles wie gewünscht funktioniert:

$ kubectl version (aufgrund der sofort einsatzbereiten Clusterrollen und Clusterrollen-Bindungen schien nicht zu funktionieren):

%Vor%

system-access.yml :

%Vor%     
Amit Kumar Gupta 24.12.2016, 00:59
quelle

1 Antwort

4

Zuerst müssen Sie den Zugriff auf die URLs zulassen, die kubectl für die API-Erkennung und -Überprüfung verwendet (Swagger, Listen von API-Gruppen und Ressourcentypen usw.).

Das einfachste Verfahren ist das Laden des Standard-Bootstraps. Cluster-Rollen und Cluster-Rollenbindungen :

%Vor%

Dadurch wird eine system:discovery ClusterRole erstellt und alle Benutzer (authentifiziert und nicht authentifiziert) an sie gebunden, sodass sie auf Informationen zu swagger und API-Gruppen zugreifen können.

Zweitens sollten Sie das Entwicklerdienstkonto nicht in die Clusterrollenbindung all einschließen. Dies würde ermöglichen, dass das Dienstkonto (und jeder mit Zugriff auf die geheimen Daten im Dev-Namespace, der die Anmeldeinformationen des Entwicklerdienstkontos enthält) einen Cluster-weiten Zugriff erhält.

    
Jordan Liggitt 24.12.2016, 16:01
quelle