Cloudera Identity: Von LDAP über Kerberos zu Ranger

zte Glied einer Kette, die im Corporate Identity Provider beginnt, über LDAP- oder AD-Gruppen läuft, in Kerberos-Principals übersetzt wird, durch Knox oder direkte Client-Verbindungen an den Cluster kommt und erst dort auf eine Autorisierungsentscheidung trifft. Jedes Glied die.

Lösung: Behandle Identität in CDP als eine durchgehende, dokumentierte Kette und nicht als Konfiguration in vier getrennten Systemen.

In einem Satz: Behandle Identität in CDP als eine durchgehende, dokumentierte Kette und nicht als Konfiguration in vier getrennten Systemen.

Problem

In CDP-Umgebungen wird „Zugriff“ meist an der Stelle diskutiert, an der er sichtbar ist: in der Ranger-Policy. Die Policy ist aber nur das letzte Glied einer Kette, die im Corporate Identity Provider beginnt, über LDAP- oder AD-Gruppen läuft, in Kerberos-Principals übersetzt wird, durch Knox oder direkte Client-Verbindungen an den Cluster kommt und erst dort auf eine Autorisierungsentscheidung trifft. Jedes Glied dieser Kette kann eigenständig driften, und jedes Glied wird von einem anderen Team betrieben.

Die typische Folge ist ein Modell, das auf dem Papier sauber wirkt und im Betrieb nicht hält. Eine Gruppe heißt dl-finance-analysts, aber der Ranger-Usersync liefert sie mit anderem Namensraum. Ein Service Account ist als Principal vorhanden, gehört aber niemandem. Ein Analyst verliert seine Gruppenmitgliedschaft, behält jedoch Zugriff, weil daneben ein direkter Grant, ein Hive-Verantwortung-Recht oder eine lokale Ranger-Rolle existiert. Der Zugriff endet nicht dort, wo die Gruppenmitgliedschaft endet.

Der zweite Problemkern ist die Vermischung von menschlichen und technischen Identitäten. Ein Mensch hat einen Vorgesetzten, einen Austrittsprozess und eine Rezertifizierung. Ein Service Account hat davon nichts, es sei denn, jemand baut es explizit. Genau diese Accounts halten aber in der Praxis die weitreichendsten Rechte: Ingest schreibt in alle Landing-Zonen, ein Spark-Job liest domänenübergreifend, ein Reporting-Connector besitzt breite Leserechte über Hive.

Entscheidung

Behandle Identität in CDP als eine durchgehende, dokumentierte Kette und nicht als Konfiguration in vier getrennten Systemen. Die Kette lautet: Corporate IdP → LDAP/AD-Gruppe → Kerberos-Principal beziehungsweise Knox-Authentifizierung → Ranger-Identität (User, Gruppe, Rolle) → wirksames Privileg auf einer Ressource. Für jedes Glied wird festgehalten, wer es pflegt, woher die Wahrheit kommt und wie ein Widerspruch aufgelöst wird.

Trenne menschliche und technische Identitäten strikt, mit unterschiedlichen Namenskonventionen, unterschiedlichen Lebenszyklen und unterschiedlichen Nachweisen. Menschliche Zugriffe werden über Gruppen und Rollen vergeben, nie direkt an den einzelnen Benutzer. Technische Zugriffe werden an benannte Service-Principals vergeben, die einen aktiven Owner, einen Zweck und ein Rotationsverfahren besitzen.

Der Pilot umfasst eine Domäne, drei bis fünf reale Rollen und alle Service Accounts, die auf dem Pfad dieser Domäne laufen. Erfolgreich ist er, wenn ein Zugangsentzug im IdP innerhalb einer definierten Frist nachweislich am Cluster wirkt und wenn kein Bypass-Pfad ohne Owner und Protokollierung existiert.

Scope und Abgrenzung

Scope-in sind: der produktive Realm und mindestens eine nichtproduktive Umgebung, die Gruppen der Pilotdomäne, alle Service-Principals auf dem Ingest-, Verarbeitungs- und Consumer-Pfad, die Knox-Topologien, über die externe Clients zugreifen, sowie sämtliche privilegierten Konten und Break-Glass-Wege. Letztere sind ausdrücklich Teil des Scopes, weil sie reguläre Controls aushebeln können.

Scope-out sind benachbarte Domänen, historische Cluster ohne Migrationsentscheidung und Anwendungen, die nicht über CDP-Identitäten authentifizieren. Sie werden nicht ignoriert, sondern als bekannte Abhängigkeit registriert. Wer sie später einbezieht, benötigt einen erneuten Grenze-Check und einen Owner.

Nicht Teil dieses Playbooks ist die feingranulare Policy-Modellierung selbst; sie gehört in den Ranger-Teil der Serie. Hier geht es ausschließlich um die Frage, ob die Identität, auf die eine Policy verweist, die richtige, aktuelle und vollständige ist.

Rollen und Entscheidungsrechte

• Zugriffsverwaltung- oder Directory-Team: ist autoritativ für Existenz, Attribute und Mitgliedschaft von Corporate-Identitäten und Gruppen.
• Plattform-technischer Betreiber (CDP/Ranger): übersetzt Corporate-Gruppen in Ranger-Rollen und betreibt Usersync, Kerberos-Anbindung und Knox.
• Data Owner: entscheidet, welche fachliche Rolle welchen Zweck verfolgen darf; er entscheidet nicht über die technische Umsetzung.
• Service Account verantwortliche Person: ist eine benannte Person oder ein benanntes Team, verantwortlich für Zweck, Rechteumfang, Rotation und Stilllegung.
• Security: definiert Anforderungen an Authentifizierung, Bypass-Protokollierung, Rezertifizierungsfrist und Ausnahmeprozess.
• Auditor oder unabhängige Prüfung: bewertet, ob die Kette nachvollziehbar und die Evidenz reproduzierbar ist.

Pro Entscheidung existiert genau ein Accountable. Die häufigste Störung entsteht dort, wo das Directory-Team eine Gruppe für „nur ein Namensobjekt“ hält, während sie auf der Plattform faktisch die Rolle definiert. Diese Doppeldeutung wird schriftlich aufgelöst, bevor Policies gebaut werden.

Von der Corporate-Gruppe zur Ranger-Rolle

Namensraum und Synchronisation festlegen

Der erste konkrete Schritt ist die Klärung, welche Objekte Ranger tatsächlich sieht. Der Usersync liefert Benutzer und Gruppen aus LDAP oder AD; die dabei verwendeten Filter, Basis-DNs und Attributzuordnungen entscheiden über den späteren Policy-Ausdruck. Dokumentiere pro Umgebung, welcher Attributwert zur Ranger-Identität wird, welche Gruppen ausgeschlossen sind und in welchem Intervall synchronisiert wird.

Ein Synchronisationsintervall ist eine Governance-Aussage, keine technische Nebensache. Es bestimmt die maximale Latenz zwischen einem Entzug im IdP und der Wirkung am Cluster. Diese Latenz wird als Zielwert benannt und gemessen, nicht geschätzt.

Gruppen auf fachliche Rollen abbilden

Eine Corporate-Gruppe ist eine Organisationsaussage, eine Ranger-Rolle eine Berechtigungsaussage. Beide sind selten deckungsgleich. Baue deshalb eine explizite Zuordnungstabelle: fachliche Rolle, zugehörige Gruppen, erlaubter Zweck, betroffene Ressourcenklassen, Accountable, Review-Datum. Die Tabelle wird versioniert und ist die einzige zulässige Quelle für neue Policy-Zuweisungen.

Vermeide Rollen, die aus Organisationseinheiten abgeleitet sind, ohne dass ein Zweck benannt ist. „Abteilung Controlling“ ist keine Rolle. „Controlling-Analyse auf pseudonymisierten Transaktionsdaten“ ist eine Rolle, weil sie einen prüfbaren Zweck und damit eine Grenze besitzt.

Direkte Benutzer-Grants ausschließen

Direkte Zuweisungen an einzelne Benutzer sind der zuverlässigste Weg, eine Rezertifizierung zu unterlaufen. Sie werden als Ausnahme behandelt: befristet, begründet, mit kompensierendem Control und mit automatischer Wiedervorlage. Ein regelmäßiger Report listet alle Policies mit Benutzerbezug; ein Wachstum dieser Zahl ist ein Governance-Signal, kein Betriebsdetail.

Kerberos, Service Accounts und Keytabs

Kerberos beantwortet die Frage der Authentizität, nicht die der Autorisierung. Ein gültiges Ticket beweist, dass ein Principal sich ausweisen konnte — nicht, dass der dahinterliegende Mensch oder Job den Zugriff haben darf. Deshalb wird jeder produktiv genutzte Principal registriert: Name, Typ (human, service, system), Owner, Zweck, betroffene Dienste, Keytab-Speicherort, Rotationsintervall, Stilllegungsbedingung.

Keytabs sind Zugangsdaten mit langer Lebensdauer. Sie liegen häufig auf Edge Nodes, in Scheduler-Konfigurationen oder in Container-Images. Wer eine Keytab lesen kann, kann die Identität annehmen. Der Schutz der Keytab-Datei ist damit Teil des Zugriffsmodells und nicht nur eine Betriebsaufgabe. Halte fest, wer auf dem Host lesen darf und wie ein Kompromittierungsfall behandelt wird.

Für Service Accounts gilt eine zusätzliche Regel: kein geteilter Account über Domänengrenzen hinweg. Ein Ingest-Account, der in drei Domänen schreibt, macht jede spätere Zuordnung eines Schreibvorgangs unmöglich. Die Trennung kostet einmalig Aufwand und spart bei jedem Incident die aufwendige Rekonstruktion.

Die Stilllegung ist der am häufigsten fehlende Teil. Für jeden Service Account wird beim Anlegen definiert, woran erkennbar ist, dass er nicht mehr benötigt wird, und wer ihn dann entfernt. Ohne diese Festlegung entsteht ein wachsender Bestand aktiver Identitäten ohne Zweck.

Knox als Perimeter und die Frage der Umgehung

Knox bündelt externe Zugriffe, terminiert Authentifizierung und leitet an die Dienste weiter. Governance-relevant ist weniger die Existenz des Gateways als die Frage, welche Wege daran vorbeiführen. Typische Umgehungen sind direkte JDBC- oder Thrift-Verbindungen aus dem internen Netz, Zugriffe von Edge Nodes mit lokal vorhandenen Keytabs, Admin-Konsolen und Wartungszugänge.

Erstelle eine vollständige Liste der Zugriffspfade auf die Pilotdomäne, jeweils mit Authentifizierungsmechanismus, Autorisierungspunkt und Protokollierung. Ein Pfad ohne Autorisierungspunkt ist ein Findings-Kandidat, kein akzeptierter Sonderfall. Ein Pfad ohne Protokollierung ist im Auditfall nicht verteidigbar, unabhängig davon, wie eng er technisch begrenzt ist.

Für Break-Glass-Zugänge gilt: erlaubt, aber protokolliert, befristet, nach Nutzung reviewt. Die Nutzung eines Notfallkontos erzeugt ein Ereignis, das jemand aktiv bewerten muss. Ein Notfallkonto, dessen Nutzung nie geprüft wird, ist faktisch ein dauerhafter privilegierter Zugang.

Rezertifizierung und Nachweis der Wirksamkeit

Rezertifizierung prüft nicht Gruppenmitgliedschaften, sondern wirksame Zugriffe. Die zentrale Frage lautet nicht „ist die Person noch in der Gruppe?“, sondern „darf diese Rolle diesen Zweck auf diesen Daten weiterhin verfolgen, und stimmt der wirksame Zugriff mit der Rolle überein?“. Beide Teile werden getrennt beantwortet und getrennt dokumentiert.

Mindestens vier Testarten werden pro Zyklus protokolliert: ein erlaubter Standardzugriff, ein bewusst verweigerter Zugriff, ein Zugriff über einen Service-Principal und ein privilegierter Zugriff über einen Bypass-Pfad. Jeder Test nennt Identität, Zeitpunkt, Ressource, erwartetes Ergebnis, tatsächliches Ergebnis und die zum Testzeitpunkt wirksame Policy-Version.

Ein Entzugstest gehört ebenfalls in den Zyklus: Eine Testidentität wird im IdP aus der Gruppe entfernt, und es wird gemessen, nach welcher Zeit der Zugriff am Cluster tatsächlich endet. Dieses Ergebnis ist der belastbarste Beweis dafür, dass die Kette funktioniert — und in vielen Umgebungen der erste Punkt, an dem eine unbekannte Latenz oder ein zwischengelagerter Cache sichtbar wird.

Häufige Anti-Patterns

Die Gruppe ist der Beweis

Eine Mitgliedschaftsliste zeigt Absicht, nicht Wirkung. Ohne einen Effective-Access-Test bleibt offen, ob daneben ein zweiter Pfad existiert.

Ein Service Account für alles

Geteilte technische Identitäten sind bequem und machen Verursacherzuordnung unmöglich. Der Preis fällt erst im Incident an, dafür vollständig.

Kerberos gilt als Autorisierung

Ein Ticket beweist Authentizität. Die Erlaubnis kommt aus Ranger, aus Zugriffsregels oder aus Verantwortung — und diese Quellen widersprechen sich gelegentlich.

Knox wird als geschlossener Perimeter angenommen

Solange interne Direktverbindungen möglich sind, ist das Gateway ein bequemer Pfad, aber keine Grenze.

Rezertifizierung ohne Zweckprüfung

Wer nur Mitgliedschaften bestätigt, verlängert bestehende Rechte routinemäßig, statt sie zu prüfen.

Keytabs außerhalb des Zugriffsmodells

Wer die Datei lesen kann, ist der Account. Dateiberechtigungen gehören damit in dieselbe Betrachtung wie Policies.

Umsetzung in 90 Tagen

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Cloudera CDP Governance
• Lernpfad — Cloudera CDP Governance

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Kette aufnehmen

Alle Glieder von IdP bis wirksamem Privileg dokumentieren. Zugriffspfade auflisten, Service-Principals inventarisieren, Owner benennen. Drei konkrete Risiken priorisieren.

Schritt 2: Rollenmodell und Zuordnung entscheiden

Fachliche Rollen definieren, Gruppen zuordnen, Namenskonventionen für menschliche und technische Identitäten festlegen, Ausnahmen für bestehende Direkt-Grants erfassen.

Schritt: Umsetzen und testen

Usersync und Rollenmapping produktiv stellen, Direkt-Grants abbauen, Keytab-Schutz prüfen, die vier Testarten durchführen und protokollieren.

Schritt: Entzug und Notfall simulieren

Entzugstest mit gemessener Latenz durchführen, einen Break-Glass-Zugriff auslösen und den Review-Weg vollständig gehen.

Schritt 4: Rezertifizierung und Skalierung

Ersten vollständigen Zyklus abschließen, Aufwand messen, Automatisierungslücken benennen und erst danach über die Ausweitung auf weitere Domänen entscheiden.

Messung

• Anteil der Zugriffe, die über Rollen statt über Direkt-Grants vergeben sind
• Gemessene Latenz zwischen Entzug im IdP und Wirkung am Cluster
• Anteil der Service-Principals mit aktivem verantwortliche Person, Zweck und Rotationsnachweis
• Anzahl bekannter Zugriffspfade ohne Autorisierungspunkt oder ohne Protokollierung
• Anteil der Break-Glass-Nutzungen mit dokumentiertem Nachreview
• Alter und Anzahl offener Ausnahmen im Identitätsbereich
• Zeitaufwand für einen vollständigen Rezertifizierungszyklus je Domäne

Checkliste

• Die Kette von IdP bis wirksamem Privileg ist je Umgebung dokumentiert.
• Für jedes Glied ist eine autoritative Quelle und ein Accountable benannt.
• Menschliche und technische Identitäten sind getrennt benannt und getrennt geführt.
• Jeder produktive Service-Principal hat verantwortliche Person, Zweck, Rotation und Stilllegungsbedingung.
• Keytab-Speicherorte und Leseberechtigungen sind Teil des Zugriffsmodells.
• Fachliche Rollen sind über Zweck definiert, nicht über Organisationseinheiten.
• Direkte Benutzer-Grants sind erfasst, befristet und rückläufig.
• Alle Zugriffspfade inklusive Knox-Umgehungen sind gelistet und bewertet.
• Break-Glass-Zugänge sind protokolliert, befristet und werden nachgeprüft.
• Erlaubter, verweigerter, Service- und Bypass-Zugriff wurden real getestet.
• Die Entzugslatenz wurde gemessen und gegen einen Zielwert bewertet.
• Rezertifizierung prüft Zweck und wirksamen Zugriff, nicht nur Mitgliedschaft.
• Evidenz nennt Identität, Zeitpunkt, Ressource, Ergebnis und Richtlinie-Version.
• Die Ausweitung auf weitere Domänen erfolgt erst nach bestandenem Entzugstest.

Artefakt

Das Ergebnis ist eine Identity Chain Card für die Pilotdomäne. Sie beschreibt in einer Tabelle jedes Glied der Kette mit autoritativer Quelle, betreibendem Team, Synchronisationsverhalten, bekannter Latenz und Konfliktauflösung. Ergänzt wird sie durch ein Service-Account-Register mit Owner, Zweck, Rechteumfang, Rotationsstand und Stilllegungsbedingung.

Der dritte Bestandteil ist ein Testprotokoll mit den vier Zugriffsarten und dem Entzugstest. Es ist die eigentliche Evidenz: Es zeigt nicht, was konfiguriert wurde, sondern was tatsächlich passiert ist. Jede Änderung an Rollenmodell, Usersync-Konfiguration oder Zugriffspfaden erzeugt eine neue Version der Karte und löst gezielte Retests aus.

Tools und Verweise

• Ranger Richtlinie Pattern Generator
• Authority Matrix
• Custom Stack Builder
• Cloudera CDP Ranger Start
• Kafka Schema Registry Start
• Governance über mehrere Plattformen
• Lernpfad Cloudera CDP Governance
• Glossary: Kerberos, Apache Ranger, Apache Knox, Cloudera CDP