Kubernetes Role-Based Access Control(RBAC)

Reading time: 6 minutes

Role-Based Access Control (RBAC)

Kubernetes hat ein Autorisierungsmodul namens Role-Based Access Control (RBAC), das hilft, Berechtigungen für den API-Server festzulegen.

Das Berechtigungsmodell von RBAC besteht aus drei einzelnen Teilen:

1. Role\ClusterRole ­– Die tatsächliche Berechtigung. Sie enthält Regeln, die eine Menge von Berechtigungen darstellen. Jede Regel enthält Ressourcen und Verben. Das Verb ist die Aktion, die auf die Ressource angewendet wird.
2. Subjekt (Benutzer, Gruppe oder ServiceAccount) – Das Objekt, das die Berechtigungen erhält.
3. RoleBinding\ClusterRoleBinding – Die Verbindung zwischen Role\ClusterRole und dem Subjekt.

Der Unterschied zwischen “Roles” und “ClusterRoles” liegt nur darin, wo die Rolle angewendet wird – eine “Role” gewährt Zugriff auf nur ein bestimmtes Namespace, während eine “ClusterRole” in allen Namespaces im Cluster verwendet werden kann. Darüber hinaus können ClusterRoles auch Zugriff auf gewähren:

• cluster-scoped Ressourcen (wie Knoten).
• non-resource Endpunkte (wie /healthz).
• namespaced Ressourcen (wie Pods), über alle Namespaces hinweg.

Ab Kubernetes 1.6 sind RBAC-Richtlinien standardmäßig aktiviert. Um RBAC zu aktivieren, können Sie etwas wie verwenden:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Vorlagen

Im Template eines Role oder ClusterRole müssen Sie den Namen der Rolle, den Namespace (in Rollen) und dann die apiGroups, Ressourcen und Verben der Rolle angeben:

• Die apiGroups ist ein Array, das die verschiedenen API-Namespaces enthält, auf die diese Regel zutrifft. Zum Beispiel verwendet eine Pod-Definition apiVersion: v1. Es kann Werte wie rbac.authorization.k8s.io oder [*] haben.
• Die Ressourcen ist ein Array, das definiert, auf welche Ressourcen diese Regel zutrifft. Sie können alle Ressourcen mit: kubectl api-resources --namespaced=true finden.
• Die Verben ist ein Array, das die erlaubten Verben enthält. Das Verb in Kubernetes definiert die Art der Aktion, die Sie auf die Ressource anwenden müssen. Zum Beispiel wird das List-Verben gegen Sammlungen verwendet, während "get" gegen eine einzelne Ressource verwendet wird.

Regeln Verben

(Diese Informationen stammen aus den Docs)

Kubernetes überprüft manchmal die Autorisierung für zusätzliche Berechtigungen mit spezialisierten Verben. Zum Beispiel:

• PodSecurityPolicy
• use Verb auf podsecuritypolicies Ressourcen in der policy API-Gruppe.
• RBAC
• bind und escalate Verben auf roles und clusterroles Ressourcen in der rbac.authorization.k8s.io API-Gruppe.
• Authentifizierung
• impersonate Verb auf users, groups und serviceaccounts in der Kern-API-Gruppe und die userextras in der authentication.k8s.io API-Gruppe.

Beispiele

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Zum Beispiel können Sie eine ClusterRole verwenden, um einem bestimmten Benutzer zu erlauben, Folgendes auszuführen:

kubectl get pods --all-namespaces

RoleBinding und ClusterRoleBinding

Aus den Dokumenten: Ein RoleBinding gewährt die in einer Rolle definierten Berechtigungen an einen Benutzer oder eine Gruppe von Benutzern. Es enthält eine Liste von Subjekten (Benutzern, Gruppen oder Dienstkonten) und einen Verweis auf die zu gewährende Rolle. Ein RoleBinding gewährt Berechtigungen innerhalb eines bestimmten Namespaces, während ein ClusterRoleBinding diesen Zugriff clusterweit gewährt.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Berechtigungen sind additiv, sodass Sie ein clusterRole mit „list“ und „delete“ Secrets haben können, das Sie mit einer Rolle mit „get“ hinzufügen können. Seien Sie sich dessen bewusst und testen Sie immer Ihre Rollen und Berechtigungen und geben Sie an, was ERLAUBT ist, denn alles ist standardmäßig VERWEIGERT.

Auflisten von RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Missbrauch von Rollen/ClusterRoles zur Privilegieneskalation

Abusing Roles/ClusterRoles in Kubernetes