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

Question

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

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 .
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.
Aktualisierte Kubernetes, um nur den "RBAC" Autorisierungsmodus zuzulassen.
Generierte Client-TLS-Daten, für die das Zertifikat-Betreff-Flag (für openssl) dev .
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:

dev
%Vor%
GitHub-Problem: Ссылка
Mailinglistenbeitrag: Ссылка

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%

client-certificates kubernetes rbac kubectl

Amit Kumar Gupta 24.12.2016, 00:59

quelle

1 Antwort

Tags und Links client-certificates kubernetes rbac kubectl

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Fehler beim Kompilieren von AIDL

score 4 · Accepted Answer

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.