2026.3.0

2026.3.0 erweitert die Berechtigungen externer Systeme auf Apache Pulsar, Apache Solr, ClickHouse, PostgreSQL und OpenSearch. Die Agenten für Pulsar und Solr entscheiden jede Anfrage im System selbst; die Agenten für ClickHouse, PostgreSQL und OpenSearch laufen neben dem System und halten dessen eigene Zugriffskontrolle mit den Richtlinien im Einklang, sodass das System jede Anfrage selbst prüft. Die vollständige Liste der Änderungen finden Sie im GitHub-Vergleich.

Apache Pulsar

• Ein Pulsar-Service-Plug-in: Tenants, Namespaces, Topics, die Subscriptions unterhalb eines Topics und Cluster, mit Pulsars produce, consume, functions, sources, sinks und packages sowie der Verwaltung von Topics, Namespaces und Tenants; es meldet sich mit einem Token, einem Passwort, OAuth-2.0-Client-Credentials oder einem TLS-Client-Zertifikat an; siehe Apache Pulsar.
• Ein Autorisierungsanbieter der Broker, der jede Prüfung nacheinander am Tenant, Namespace, Topic und an der Subscription entscheidet, mit Bedingungen auf die Client-Adresse; admin auf einem Cluster macht eine Rolle zum Pulsar-Superuser, und Berechtigungen über Pulsar selbst werden abgelehnt; siehe den Pulsar-Agenten.
• Die Integrationstests decken Pulsar 3.0.17, 3.3.9, 4.0.14 und 4.2.5 ab.

Apache Solr

• Ein Solr-Service-Plug-in: Collections, die Anfragepfade darin wie /select oder /export, sodass eine Richtlinie eine Collection erlauben und einen Handler verweigern kann, und der Cluster; es meldet sich mit Basic Authentication oder einem JSON Web Token an; siehe Apache Solr.
• Ein Autorisierungs-Plug-in der Knoten, das Anfragen so einordnet wie Solrs regelbasiertes Plug-in und jede an ihrer Collection und ihrem Anfragepfad entscheidet; Anfragen der Collections API benötigen admin_collection auf jeder Collection, die sie nennen, und die verifizierten Rollen eines JSON Web Tokens zählen als Gruppen; siehe den Solr-Agenten.
• Die Integrationstests decken SolrCloud-Knoten von Solr 9.8.1, 9.10.1, 9.11.0 und 10.0.0 ab, unter dem Security Manager von Solr 9.

ClickHouse

• Ein ClickHouse-Service-Plug-in: Datenbanken, Tabellen, Spalten und der Server; Lesen und Schreiben werden pro Spalte entschieden, Operationen auf Tabellen, Datenbanken und dem Server über eigene Zugriffstypen, von denen keiner eine Privilegiengruppe ist, sodass eine Richtlinie nie mehr gibt, als sie nennt; siehe ClickHouse.
• Ein Agent neben den Servern, der pro Benutzer eine Rolle mit genau dem hält, was die Richtlinien geben, und eine Row Policy pro Zeilenfilter; ein Zugriffstyp, der auf einer ganzen Datenbank erlaubt ist, ohne dass darunter etwas eingeschränkt ist, wird auf der Datenbank gewährt, sodass neue Tabellen ihn sofort haben; siehe den ClickHouse-Agenten.
• Zugriffe werden aus system.query_log gemeldet; Berechtigungen außerhalb von GrantForge, die geben, was eine Richtlinie verweigert, werden gemeldet. Die Integrationstests decken ClickHouse 24.8, 25.3, 25.8, 26.3 und 26.8 ab.

PostgreSQL

• Ein PostgreSQL-Service-Plug-in: Datenbanken, Schemas, Tabellen und Views sowie Spalten, mit PostgreSQLs Privilegien auf der Ebene, auf der PostgreSQL sie vergibt; es meldet sich mit einem Passwort oder einem TLS-Client-Zertifikat an, mit den TLS-Modi von libpq; siehe PostgreSQL.
• Ein Agent neben den Servern, der in jeder Datenbank eine Rolle pro Benutzer hält, bis hinunter zu Spalten, mit dem nötigen CONNECT, USAGE auf Schemas und Serial-Sequenzen, und jede Datenbank in einer Transaktion ändert; Zeilenfilter werden zu restriktiven Row-Security-Richtlinien und schränken daher nur ein; siehe den PostgreSQL-Agenten.
• Zugriffe werden aus dem mit pgaudit geschriebenen Serverlog gemeldet. Die Integrationstests decken PostgreSQL 15, 16, 17 und 18 ab.

OpenSearch

• Ein OpenSearch-Service-Plug-in: Indizes und Data Streams, ihre Felder und der Cluster; jeder Zugriffstyp ist eine Aktionsgruppe des Security-Plug-ins; Masken werden zu dessen maskierten Feldern und Zeilenfilter zu dessen Document Level Security; siehe OpenSearch.
• Ein Agent neben dem Cluster, der pro Benutzer eine Rolle hält, die nur diesem Benutzer zugeordnet ist, geschrieben als JSON-Patches, die das Security-Plug-in im ganzen Cluster anwendet; Indexmuster bleiben Muster, wo jede Richtlinie über sie gleich entscheidet, sodass später angelegte Indizes sofort erreichbar sind; siehe den OpenSearch-Agenten.
• Zugriffe werden aus dem Audit-Log des Security-Plug-ins gemeldet; Rollen außerhalb von GrantForge, die geben, was eine Richtlinie verweigert, werden gemeldet. Die Integrationstests decken OpenSearch 2.19, 3.3, 3.6 und 3.9 ab.

Policy-Engine und Agenten

• Die Policy-Engine sagt, ob etwas unterhalb einer Ressource für einen Benutzer und einen Zugriff anders entschieden werden könnte, sodass Agenten, die in den Begriffen eines Systems gewähren, einen Container als Ganzes gewähren können, etwa jede Tabelle einer Datenbank.
• Agenten-Snapshots zeigen neben ihren Zugriffsrichtlinien auch ihre Maskierungs- und Zeilenfilterrichtlinien und die Benutzer, die sie nennen.

Dokumentation und Veröffentlichung

• Die Plug-ins und Agenten für Pulsar, Solr, ClickHouse, PostgreSQL und OpenSearch sind in allen elf Sprachen dokumentiert, und jede README listet sie mit den Versionen, die die Integrationstests prüfen.
• Die Scrollleisten der Dokumentation folgen der Farbpalette der Website im hellen und dunklen Design.
• GitHub-Releases tragen ihren Versions-Tag als Titel.

Fixes

• Das Pulsar-Plug-in benennt einen Broker, der Verbindungen ablehnt, als nicht erreichbar.
• Der Solr-Agent wird gegen Solr 9.10.1 gebaut, das Sicherheitshinweise früherer Versionen behebt.
• Der PostgreSQL-Agent liest Zeitzonenabkürzungen wie CEST in den Zeiten des Serverlogs.
• Der OpenSearch-Agent behält SLF4J in seinem Jar, sodass ein Server, der ihn bündelt, seine eigene Protokollierung behält.
• Konsole, SDK und Dokumentations-Website aktualisieren vite, vitest, undici und dompurify auf Versionen, die npm-Sicherheitshinweise beheben.