Kubernetes-Anwendungsrollen/Rechte festlegen

Kubernetes bietet mehrere Hauptautorisierungsmechanismen, um zu kontrollieren, wer über die Kubernetes-API Änderungen am Cluster vornehmen kann. Dazu gehören Tools wie kubectl, Systemkomponenten und Anwendungen, die im Cluster ausgeführt werden und dessen Zustand manipulieren, wie z. B. Jenkins mit dem Kubernetes-Plugin oder Helm. Unter den verfügbaren Autorisierungsmechanismen sind die attributbasierte Zugriffskontrolle (ABAC) und die rollenbasierte Zugriffskontrolle (RBAC) diejenigen, die lokal in einem Kubernetes-Cluster ausgeführt werden und konfigurierbare Autorisierungsrichtlinien ermöglichen. RBAC wird aufgrund seiner einfachen Verwaltung, Flexibilität und Sicherheitsvorteile bevorzugt.

RBAC vs. ABAC

ABAC (Attribute-Based Access Control)

ABAC ist zwar leistungsstark, hat aber auch einige Nachteile:

Komplexität: Im Vergleich zu RBAC schwieriger zu verwalten und zu verstehen.
Sicherheitsrisiken: Erfordert SSH und Root-Dateisystemzugriff auf die Master-Host-VM.
Betrieblicher Mehraufwand: Die Cluster-API muss neu gestartet werden, damit die Änderungen wirksam werden.

RBAC (Role-Based Access Control)

RBAC ist aufgrund seiner Einfachheit und Flexibilität der bevorzugte Autorisierungsmechanismus:

Einfaches Management: Konfigurationen werden mit kubectl oder direkt über die Kubernetes-API vorgenommen.
Delegation: Benutzer können autorisiert werden, Änderungen an Autorisierungsrichtlinien vorzunehmen.
Granularität: Richtlinien können einfach auf die in der Kubernetes-API verwendeten Ressourcen und Operationen abgebildet werden.

Was lässt sich mit RBAC einschränken?

RBAC ermöglicht die Einschränkung von Aktionen (Verben) auf Ressourcen. Die folgenden Verben können in RBAC-Richtlinien verwendet werden:

list: Ermöglicht das Auflisten von Ressourcen, z. B. kubectl get pods.
get: Ermöglicht das Abrufen einer bestimmten Ressource, z. B. kubectl get pod <Name>.
watch: Ermöglicht das Beobachten von Änderungen an Ressourcen, typischerweise verwendet mit list oder get.
create: Ermöglicht das Erstellen neuer Ressourcen.
delete: Ermöglicht das Löschen von Ressourcen.
deletecollection: Ermöglicht das Löschen von mehreren Ressourcen.
patch: Ermöglicht das Ändern von Ressourcen.
update: Ermöglicht das Aktualisieren von Ressourcen mit kubectl replace.

Beispiel einer RBAC-Konfiguration

Benutzerspezifisches RBAC

In kleinen Teams oder speziellen Szenarien kann jeder Benutzer bestimmte Rechte erhalten. Dieser Ansatz kann jedoch zu komplexen und schwer zu verwaltenden Konfigurationen führen.

Rollenspezifisches RBAC

Ein skalierbarerer Ansatz ist die Definition von Rollen auf der Grundlage von Zuständigkeiten und die Zuweisung dieser Rollen an Benutzer. Dies reduziert den Verwaltungsaufwand und gewährleistet Konsistenz.

Schlüsselrollen und Zuständigkeiten

Cluster Admin
- Zuständigkeiten: Erstellen des Clusters, Hinzufügen/Entfernen von Knoten, Verwalten der Control Plane, Festlegen von Taints, Toleranzen, Knotenaffinitäten und ClusterRoles.
- Rolle: Verwendung der eingebauten cluster-admin ClusterRoleBinding.
```
kubectl get clusterrole cluster-admin kubectl get clusterrolebinding cluster-admin
```

Schöpfer des Namensraums

Zuständigkeiten: Anlegen von Namespaces und Zuweisung von Rollen, Erstellen von Namespace-spezifischen PodSecurityPolicies.
Rolle: Benötigt alle Verben für Namespaces und PodSecuritypolicies sowie Rollen.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-creator
rules:
- apiGroups: [""]
  resources: ["namespaces", "roles"]
  verbs: ["create", "get", "list", "watch", "delete"]
- apiGroups: ["policy"]
  resources: ["podsecuritypolicies"]
  verbs: ["create", "get", "list", "watch", "delete"]

Secret Admin
- Zuständigkeiten: Verwaltung von Geheimnissen und PKIs, Bearbeitung von Anträgen auf Unterzeichnung von Zertifikaten.
- Rolle: Benötigt Zugang zu allen Geheimnissen und Zertifikatsignierungsaufträgen.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-admin
rules:
- apiGroups: [""]
  resources: ["secrets", "certificatesigningrequests"]
  verbs: ["create", "get", "list", "watch", "delete"]
```
Service Manager
- Zuständigkeiten: Verwaltung spezifischer Dienste innerhalb von Namensräumen, Sicherstellung von Leistung und Lastmanagement.
- Rolle: Musterrolle für dienstspezifische Zuständigkeiten.

Netzwerk Admin

Zuständigkeiten: Verwaltung von Netzwerkrichtlinien, Ingress-Controllern und Behebung von Netzwerkproblemen.
Rolle: Benötigt Zugang zu Netzwerkressourcen.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: network-admin
rules:
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies", "ingresses", "ingressclasses"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get"]

Speicherverwaltung

Zuständigkeiten: Verwaltung von Speicherressourcen, Behebung von Speicherproblemen.
Rolle: Benötigt Zugang zu Speicherressourcen.apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole
metadata:
  name: storage-admin
rules:
- apiGroups: ["storage.k8s.io"]
  resources: ["csidrivers", "csinodes", "storageclasses", "volumeattachments"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]

Application Manager

Zuständigkeiten: Bereitstellung und Verwaltung von Anwendungen, Sicherstellung der ordnungsgemäßen Kennzeichnung, Umgang mit Configmaps, Secrets und Services.
Rolle: Benötigt Zugang zu anwendungsbezogenen Ressourcen innerhalb von Namespaces.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: application-deployer
  namespace: <namespace>
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
- apiGroups: [""]
  resources: ["configmaps", "persistentvolumeclaims", "pods", "secrets", "services", "serviceaccounts"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]

Nur-Lese-Rolle (Ansicht)

Zuständigkeiten: Ermöglicht den Nur-Lese-Zugriff zur Ansicht der meisten Objekte.
Rolle: Nützlich für Vorgesetzte, Gäste, Berater.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-access
subjects:
- kind: User
  name: <username>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Schlussfolgerung

Die Implementierung einer gut definierten RBAC-Richtlinie in Kubernetes stellt sicher, dass Rollen und Verantwortlichkeiten klar abgegrenzt sind, wodurch der Verwaltungsaufwand reduziert und die Sicherheit erhöht wird. Durch die Befolgung des rollenspezifischen RBAC-Ansatzes können Sie Zugriffskontrollen effizient verwalten, Verantwortlichkeiten delegieren und einen sicheren und gut organisierten Cluster pflegen. Überprüfen und aktualisieren Sie diese Richtlinien regelmäßig, um sie an die sich wandelnden Anforderungen Ihres Unternehmens anzupassen und die Einhaltung bewährter Sicherheitsverfahren zu gewährleisten.

Risiken