51 RBAC: Role-Based Access Control in Kubernetes

51.1 Einführung

Role-Based Access Control (RBAC) ist das primäre Autorisierungssystem in Kubernetes, das granulare Zugriffskontrolle auf Cluster-Ressourcen ermöglicht. RBAC folgt dem Prinzip der minimalen Berechtigung (Least Privilege) und ermöglicht es, Benutzern und Services nur die notwendigen Berechtigungen zu gewähren, die sie für ihre Aufgaben benötigen.

51.2 Was ist RBAC?

RBAC ist ein Autorisierungsmodell, das Zugriff auf Kubernetes-Ressourcen basierend auf Rollen steuert. Es definiert, wer (Subject) was (Resource) wie (Verb) in welchem Bereich (Namespace/Cluster) tun darf.

Kernprinzipien: - Rollenbasierte Zugriffskontrolle: Berechtigungen werden in Rollen gebündelt - Granulare Berechtigungen: Feinjustierte Kontrolle über API-Zugriffe - Namespace-Isolation: Bereichsspezifische Berechtigungsvergabe - Least Privilege: Minimale erforderliche Berechtigungen

51.3 Abgrenzung zu anderen Autorisierungsmethoden

Methode Beschreibung Anwendungsbereich Komplexität
RBAC Rollenbasierte Zugriffskontrolle Standard-Autorisierung Mittel
ABAC Attribute-Based Access Control Komplexe Policy-Szenarien Hoch
Webhook Externe Autorisierung Custom Authorization Logic Variabel
Node Node-spezifische Autorisierung Kubelet-Zugriff Niedrig
AlwaysAllow Keine Autorisierung Development/Testing Keine

RBAC als Standard: Seit Kubernetes 1.8 ist RBAC standardmäßig aktiviert und die empfohlene Autorisierungsmethode für produktive Cluster.

51.4 Kernkonzepte

51.4.1 Subjects (Subjekte)

User Accounts: - Externe Benutzer (Menschen oder externe Services) - Werden nicht direkt in Kubernetes verwaltet - Integration über externe Identity Provider (OIDC, LDAP, etc.)

Service Accounts: - Kubernetes-native Identitäten für Pods und Services - Automatisch verwaltete Credentials - Namespace-spezifisch

Groups: - Sammlung von Benutzern oder Service Accounts - Vereinfachen die Rollenverwaltung für Teams - Können über externe Identity Provider bereitgestellt werden

51.4.2 Resources (Ressourcen)

Kubernetes-API-Objekte, auf die zugegriffen werden kann:

# Core Resources
resources: ["pods", "services", "configmaps", "secrets"]

# Apps Resources  
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]

# RBAC Resources
resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

# Custom Resources
resources: ["customresourcedefinitions", "mycustomresource"]

# Subresources
resources: ["pods/log", "pods/exec", "deployments/scale"]

51.4.3 Verbs (Aktionen)

Definieren, welche Operationen auf Ressourcen ausgeführt werden dürfen:

# Standard CRUD Operations
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

# Administrative Operations  
verbs: ["deletecollection", "escalate", "impersonate"]

# Special Verbs
verbs: ["use"]  # Für PodSecurityPolicies, NetworkPolicies
verbs: ["bind"] # Für Roles und ClusterRoles

51.4.4 API Groups

Organisieren verwandte Ressourcen:

# Core Group (leer)
apiGroups: [""]

# Named Groups
apiGroups: ["apps", "extensions", "rbac.authorization.k8s.io"]

# Custom Groups
apiGroups: ["custom.company.com"]

# Wildcard (nicht empfohlen)
apiGroups: ["*"]

51.5 RBAC-Objekte

51.5.1 Role vs. ClusterRole

Role (Namespace-begrenzt):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

ClusterRole (Cluster-weit):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "namespaces", "persistentvolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles", "clusterrolebindings"]
  verbs: ["get", "list"]

51.5.2 RoleBinding vs. ClusterRoleBinding

RoleBinding (Namespace-begrenzt):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: developer-sa
  namespace: development
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding (Cluster-weit):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-reader-binding
subjects:
- kind: User
  name: monitoring-user
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: sre-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-reader
  apiGroup: rbac.authorization.k8s.io

51.6 Praktische Beispiele

51.6.1 Beispiel 1: Entwickler-Rolle für Namespace

Vollständige Konfiguration für Entwickler mit eingeschränkten Berechtigungen:

# Service Account für Entwickler
apiVersion: v1
kind: ServiceAccount
metadata:
  name: developer-sa
  namespace: development
---
# Entwickler-Rolle mit Pod-Management
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: developer-role
rules:
# Pod Management
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# Service Management  
- apiGroups: [""]
  resources: ["services", "endpoints"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# ConfigMap und Secret (eingeschränkt)
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]  # Nur Lesen
# Deployment Management
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments/scale"]
  verbs: ["get", "update", "patch"]
# Ingress Management
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
# RoleBinding für Entwickler
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
- kind: User  
  name: bob
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: developer-sa
  namespace: development
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

51.6.2 Beispiel 2: Read-Only Monitoring-Zugriff

Cluster-weite Leseberechtigungen für Monitoring-Services:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-reader
rules:
# Node und Cluster-Metriken
- apiGroups: [""]
  resources: ["nodes", "nodes/metrics", "nodes/stats"]
  verbs: ["get", "list"]
# Pod und Container-Metriken  
- apiGroups: [""]
  resources: ["pods", "pods/status", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
# Deployment-Informationen
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch"]
# Resource Quotas und Limits
- apiGroups: [""]
  resources: ["resourcequotas", "limitranges"]
  verbs: ["get", "list"]
# Custom Metrics (falls verwendet)
- apiGroups: ["metrics.k8s.io"]
  resources: ["*"]
  verbs: ["get", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitoring-sa
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-reader-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
- kind: User
  name: prometheus-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: monitoring-reader
  apiGroup: rbac.authorization.k8s.io

51.6.3 Beispiel 3: Namespace-Administrator

Vollständige Kontrolle über einen Namespace ohne Cluster-Berechtigungen:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: namespace-admin
rules:
# Vollzugriff auf alle Core-Ressourcen
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]
# Vollzugriff auf Apps
- apiGroups: ["apps"]
  resources: ["*"]
  verbs: ["*"]
# Netzwerk-Ressourcen
- apiGroups: ["networking.k8s.io"]
  resources: ["*"]
  verbs: ["*"]
# Batch Jobs
- apiGroups: ["batch"]
  resources: ["*"]
  verbs: ["*"]
# Namespace-lokale RBAC (wichtig!)
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings"]
  verbs: ["*"]
# Storage
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-binding
  namespace: production
subjects:
- kind: User
  name: team-lead
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: production-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: namespace-admin
  apiGroup: rbac.authorization.k8s.io

51.7 Service Account Management

51.7.1 Service Account für Pods

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account
  namespace: default
automountServiceAccountToken: true  # Standard
---
# Secret wird automatisch erstellt (Kubernetes < 1.24)
# Für Kubernetes >= 1.24 manuell erstellen:
apiVersion: v1
kind: Secret
metadata:
  name: app-service-account-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: app-service-account
type: kubernetes.io/service-account-token
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      serviceAccountName: app-service-account
      containers:
      - name: app
        image: my-app:latest

51.7.2 Token-Management (Kubernetes 1.24+)

# Explizite Token-Erstellung
apiVersion: v1
kind: Secret
metadata:
  name: long-lived-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: app-service-account
type: kubernetes.io/service-account-token
---
# Kurzlebige Token über TokenRequest API
# kubectl create token app-service-account --duration=3600s

51.8 Erweiterte RBAC-Funktionen

51.8.1 Aggregation Rules

Ermöglichen dynamische Zusammenstellung von ClusterRoles:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregated-reader
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-reader: "true"
rules: []  # Wird automatisch befüllt
---
# Komponenten-spezifische Rolle
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-reader
  labels:
    rbac.example.com/aggregate-to-reader: "true"
rules:
- apiGroups: ["custom.company.com"]
  resources: ["customresources"]
  verbs: ["get", "list", "watch"]

51.8.2 Resource Names

Zugriff auf spezifische Ressourcen-Instanzen:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["database-credentials", "api-keys"]
  verbs: ["get"]

51.8.3 Subresource-Zugriff

Granulare Kontrolle über Subressourcen:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-logger
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

51.9 Testing und Validierung

51.9.1 Auth Can-I Checks

# Als aktueller Benutzer
kubectl auth can-i create pods
kubectl auth can-i delete deployments --namespace=production

# Als anderer Benutzer
kubectl auth can-i create pods --as=alice
kubectl auth can-i "*" "*" --as=system:serviceaccount:default:my-sa

# Alle Berechtigungen auflisten
kubectl auth can-i --list
kubectl auth can-i --list --as=alice --namespace=development

51.9.2 RBAC-Debugging

# ClusterRoleBindings für einen Benutzer finden
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.subjects[]?.name=="alice") | .metadata.name'

# RoleBindings in einem Namespace
kubectl get rolebindings -n development -o wide

# Effektive Berechtigungen analysieren
kubectl describe clusterrole cluster-admin
kubectl describe rolebinding developer-binding -n development

51.10 Best Practices

51.10.1 Least Privilege Principle

# Schlecht: Zu breite Berechtigungen
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# Gut: Spezifische Berechtigungen
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "update", "patch"]
  resourceNames: ["my-specific-deployment"]

51.10.2 Service Account Security

# Sichere Service Account Konfiguration
apiVersion: v1
kind: ServiceAccount
metadata:
  name: secure-sa
  namespace: production
automountServiceAccountToken: false  # Deaktivieren wenn nicht benötigt
---
# Pod-spezifische Aktivierung
apiVersion: v1
kind: Pod
spec:
  serviceAccountName: secure-sa
  automountServiceAccountToken: true  # Explizit aktivieren
  containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true
      runAsNonRoot: true

51.10.3 Regelmäßige RBAC-Audits

# Ungenutzte Service Accounts finden
kubectl get serviceaccounts --all-namespaces -o json | \
  jq -r '.items[] | select(.metadata.name != "default") | "\(.metadata.namespace)/\(.metadata.name)"'

# Cluster-Admin Berechtigungen auflisten
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

# Privilegierte Pods identifizieren
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.securityContext.privileged==true) | "\(.metadata.namespace)/\(.metadata.name)"'

51.10.4 Namespace-Isolation

# Netzwerk-Isolation ergänzen
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# ResourceQuota für Ressourcen-Kontrolle
apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "10"

51.11 Troubleshooting

51.11.1 Zugriff verweigert (403 Forbidden)

Symptom: API-Aufrufe werden mit “403 Forbidden” abgelehnt

Diagnose:

# Aktuelle Berechtigungen prüfen
kubectl auth can-i <verb> <resource> --namespace=<namespace>

# Benutzer-Identität verifizieren
kubectl auth whoami

# Effective RBAC Rules analysieren
kubectl describe clusterrolebinding <binding-name>
kubectl describe rolebinding <binding-name> -n <namespace>

Häufige Ursachen und Lösungen: - Falsche RoleBinding-Subjects: Subject-Namen und API-Groups überprüfen - Namespace-Mismatch: RoleBinding im korrekten Namespace erstellen - Fehlende Verbs: Alle erforderlichen Verbs in Role definieren - API-Group-Fehler: Korrekte API-Groups für Ressourcen verwenden

51.11.2 Service Account Token-Probleme

Symptom: Pods können nicht auf Kubernetes-API zugreifen

Diagnose:

# Service Account Token prüfen
kubectl get secrets -o json | jq -r '.items[] | select(.type=="kubernetes.io/service-account-token")'

# Pod-Token-Mount überprüfen
kubectl exec <pod-name> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Token-Gültigkeit testen
kubectl exec <pod-name> -- curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/default/pods

Lösungsansätze: - Token nicht gemountet: automountServiceAccountToken: true setzen - Token abgelaufen: Neue Token erstellen (Kubernetes 1.24+) - Falsche Service Account: Korrekte serviceAccountName in Pod-Spec

51.11.3 RBAC-Regel-Konflikte

Symptom: Unerwartete Berechtigungen oder verweigerte Zugriffe

Diagnose:

# Alle Bindings für einen Benutzer
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq -r '.items[] | select(.subjects[]?.name=="<username>") | "\(.kind): \(.metadata.name) -> \(.roleRef.name)"'

# Überlappende Rollen identifizieren
kubectl describe clusterrole <role1>
kubectl describe clusterrole <role2>

Best Practice: RBAC-Regeln dokumentieren und regelmäßig auditieren

51.12 Integration mit externen Identity Providern

51.12.1 OIDC-Integration

# Cluster-Konfiguration (kubeadm)
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
  extraArgs:
    oidc-issuer-url: "https://oidc.company.com"
    oidc-client-id: "kubernetes"
    oidc-username-claim: "email"
    oidc-groups-claim: "groups"
    oidc-ca-file: "/etc/kubernetes/pki/oidc-ca.crt"

51.12.2 Group-basierte Autorisierung

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developers-binding
subjects:
- kind: Group
  name: "developers@company.com"  # Von OIDC Provider
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: "sre-team@company.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

51.13 Monitoring und Auditing

51.13.1 RBAC-Metriken

# ServiceMonitor für RBAC-Metriken
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: rbac-metrics
spec:
  selector:
    matchLabels:
      app: kube-rbac-proxy
  endpoints:
  - port: https
    scheme: https
    tlsConfig:
      insecureSkipVerify: true

51.13.2 Audit-Logging für RBAC

# Audit Policy für RBAC-Events
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["*"]
- level: Request
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: ""
    resources: ["serviceaccounts"]

51.14 Erweiterte Sicherheitspatterns

51.14.1 Multi-Tenancy mit RBAC

# Tenant-spezifische ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tenant-admin
rules:
# Namespace-Management für eigene Tenants
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]
  resourceNames: ["tenant-a-*", "tenant-b-*"]
# Keine Cluster-Ressourcen
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list"]
---
# Tenant-isolierte RoleBindings
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-a-admin
  namespace: tenant-a-production
subjects:
- kind: Group
  name: "tenant-a-admins"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin  # Built-in admin role
  apiGroup: rbac.authorization.k8s.io

51.14.2 Custom Resource RBAC

# Custom Resource Definition
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.platform.company.com
spec:
  group: platform.company.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
---
# RBAC für Custom Resources
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: application-manager
rules:
- apiGroups: ["platform.company.com"]
  resources: ["applications"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["platform.company.com"]
  resources: ["applications/status"]
  verbs: ["get", "update", "patch"]

51.15 Fazit

RBAC ist ein fundamentaler Baustein für die Sicherheit von Kubernetes-Clustern. Es ermöglicht granulare Zugriffskontrolle und folgt modernen Security-Prinzipien wie Least Privilege und Defense in Depth. Die korrekte Implementierung von RBAC erfordert sorgfältige Planung der Berechtigungsstrukturen und regelmäßige Audits.

Die vorgestellten Patterns und Best Practices helfen dabei, sichere und wartbare RBAC-Konfigurationen zu erstellen, die sowohl die Sicherheitsanforderungen erfüllen als auch die operative Effizienz unterstützen. Besonders wichtig ist die Integration mit organisatorischen Strukturen und externen Identity Managern für eine konsistente und skalierbare Berechtigungsverwaltung.