40 Rollenbasierte Zugriffskontrolle (RBAC)

Rollenbasierte Zugriffskontrolle in OpenShift implementiert granulare Autorisierungsmechanismen durch berechtigungsbasierte Zugriffskontrollmodelle mit Rollendefinition, Berechtigungszuweisung und Richtliniendurchsetzung. Diese RBAC-Frameworks ermöglichen die Umsetzung des Prinzips der minimalen Berechtigungen und organisatorische Sicherheits-Governance für sichere Multi-Tenant-Plattformoperationen.

40.1 Grundlagen von RBAC in OpenShift

OpenShifts RBAC-Architektur trennt Benutzer, Rollen und Berechtigungen durch Abstraktionsebenen, die flexible Berechtigungszuweisungen ohne direkte Benutzer-zu-Berechtigung-Zuordnung ermöglichen. Diese rollenbasierte Zugriffskontrolle reduziert die administrative Komplexität für umfangreiches Berechtigungsmanagement.

Die Berechtigungsgranularität umfasst Ressourcentyp, Ressourceninstanz, Namespace-Bereich und Aktionsspezifität für feinabgestimmte Zugriffskontrolle. Dieses mehrdimensionale Berechtigungsmodell ermöglicht präzise Autorisierungsrichtlinien.

[Diagramm: RBAC-Architektur mit Rollen, Berechtigungen und Bindungen]

40.1.1 RBAC-Komponenten

Subjects (Subjekte) sind Entitäten, die Aktionen ausführen können - Benutzer, Gruppen oder Service-Accounts. Sie sind die “Wer” in der Autorisierungsgleichung.

Roles (Rollen) definieren Sammlungen von Berechtigungen. Sie spezifizieren, welche Aktionen auf welchen Ressourcen ausgeführt werden dürfen.

RoleBindings verknüpfen Subjects mit Rollen und definieren damit, wer welche Berechtigungen hat.

Resources (Ressourcen) sind die OpenShift/Kubernetes-Objekte, auf die zugegriffen werden soll - Pods, Services, Deployments, etc.

Verbs (Verben) sind die Aktionen, die auf Ressourcen ausgeführt werden können - get, list, create, update, delete, etc.

40.1.2 Berechtigungsmodell

OpenShift verwendet ein additives Berechtigungsmodell - Berechtigungen werden gewährt, nicht verweigert. Wenn keine explizite Berechtigung vorhanden ist, wird der Zugriff verweigert. Dies folgt dem Prinzip der minimalen Berechtigungen.

Rollenhierarchie-Unterstützung implementiert Rollenvererbungsmechanismen für die Abbildung von Organisationsstrukturen und Berechtigungsvererbung. Diese hierarchische RBAC unterstützt komplexe organisatorische Berechtigungsmodelle.

40.2 Rollendefinition und Berechtigungszuordnung

OpenShift unterscheidet zwischen zwei Arten von Rollen: Cluster Roles und (Namespace-spezifische) Roles.

40.2.1 Cluster Roles

Cluster Roles definieren plattformweite Berechtigungen für namespace-übergreifende Operationen und Cluster-Administrationsaufgaben. Diese globalen Rollen ermöglichen administrativen Zugriff und Plattform-Management-Funktionen.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

40.2.2 Namespace Roles

Namespace Roles beschränken Berechtigungen auf spezifische Namespaces für projektbezogene Zugriffskontrolle. Diese lokalen Rollen implementieren Sicherheitsgrenzen auf Projektebene und Multi-Tenancy-Unterstützung.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-manager
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "update", "delete"]

40.2.3 Custom Role Creation

Custom-Rollenerstellung ermöglicht organisationsspezifische Rollendefinitionen mit maßgeschneiderten Berechtigungssätzen für einzigartige Geschäftsanforderungen. Diese benutzerdefinierten Rollen unterstützen flexible Autorisierungsmodelle.

Beispiel für eine Custom Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list"]
  resourceNames: ["app-config", "app-secrets"]

40.3 Subject-Typen und Zuweisungsmuster

RBAC unterstützt verschiedene Arten von Subjects, die jeweils unterschiedliche Anwendungsfälle abdecken.

40.3.1 User Role Bindings

User Role Bindings verknüpfen einzelne Benutzer mit Rollen für direkte Berechtigungszuweisung. Diese direkten Benutzerzuweisungen bieten granulare Kontrolle für spezifische Benutzeranforderungen.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: alice@company.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

40.3.2 Group Role Bindings

Group Role Bindings ermöglichen kollektive Berechtigungszuweisung durch gruppenmitgliedschaftsbasierte Rollenzuweisung. Diese gruppenbasierten Zuweisungen reduzieren den administrativen Aufwand für große Benutzergruppen.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admins
subjects:
- kind: Group
  name: cluster-administrators
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

40.3.3 Service Account Role Bindings

Service Account Role Bindings gewähren automatisierten Systemen und Anwendungen spezifische Berechtigungen für Systemintegration. Diese Service-Zuweisungen unterstützen DevOps-Automatisierung und Inter-Service-Kommunikation.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: monitoring-binding
  namespace: monitoring
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: prometheus
  apiGroup: rbac.authorization.k8s.io

40.4 Berechtigungsbereiche und Ressourcenzugriff

OpenShift implementiert verschiedene Berechtigungsbereiche, um Sicherheitsgrenzen zu definieren und Multi-Tenancy zu unterstützen.

40.4.1 Namespace-Scoped Permissions

Namespace-basierte Berechtigungen beschränken Zugriff auf spezifische Namespaces für Sicherheitsisolation auf Projektebene. Diese Bereichsbeschränkungen implementieren Multi-Tenant-Sicherheitsgrenzen.

40.4.2 Cluster-Scoped Permissions

Cluster-basierte Berechtigungen ermöglichen plattformweiten Zugriff für administrative Operationen und namespace-übergreifendes Management. Diese globalen Berechtigungen sind für die Plattformadministration erforderlich.

40.4.3 Resource-Specific Permissions

Ressourcenspezifische Berechtigungen definieren granulare Zugriffskontrolle für einzelne Ressourcentypen und -instanzen. Diese Ressourcengranularität ermöglicht feinabgestimmte Autorisierungsrichtlinien.

40.5 Built-in Roles und Standardberechtigungen

OpenShift stellt mehrere vordefinierte Rollen bereit, die häufige Berechtigungsmuster abdecken.

40.5.1 Standard OpenShift Roles

40.5.2 Admin Role

Die Admin-Rolle gewährt vollständigen administrativen Zugriff innerhalb zugewiesener Namespaces für komplettes Projektmanagement. Diese administrative Rolle ermöglicht Projektebenen-Administration ohne cluster-weiten Zugriff.

Admin-Berechtigungen umfassen: - Alle Ressourcen in einem Namespace verwalten - RBAC-Einstellungen innerhalb des Namespaces ändern - Quotas und Limits anzeigen (aber nicht ändern) - Andere Benutzer zu Projekten hinzufügen

40.5.3 Edit Role

Die Edit-Rolle ermöglicht Ressourcenänderungszugriff ohne administrative Privilegien für entwicklerorientiierte Operationen. Diese Entwicklerrolle unterstützt Anwendungsentwicklungs-Workflows ohne Sicherheitsrisiko.

Edit-Berechtigungen umfassen: - Pods, Services, Deployments erstellen und ändern - ConfigMaps und Secrets verwalten - Routes und Builds erstellen - Keine RBAC-Änderungen oder Benutzer-Management

40.5.4 View Role

Die View-Rolle bietet Nur-Lese-Zugriff für Monitoring und Audit-Zwecke ohne Änderungsmöglichkeiten. Diese Beobachterrolle unterstützt Compliance-Monitoring und Systemobservability.

View-Berechtigungen beschränken sich auf: - Ressourcen anzeigen und auflisten - Logs lesen - Metriken abrufen - Keine Erstellung oder Änderung von Ressourcen

40.6 Security Context Constraints (SCC) Integration

SCCs erweitern RBAC um Container-Sicherheitsrichtlinien und definieren, unter welchen Sicherheitsbedingungen Container ausgeführt werden dürfen.

40.6.1 SCC-Zuweisungssteuerung

SCC-Zuweisungssteuerung definiert Container-Sicherheitsrichtlinien basierend auf Benutzerrollen und Service-Account-Berechtigungen. Diese Sicherheitsrichtlinienintegration erweitert RBAC um Container-Sicherheits-Governance.

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: custom-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowPrivilegedContainer: false
allowedCapabilities: null
runAsUser:
  type: MustRunAsNonRoot

40.6.2 Privilege Escalation Prevention

Privilege-Escalation-Verhinderung implementiert Kontrollen gegen unbefugte Rechteausweitung durch SCC-Richtliniendurchsetzung. Dieser Escalation-Schutz gewährleistet die Integrität von Sicherheitsgrenzen.

40.6.3 Standard SCCs

40.7 RBAC-Audit und Compliance-Management

OpenShift bietet umfangreiche Audit-Funktionen für RBAC-Compliance und Sicherheitsmonitoring.

40.7.1 Permission Audit Trails

Berechtigungs-Audit-Trails protokollieren alle Autorisierungsentscheidungen für Compliance-Berichterstattung und Sicherheitsanalyse. Diese Audit-Logs unterstützen regulatorische Compliance und Sicherheitsmonitoring.

# RBAC-Events in Audit-Logs anzeigen
oc adm node-logs --role=master --path=audit/audit.log | \
grep '"objectRef":.*"resource":".*binding"'

40.7.2 Access Review Processes

Zugriffs-Review-Prozesse implementieren regelmäßige Berechtigungsvalidierung für die Identifizierung ungenutzter oder übermäßiger Berechtigungen. Diese Zugriffs-Reviews gewährleisten die Einhaltung des Prinzips der minimalen Berechtigungen.

Wichtige Review-Fragen: - Welche Benutzer haben administrative Berechtigungen? - Gibt es ungenutzte Rollenbindungen? - Entsprechen die Berechtigungen den aktuellen Jobrollen? - Sind temporäre Berechtigungen noch aktiv?

40.7.3 Role Usage Analytics

Rollen-Nutzungsanalysen analysieren Rollenzuweisungsmuster und Berechtigungsnutzung für Optimierungsmöglichkeiten. Diese Analysen unterstützen RBAC-Optimierung und Sicherheitsverbesserungen.

40.8 Multi-Tenancy und Isolationsstrategien

OpenShift implementiert verschiedene Strategien für sichere Multi-Tenancy durch RBAC-basierte Isolation.

40.8.1 Tenant Isolation

Mandanten-Isolationsmechanismen implementieren vollständige Berechtigungstrennung zwischen verschiedenen Mandanten oder Organisationen. Diese Isolationskontrollen gewährleisten Multi-Tenant-Sicherheitsgrenzen.

Standardmäßig können Benutzer nur auf Projekte zugreifen, für die sie explizite Berechtigungen haben. Diese Isolation erfolgt automatisch durch OpenShifts RBAC-System.

40.8.2 Cross-Tenant Permission Sharing

Mandanten-übergreifende Berechtigungsfreigabe ermöglicht kontrollierten Zugriff zwischen Mandanten für Kollaborationsszenarien. Diese selektive Freigabe unterstützt mandanten-übergreifende Zusammenarbeit.

# Beispiel: Shared Service Account für monitoring
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cross-tenant-monitoring
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: tenant-a
- kind: ServiceAccount
  name: monitoring-sa
  namespace: tenant-b
roleRef:
  kind: ClusterRole
  name: monitoring-reader
  apiGroup: rbac.authorization.k8s.io

40.9 RBAC-Integration mit externen Systemen

OpenShift kann RBAC-Informationen mit externen Identity- und Policy-Systemen synchronisieren.

40.9.1 LDAP Group Integration

LDAP-Gruppen-Integration synchronisiert externe Gruppenmitgliedschaften mit OpenShift-Rollenzuweisungen für konsistentes Berechtigungsmanagement. Diese LDAP-Integration unterstützt die Nutzung bestehender Enterprise-Identity-Infrastrukturen.

40.9.2 Active Directory Integration

Active Directory-Integration ermöglicht Windows-Domain-basierte Rollenzuweisung für Hybrid-Umgebungs-Berechtigungsmanagement. Diese AD-Integration unterstützt Windows-Ökosystem-Integration.

40.9.3 Custom Authorization Webhooks

Custom Authorization Webhooks implementieren externe Autorisierungslogik für spezialisierte Berechtigungsanforderungen. Diese Webhook-Integration ermöglicht komplexe Autorisierungsmodelle.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionWebhook
metadata:
  name: custom-rbac-webhook
webhooks:
- name: rbac.example.com
  clientConfig:
    service:
      name: rbac-webhook
      namespace: rbac-system
      path: "/validate"
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["rolebindings", "clusterrolebindings"]

40.10 RBAC-Troubleshooting und Debugging

OpenShift bietet verschiedene Tools für RBAC-Diagnose und Fehlerbehebung.

40.10.1 Permission Debugging

# Berechtigungen eines Benutzers prüfen
oc auth can-i create pods --as=alice@company.com

# Alle Berechtigungen eines Service Accounts anzeigen
oc auth can-i --list --as=system:serviceaccount:default:builder

# Detaillierte Berechtigung für spezifische Ressource
oc auth can-i get secrets/mysecret -n production --as=bob@company.com

40.10.2 Access Denied Analysis

Zugriffs-verweigert-Analysen implementieren detaillierte Protokollierung für Autorisierungsfehler mit Lösungsanleitungen. Diese Fehleranalyse beschleunigt die Behebung von Berechtigungsproblemen.

Häufige RBAC-Probleme und Lösungen:

40.10.3 Role Conflict Detection

Rollen-Konflikt-Erkennung identifiziert widersprüchliche Berechtigungszuweisungen und Policy-Inkonsistenzen. Diese Konfliktserkennung gewährleistet RBAC-Modell-Konsistenz.

40.10.4 Effektive Berechtigungen ermitteln

# Effektive Berechtigungen für einen Benutzer anzeigen
oc describe rolebinding,clusterrolebinding --all-namespaces | \
grep -A 10 -B 5 "alice@company.com"

# Service Account Berechtigungen analysieren
oc get rolebinding,clusterrolebinding -o wide | \
grep "system:serviceaccount:monitoring:prometheus"

40.11 Best Practices für RBAC-Implementation

Prinzip der minimalen Berechtigungen: Gewähren Sie nur die minimal notwendigen Berechtigungen für die jeweilige Aufgabe. Beginnen Sie mit restriktiven Berechtigungen und erweitern Sie bei Bedarf.

Gruppenbasierte Zuweisungen: Verwenden Sie Gruppenmitgliedschaften anstelle direkter Benutzerzuweisungen für einfachere Verwaltung und Konsistenz.

Regelmäßige Audits: Führen Sie regelmäßige Reviews der Berechtigungen durch, um ungenutzte oder übermäßige Berechtigungen zu identifizieren.

Dokumentation: Dokumentieren Sie Custom Roles und ihre Anwendungsfälle für zukünftige Referenz und Compliance.

Namespace-Isolation: Nutzen Sie Namespaces konsequent für Mandanten-Isolation und begrenzen Sie Cross-Namespace-Berechtigungen auf das notwendige Minimum.

Service Account Management: Erstellen Sie spezifische Service Accounts für verschiedene Anwendungen anstatt den default Service Account zu verwenden.

Testing: Testen Sie RBAC-Konfigurationen in Entwicklungsumgebungen, bevor Sie sie in der Produktion implementieren.