Einführung
Die Kubernetes-Authentifizierung identifiziert den Aufrufer; die Autorisierung legt fest, was diese Identität tun darf. RBAC beschreibt Berechtigungen als Verben für API-Ressourcen und weist sie Benutzern, Gruppen oder ServiceAccounts zu.
Sie erstellen einen auf einen Namespace begrenzten Leser, verknüpfen seine Identität mit Berechtigungen und überprüfen anschließend durch Identitätsvortäuschung sowohl erlaubte als auch verweigerte Zugriffe.
RBAC lässt sich leichter verstehen, wenn man es auf drei Fragen reduziert: Wer? (ServiceAccount), Was darf diese Identität tun? (Role) und Wer erhält diese Berechtigungen? (RoleBinding). Erst wenn alle drei Objekte vorhanden sind, ist der Autorisierungspfad vollständig.
Eine ServiceAccount-Identität erstellen
Erstellen Sie in diesem Schritt einen auf einen Namespace begrenzten ServiceAccount für eine Anwendungskomponente.
Ein ServiceAccount ist eine Kubernetes-API-Identität für Workloads und automatisierte Prozesse. Er ist kein Linux-Benutzer innerhalb des Containers. Eine eigene Identität für dieses Beispiel verhindert, dass die Anwendung den standardmäßigen ServiceAccount des Namespace übernimmt.
cd /home/labex/project/rbac-access
kubectl create serviceaccount inventory-reader -n practice-rbac
kubectl get serviceaccount inventory-reader -n practice-rbac -o yaml
Die vollständige Identität lautet system:serviceaccount:practice-rbac:inventory-reader. Das alleinige Erstellen einer Identität gewährt noch keine Anwendungsberechtigungen.
In der YAML-Ausgabe bestätigen die Metadaten den Namespace und den Namen. Erwarten Sie nicht, dass automatisch ein langlebiges Token-Secret angezeigt wird; moderne Kubernetes-Projekte kurzlebige Tokens bei Bedarf in Pods.
Das zurückgegebene Objekt enthält den festgelegten Namen und Namespace, aber kein automatisch erzeugtes Token-Secret:
kind: ServiceAccount
metadata:
name: inventory-reader
namespace: practice-rbac
Auf den Namespace begrenzte Berechtigungen definieren
Erstellen Sie in diesem Schritt eine Role, die ausschließlich im Namespace practice-rbac das Lesen von Pods und ConfigMaps erlaubt.
Jede Regel kombiniert API-Gruppen, Ressourcen und Verben. Für Kernressourcen wie Pods und ConfigMaps steht apiGroups: [""] für die leere Zeichenfolge. Die Verben get, list und watch beschreiben das Lesen einzelner Objekte, das Lesen von Sammlungen und das Verfolgen von Änderungen.
cd /home/labex/project/rbac-access
cat <<'EOF' > inventory-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: inventory-reader, namespace: practice-rbac}
rules:
- apiGroups: [""]
resources: [pods, configmaps]
verbs: [get, list, watch]
EOF
Wenden Sie die Role an und lassen Sie sie beschreiben. describe stellt die Richtlinienregeln in einer Tabelle dar, die sich leichter prüfen lässt als rohes YAML:
kubectl apply -f inventory-role.yaml
kubectl describe role inventory-reader -n practice-rbac
Die leere API-Gruppe wählt Kernressourcen aus. Eine Role gewährt niemals Zugriff außerhalb ihres Namespace.
Beachten Sie außerdem, was fehlt: Es gibt kein create, update, patch oder delete. Das Prinzip der geringsten Berechtigung wird ebenso durch weggelassene wie durch erteilte Berechtigungen bestimmt.
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
configmaps [] [] [get list watch]
pods [] [] [get list watch]
Die Tabelle stellt die kombinierte YAML-Regel als eine Zeile pro Ressource dar. Beide Zeilen enthalten dieselben drei schreibgeschützten Verben.
Die Role mit der Identität verknüpfen
Verknüpfen Sie in diesem Schritt die Role über eine RoleBinding mit dem ServiceAccount.
Der imperative Befehl ist kompakt, da beide Objekte bereits vorhanden sind. --role bezeichnet die Quelle der Berechtigungen, während --serviceaccount mit dem Format namespace:name das Subjekt identifiziert.
cd /home/labex/project/rbac-access
kubectl create rolebinding inventory-reader -n practice-rbac --role=inventory-reader --serviceaccount=practice-rbac:inventory-reader
kubectl get rolebinding inventory-reader -n practice-rbac -o yaml
roleRef bezeichnet die Berechtigungen; subjects bezeichnet die Identitäten, die diese erhalten. Beide bleiben hier auf den Namespace begrenzt.
Eine Role und ein ServiceAccount mit demselben Namen bleiben voneinander unabhängig, bis diese Verknüpfung besteht. Namen dienen der Orientierung für Menschen; die RoleBinding stellt die tatsächliche Autorisierungsverbindung her.
Verfolgen Sie im YAML die Verbindung von roleRef.name: inventory-reader zu dem Subjekt mit dem Typ ServiceAccount, dem Namen inventory-reader und dem Namespace practice-rbac.
Erlaubte und verweigerte Aktionen testen
Verwenden Sie in diesem Schritt kubectl auth can-i zusammen mit --as, um die Identität des ServiceAccount vorzutäuschen.
Für Autorisierungstests sind sowohl positive als auch negative Fälle erforderlich. Ein yes bestätigt, dass die benötigte Aufgabe möglich ist, während ein no belegt, dass destruktive Aktionen und Zugriffe auf andere Namespaces nicht versehentlich gewährt wurden.
cd /home/labex/project/rbac-access
IDENTITY=system:serviceaccount:practice-rbac:inventory-reader
kubectl auth can-i list pods -n practice-rbac --as="$IDENTITY"
kubectl auth can-i get configmaps -n practice-rbac --as="$IDENTITY"
kubectl auth can-i delete pods -n practice-rbac --as="$IDENTITY" || true
kubectl auth can-i list pods -n default --as="$IDENTITY" || true
Die ersten beiden Antworten sollten yes lauten; das Löschen und das Auflisten von Pods in einem anderen Namespace sollten jeweils no ergeben. Die Identitätsvortäuschung testet die Autorisierung, ohne ein Token offenzulegen oder zu erstellen.
kubectl auth can-i liefert zusammen mit der Antwort no einen Status ungleich null für die Shell. Die beiden Endungen || true sorgen dafür, dass der beabsichtigte Verweigerungstest fortgesetzt wird; sie ändern nichts an der Autorisierungsentscheidung.
yes
yes
no
no
Lesen Sie diese Ergebnisse als zwei erforderliche Fähigkeiten, gefolgt von zwei geschützten Grenzen. Eine Testreihe, die nur aus yes-Antworten besteht, würde das Prinzip der geringsten Berechtigung nicht nachweisen.
Der aktuelle Laborbenutzer darf diesen ServiceAccount zu Testzwecken imitieren. --as ändert für diesen Befehl die vom API-Server ausgewertete Identität; es ändert weder Ihren Shell-Benutzer noch wechselt es dauerhaft die von kubectl verwendeten Zugangsdaten.
Zusammenfassung
Sie haben einen ServiceAccount erstellt, schreibgeschützte Namespace-Berechtigungen mit einer Role beschrieben, diese über eine RoleBinding zugewiesen und mithilfe von Identitätsvortäuschung sowohl erlaubte als auch verweigerte Aktionen nachgewiesen.
