Das Server-Plug-in grantforge-plugin-zookeeper definiert den Diensttyp zookeeper, seine Ressourcen und die Verbindungskonfiguration. Zum Durchsetzen der Richtlinien gehört ein zweiter Teil, der innerhalb von ZooKeeper läuft: der Agent, der als SASL-Authentifizierungsprovider an den ACL-Entscheidungen der Server mitwirkt. Er liegt in agents/grantforge-agent-zookeeper; der Befehl mvn -pl agents/grantforge-agent-zookeeper -am package erzeugt eine einzelne Java-8-kompatible Shaded-JAR mit ihren Abhängigkeiten, die in der Distribution unter agents/zookeeper/grantforge-agent-zookeeper-<version>.jar ausgeliefert wird. Die Implementierung ist auf die APIs von ZooKeeper 3.6–3.9 ausgelegt; die Kompatibilität mit den einzelnen Versionen muss noch praktisch validiert werden. Weder die vollständige Versionsmatrix noch eine Produktionsabnahme gelten damit als abgeschlossen.
Bereitstellung
-
Installiere die JAR im Verzeichnis
libjedes ZooKeeper-Servers, einschließlich aller Knoten, die Client-Anfragen annehmen können. Erstelle Agent-Zugangsdaten im zugehörigen GrantForge-Datendienst vom Typzookeeper. Speichere das Token in einer separaten Datei, die nur das ZooKeeper-Betriebskonto lesen darf; schreibe das Token selbst nicht inzoo.cfg. -
Ergänze auf jedem Server die folgenden Einstellungen in
zoo.cfgund ersetze Beispieladresse, Pfade und Instanzkennung.grantforge.server.url(http[s]://GrantForge),grantforge.token.file, ein lokalesgrantforge.cache.dirundgrantforge.instancesind Pflichtangaben. Das Cache-Verzeichnis muss für das ZooKeeper-Betriebskonto beschreibbar sein.authProvider.1=org.devlive.grantforge.zookeeper.agent.GrantForgeSaslAuthenticationProvider enableEagerACLCheck=false grantforge.server.url=https://GrantForge grantforge.token.file=/etc/zookeeper/grantforge.token grantforge.cache.dir=/var/lib/zookeeper/grantforge-cache grantforge.instance=zk-1 grantforge.principal.mapping=short -
Dieser Provider ersetzt den nativen SASL-Provider. In keinem anderen Eintrag
authProvider.Ndarf ein weiterer Provider für dasselbe Schemesaslregistriert bleiben.enableEagerACLCheck=falseist zwingend: Bei aktivierter Prüfung wird die Provider-Registrierung abgelehnt und der Marker lässt keinen Zugriff zu. Behalte die normale ZooKeeper-Authentifizierung mit SASL, JAAS und Kerberos bei und prüfe ihre Funktion; der Agent ersetzt keine Authentifizierung. Starte die Server nach dem Wartungsverfahren des Ensembles neu. -
Optional verweist
grantforge.signing.key.fileauf eine Datei mit dem fest hinterlegten öffentlichen Signaturschlüssel.grantforge.principal.mapping=shortist der Standard und bildetkafka/host@REALMaufkafkaab;fullbehält den vollständigen Principal. Benutzer in Richtlinien müssen den abgebildeten Identitäten entsprechen.
ACLs und Einschränkungen
- Nur die Marker-ACL
sasl:grantforgewird von GrantForge-Richtlinien entschieden, etwasasl:grantforge:cdrwamitc=create,d=delete,r=read,w=writeunda=admin. Andere native ACLs, einschließlich anderer SASL-Identitäten, funktionieren unverändert. - Läuft der Agent nicht, fehlt ein nutzbarer Richtlinien-Snapshot, ist dessen
serviceTypenichtzookeeperoder passt/erlaubt keine Richtlinie den Zugriff, lehnt der Marker ab. Das ist kein globales Deny: Andere ACLs,world:anyoneoder einesuper-Identität können die Anfrage weiterhin zulassen. - Richtlinien prüfen den absoluten Zielpfad auf dem Server. Bei
create/deleteist das der zu erstellende/löschende Znode, nicht der Elternknoten, dessen ACL geprüft wird. Bei Chroot-Anfragen muss der tatsächliche Chroot-Präfix im Richtlinienpfad stehen:/brokersunter Chroot/kafkaentspricht/kafka/brokers. Sequenziellescreateprüft den absoluten Anfragepräfix auf dem Server vor dem Anhängen der Sequenznummer; spätereread/delete-Prüfungen verwenden den vollständigen erzeugten Knotennamen. - Native ACLs werden nicht automatisch migriert, und ACLs werden nicht rekursiv vererbt; neue Znodes brauchen eine ausdrücklich gesetzte Marker-ACL. Prüfe vor
setACLerlaubte und abgelehnte Zugriffe in einem kleinen Bereich und behalte einen unabhängigen administrativen Zugang. Setze den Marker nicht unüberlegt am Wurzelknoten, um dich nicht auszusperren. - Ein Server ohne Agent gleicht
sasl:grantforgemit der nativen SASL-Identitätgrantforgeab, statt Richtlinien auszuwerten. Deshalb ist die Bereitstellung auf allen Knoten erforderlich; eine teilweise Bereitstellung schützt das Ensemble nicht. - Bei Schreibanfragen, die ein Follower/Observer an den Leader weiterleitet, kann an dieser Provider-Schnittstelle die Client-Verbindung fehlen; der
clientAddress-Kontext kann daher leer sein. Durchgängige Ensemble-Richtlinien auf Basis der Client-IP sind nicht garantiert. - Dieser Provider kennt das endgültige Ergebnis einer Anfrage nicht. Er sendet daher keine abschließenden
AccessEvent-Auditereignisse und bietet kein vollständiges Zugriffsaudit.
