• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Daniel Drack 01. April 2025

Einführung in Role Based Access Control (RBAC)

So funktioniert rollenbasierte Zugriffskontrolle

Role Based Access Control (RBAC) und Autorisierung

Was ist Role Based Access Control (RBAC)?

Role Based Access Control (RBAC), ist eine Autorisierungsmethode, bei welcher Identitäten Rollen zugewiesen werden. Basierend auf diesen Rollen wird entschieden, ob eine Identität eine Operation auf eine Ressource ausführen darf. Woher die Informationen über die Identität kommen, ist an dieser Stelle nicht relevant. Kubernetes bietet beispielsweise sieben Authentifizierungsmethoden an, welche im Endeffekt alle zu einer gleichwertigen User-Information (Identität) führen [7]. Neben RBAC gibt es auch noch andere Autorisierungsmethoden, wie beispielsweise ABAC (Attribute Based Access Control) und I (Policy Based Access Control), welche flexibler, aber auch komplexer sind als RBAC [8].

Wichtige Begriffe

Nun, da wir wissen, was Authentifizierung und Autorisierung sind, können wir näher auf die wichtigsten Begriffe im Bereich Autorisierung eingehen. 

• Ein User ist eine einzigartige Identität, die einer oder mehreren Personen zugeordnet ist. User haben bestimmte Attribute wie Name, E-Mail, User-ID oder Gruppen.
• Gruppen sind Sammlungen von Usern. User können Teil mehrerer Gruppen sein. Gruppen können (je nach System) hierarchisch angeordnet sein. Gruppen können auch Attribute an ihre User vererben.
• Ressourcen und Operationen wurden bereits behandelt. Die Kombination der beiden sind Berechtigungen (Permissions).
• Eine Berechtigung beschreibt "Operation auf Ressource".
• System ist ein Software-Produkt oder eine Lösung, das den Zugriff auf seine Ressourcen beschränken möchte.
• Eine Stage ist eine Instanz eines Systems, welche einem bestimmten Reifegrad im Entwicklungs- oder Betriebsprozess entspricht. Übliche Stages sind DEV (Entwicklung), TEST, UAT (User Acceptance Tests) und PROD.
• Rollen sind Sammlungen von Berechtigungen, die Gruppen (oder einzelnen Usern) zugewiesen werden können. Rollen geben einem User somit das Recht, gewisse Operationen auf Ressourcen anwenden zu dürfen.

Da wir jetzt die Grundbegriffe von RBAC kennen, stellen sich folgende zwei Fragen:

• Was fange ich damit an?
• Wie hilft mir das bei der Umsetzung einer sauberen Zugriffskontrolle?

Planung, Implementierung & Betrieb von Role Based Access Control (RBAC)

Die erste Frage klingt überspitzt, ist aber gerechtfertigt. Trockene Theorie wird in der Praxis gerne belächelt, ist aber in diesem Fall nötig. Nur wer die Bausteine und Grundbegriffe von Authentifizierung und Autorisierung verstanden hat, kann dieses Wissen nutzbar machen. Denn der erste Schritt jeder gelungenen Umsetzung ist die Planung. Im Fall von RBAC nennt man diesen Plan ein Berechtigungskonzept.

Planung

Das Berechtigungskonzept ist (anfangs) ein Prosa-Dokument, welches folgende Informationen beinhalten muss:

• Art und Herkunft von Usern/Gruppen
• das betrachtete System sowie dessen Stages
• die relevanten Ressourcen
• die möglichen Operationen
• definierte Berechtigungen und Rollen
• Verknüpfung von Rollen, Usern/Gruppen und System/Stages.

Üblicherweise gibt es ein Berechtigungskonzept pro System, nicht zwangsläufig pro Typ. Zum Beispiel kann es unterschiedliche Konzepte für Oracle-Datenbanken pro Abteilung geben. Oder ein Konzept für GitLab-Umgebungen pro Business Unit.

Info: Es hat sich als praktikabel herausgestellt, zumindest ein Konzept pro Software zu erarbeiten. Beispielsweise ist es ungünstig, die Zugriffsregelung auf Kubernetes Cluster und Datenbanken im selben Konzept zu betrachten. Zu viele verschiedene Ressourcen, Operationen und beteiligte Gruppen machen alles unnötig kompliziert.

Die Informationen über System/Stage sowie Ressourcen und Operationen sind schon am Anfang der Konzepterstellung vorhanden. Das System und dessen Stages müssen schon weit vorher definiert sein, bevor überhaupt implementiert wird... Schließlich muss man wissen, was gebaut werden soll. Ressourcen und Operationen bringt die Software vordefiniert mit, egal ob 3rd-Party oder Eigenentwicklung. Die Hauptaufgabe bei der Erarbeitung des Berechtigungskonzepts liegt darin, sinnvolle Rollen zu definieren. Diese Rollen müssen anschließend den richtigen Gruppen auf den passenden Stages eines Systems zugewiesen werden.

Rollen definieren

Hier schließt sich auch der Kreis zum "iterativen" Ansatz. Bei diesem ist es nämlich wahrscheinlich, dass sich das Ergebnis je nach Anzahl der Anpassungszyklen, beteiligten Personen und Anforderungen drastisch unterscheidet. Es lässt jedoch schon vermuten, dass der "deterministische" Ansatz wesentlich aufwändiger, komplexer und umständlicher ist. Es gilt also, die Balance zwischen Transparenz und Pragmatismus zu finden. 

In der Praxis sehen wir oft eine Vermischung, in der zwar auf Szenarien/Tasks gesetzt wird, von dort aber pragmatisch gleich auf die Rollendefinition gewechselt wird (kein Ableiten von Rollen aus Arbeitsprofilen, kein Algorithmus).

Lessons Learned

Gehen wir an dieser Stelle kurz auf Stolpersteine ein, die man in der Praxis häufig sieht, aber leicht vermeiden kann. 

Benennung von Gruppen und Rollen:

• Gruppen:
  • Gruppen leiten sich aus organisatorischen Teams ab und sollten daher auch an das Tätigkeitsfeld gebunden sein.
  • Gruppen bilden Sammlungen von Personen ab – grundsätzlich unabhängig vom System.
  • gut: Entwickler_Projekt_A, ChapterXMember, OnCallTeam,..
  • schlecht: Confluence Admins, GitLab Contributors,..
• Rollen:
  • Rollen leiten sich aus systemspezifischen Arbeitsprofilen ab, d. h. Rollen haben eine Einschränkung auf das System.
  • gut: (GitLab) Project Maintainer, (Confluence) Space Member,..
  • schlecht: Global_Admin, Storage_Team,..
• Mapping von Gruppen - Rollen - Stages

Verknüpfung von Gruppen - Rollen - Stages:

• Einer Gruppe wird eine Rolle pro Stage zugewiesen.
  Die Rollen sind auf jeder Stage dieselben (=global).
  • d. h. es gibt keine Stage-spezifischen Rollen!
  • z. B.: Es gibt nur die Rolle Cluster Admin. Kein Dev Cluster Admin oder Prod Cluster Admin.

Beispiel: Die Gruppe Projekt_X_Entwickler bekommt auf

• DEV Cluster die Rolle Cluster Admin
• TEST Cluster die Rolle Cluster Member
• PROD Cluster die Rolle Cluster Read-Only

Somit hat man sauber definierte Gruppen, angelehnt an Organisationseinheiten (sprich Personen, die dasselbe tun). Die definierten Rollen sehen auf jeder Stage gleich aus (sprich haben die gleichen Berechtigungen). Lediglich die Zuweisung von Rolle pro Stage unterscheidet sich.

Info: Die Organisationseinheit, nach der eine Gruppe definiert wird, muss nicht zwangsläufig einem Team im Organigramm entsprechen. Es könnten z. B. auch die jeweiligen Security Champions der verschiedenen Entwicklerteams eine Gruppe bilden (Chapters/Clans oder Matrix-/Projekt-Organisation).

Zusammenfassung

An dieser Stelle haben wir nun die Umsetzung unserer Zugriffskontrolle fertig geplant. Das Ergebnis der Planung ist ein Berechtigungs-(bzw. RBAC-)Konzept, welches folgende Dinge in Prosa (Word, Confluence,..) beschreibt:

• das betrachtete System
  • Stages des Systems
  • Ressourcen, Operationen und Berechtigungen des Systems
• Ursprung und Art der Identitätsinformation
  • Gruppen, Zusatzattribute,..
  • Identity Provider und Authentifizierungsmethode
• betroffene User/Gruppen
• definierte Rollen
  • Ggf.: Wie wurden die Rollen definiert (iterativ/deterministisch).
• Verknüpfung von Gruppen - Rollen - Stage.

Anmerkung: Prosadokumente sind ein guter Anfang, warten und verwenden sich technisch jedoch eher schlecht. Aus diesem Grund würde es sich anbieten, an dieser Stelle auf einen "As-code"-Ansatz zu wechseln.

Implementierung von RBAC

Um die Verwaltung von Rollen, Gruppen und deren Verknüpfung technisch umzusetzen, gibt es zwei Arten:

• manuell über UI (oder API)
• automatisiert und as code – RBAC done Right

Info: Alle Systeme setzen Autorisierung unterschiedlich um bzw. bieten andere Möglichkeiten (RBAC, ABAC,..). Es gibt noch keinen RBAC Standard (wie SAML/OIDC für AuthN), daher müssen Rollen/Gruppen und deren Verknüpfung immer pro System betrachtet und umgesetzt werden. 

Wie das manuelle Verwalten von Rollen sowie das anschließende Zuweisen dieser in einem bestimmten System funktioniert, ist der jeweiligen Dokumentation zu entnehmen. Auf diesen Punkt wird hier nicht mehr eingegangen – moderne und cloud-native Systeme werden als Code konfiguriert (auch RBAC).

Um Rollen und deren Mappings automatisiert in einem System verwalten zu können, muss das System dies technisch ermöglichen. Die meiste moderne Software bietet heute APIs an, welche von weiteren Tools verwendet werden können. Speziell Infrastructure-as-Code- oder Configuration-as-Code-Tools bieten sich für diese Tasks an. Konkret sprechen wir hier von Werkzeugen wie Terraform, Pulumi, Ansible, Puppet etc. Alle diese Tools erlauben es, einen "desired state" als Code zu beschreiben und können diesen anschließend am Zielsystem konfigurieren.

Beispiel:

• Wir haben drei Gruppen von Usern:
  • Projekt_x_Entwickler
  • Platform_Team
  • Projekt_x_Management
• Wir haben drei Systeme mit jeweils drei Stages (DEV, TEST, PROD):
  • Kubernetes – die Container-Plattform
  • GitLab – das Source-Code-Management-System
  • JFrog Artifactory – die Artifact Registry

Es gibt für jedes der drei Systeme ein eigenes Berechtigungskonzept mit definierten Rollen. Diese Rollen lauten (sehr vereinfacht!)

• Kubernetes
  • Read-Only –- darf (fast) alles sehen
  • Namespace-User – darf alles in einem bestimmten Namespace
  • Cluster-Admin – darf alles im System
• GitLab
  • Reporter – darf alles im Projekt lesen
  • Maintainer – darf im Projekt CRUD
  • Administrator – darf alles im System
• Artifactory
  • Project-Pull – darf Objekte aus einem Projekt herunterladen
  • Project-Owner – darf CRUD in einem Projekt
  • Artifactory-Admin – darf alles im System.

In den Berechtigungskonzepten wurden folgende Gruppen-Rollen-Zuweisungen festgelegt:

Kubernetes	DEV	TEST	PROD
Projekt_x_Entwickler	Namespace-User	Namespace-User	Read-Only
Platform_Team	Cluster-Admin	Cluster-Admin	Namespace-User
Projekt_x_Management	Read-Only	Read-Only	Read-Only

GitLab	DEV	TEST	PROD
Projekt_x_Entwickler		Administrator	Maintainer
Platform_Team	Administrator	Administrator	Administrator
Projekt_x_Management			Reporter

Artifactory	DEV	TEST	PROD
Projekt_x_Entwickler		Project Owner	Project-Pull
Platform_Team	Artifactory-Admin	Artifactory-Admin	Artifactory-Admin
Projekt_x_Management			Project-Pull

Nun stellt sich die Frage, wie diese Rollen und Mappings in den drei unterschiedlichen Systemen implementiert werden können – "code to the rescue"! Mit Tools wie Terraform kann die Implementierung von (unter anderem!) RBAC in einer "Sprache" passieren – in diesem Fall HCL. Starten wir mit der Definition der Rollen. In Kubernetes wird üblicherweise mit YAML-Manifests gearbeitet (welche als JSON an die Kubernetes-API gesendet werden). Die Definition einer Rolle würde "nativ" so aussehen:

apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRole 
metadata:  
  name: cluster-read-pod-svc
rules:  
  - apiGroups: [""]  
    resources: ["pods", "services"] # <- Ressourcen
    verbs: ["get", "list", "watch"] # <- Operationen

Diese Rolle erlaubt lesende Operationen auf Ressourcen von Typ Pod und Service. Die Rolle kann mit folgender Konfiguration einer Gruppe (in einem Namespace) zugewiesen werden:

apiVersion: rbac.authorization.k8s.io/v1  
kind: RoleBinding  
metadata:  
  name: demo-role-binding  
  namespace: default  
subjects:  
  - kind: Group  
    name: "demo-group"  
    apiGroup: rbac.authorization.k8s.io  
roleRef:  
  kind: Role  
  name: cluster-read-pod-svc
  apiGroup: rbac.authorization.k8s.io

Diese Code-Beispiele implementieren schon sehr gut das "As-code"-Paradigma, sind jedoch spezifisch für Kubernetes. Übersetzt man diese Konfiguration nach Terraform, sieht das folgendermaßen aus:

# add provider config here
resource "kubernetes_cluster_role" "cluster_read_pod_svc" {  
  metadata {  
    name      = "cluster-read-pod-svc"
  }  
  
  rule {  
    api_groups = [""]  
    resources  = ["pods", "services"]  
    verbs      = ["get", "list", "watch"]  
  }  
}  
  
resource "kubernetes_role_binding" "demo_role_binding" {  
  metadata {  
    name      = "demo-role-binding"  
    namespace = "default"  
  }  
  
  subject {  
    kind      = "Group"  
    name      = "demo-group"  
    api_group = "rbac.authorization.k8s.io"  
  }  
  
  role_ref {  
    kind      = "Role"  
    name      = kubernetes_role.demo_role.metadata[0].name  
    api_group = "rbac.authorization.k8s.io"  
  }  
}

Die beiden Notationen führen im Endeffekt zum selben Ergebnis (im Kubernetes-Cluster), jedoch bietet Terraform einen entscheidenden Vorteil: Mit Terraform können auch Artifactory, GitLab und über 3.000 andere Systeme konfiguriert werden [10]. Die Rollen von GitLab sind bereits vom System vorgegeben, Custom-Rollen werden nur mit der höchsten (teuersten) Lizenz verfügbar. In unserem Beispiel sind jedoch keine Custom-Rollen nötig. Für Artifactory würde die Definition der Rollen in Terraform folgendermaßen aussehen:

resource "platform_permission" "project_owner" {  
  name = "Project-Owner-Projekt_x_Entwickler"
  
  artifact = {  
    actions = {  
      groups = [  
        {  
          name = "Projekt_x_Entwickler"  
          permissions = ["READ", "WRITE", "SCAN", "DELETE", "ANNOTATE"]  
        }  
      ]  
    }  
  
    targets = [  
      {  
        name = "ALL-LOCAL"  
        include_patterns = ["**"]  
      }
    ]  
  }
}

Dieses Beispiel veranschaulicht, wie unterschiedlich die Implementierung pro System ausfällt. Artifactory beschreibt beispielsweise die Berechtigungen gemeinsam mit dem User/Gruppen-Mapping in einer Konfiguration. Die hier beschriebenen Code-Fragmente würden in der Praxis natürlich umfangreicher sein. Folgende Best Practices kann ich an dieser Stelle mitgeben:

• ein Repo/eine Config für alle Rollen eines Systems
  • Die gleiche Config wird auf alle Stages angewendet.
  • Gleiche Rollen auf allen Stages!
• ein Repo/eine Config pro Stage für die Gruppen-Rollen-Mappings
  • erlaubt leichtere Zugriffskontrolle auf den Code einer Stage
  • Mappings in leicht lesbarem Format abbilden: CSV, YAML,..

Info: Was die Implementierung betrifft, ist also abschließend festzuhalten, dass es sehr von Vorteil ist, diese zu automatisieren. Tools, welche mit mehreren Zielsystemen umgehen können (wie z. B. Terraform et al), bieten sich hierfür an (Stichwort: Infrastructure as Code / Configuration as Code). Der "As-code"-Ansatz hat jedoch noch andere Vorteile, welche im laufenden Betrieb klar werden.

Betrieb

Mit Betrieb ist die laufende Pflege und Verwaltung der Rollen, Gruppen und deren Verknüpfung gemeint (hier eingeschränkt auf den Fall von RBAC). Speziell bei regulierten und/oder sehr großen Unternehmen ergeben sich hier einige Herausforderungen:

• Es muss jederzeit ersichtlich sein, welche Zugriffsrechte am System konfiguriert sind.
• Es muss nachvollziehbar sein, warum/wie/wann eine Person bestimmte Rechte erhalten hat.
• Es gilt, gewisse Richtlinien (interne oder externe) einzuhalten.
• Es müssen Prozesse zur Erteilung/Entfernung von Permissions eingehalten werden (approvals etc).
• Es sollte sichergestellt werden, dass die erteilten Berechtigungen keine ungewollten Nebeneffekte haben (Stichwort: Privilege Escalation).

Bei all diesen Anforderungen kann der "As-code"-Ansatz seine Stärken noch weiter ausspielen.

• Durch die Abbildung der Konfiguration als Code ist jederzeit ersichtlich, welche Berechtigungen an wen vergeben sind (Sofern sichergestellt ist, dass nichts manuell geändert wird.)
• Wie für jede andere Art von Code, können auch hier Pull Requests mit Approval-Regeln etc. verwendet werden. Außerdem ist jede Änderung für Mensch und Maschine leicht nachvollziehbar.
• Die (Git) History im Code Repo, in welchem der Code abgelegt ist, ist ein transparentes Log aller Änderungen.
• Richtlinien können als technische Policies formuliert und der Code gegen diese Policies getestet werden.
• Der Code kann programmatisch ausgewertet und validiert werden. Dadurch können z. B. Privilege-Escalation-Schwachstellen oder andere logische Fehler entdeckt werden.

Info: Ein weiterer angenehmer Nebeneffekt von Code ist, dass daraus sehr einfach und jederzeit aktuell Dokumentation generiert werden kann. Doku wird also nicht mehr im Zuge eines Change-Request-Feldes oder gar erst (hoffentlich) im Nachhinein geschrieben, sondern aus der Live-Konfiguration erstellt.

Zusammenfassung

Die Kontrolle von Zugriffen auf Ressourcen ist ein sehr altes Problem der IT, für das es keine "One-size-fits-all"-Lösung gibt. RBAC hat sich in den vergangenen Jahren jedoch als praktikable Methode herausgestellt. Zwar ist RBAC nicht so mächtig und flexibel wie andere Methoden, jedoch leicht zu verstehen und von vielen Systemen implementiert. Die Erarbeitung von Rollen sowie die anschließende und laufende Konfiguration der betroffenen Systeme sind die derzeitigen Hauptprobleme in diesem Bereich. Spätestens seit der Cloud-Ära, in der nahezu jedes System über eine API verfügt, hat sich zumindest für die Implementierung von RBAC ein Best Practice herauskristallisiert. Configuration as Code mit Tools wie Terraform et al. bringt enorme Vorteile und ist der aktuell beste Weg, um Systeme zu verwalten. RBAC done Right – sauber abgeleitete Rollen, implementiert "as code".

Autor