2026.3.0

2026.3.0 étend les permissions des systèmes externes à Apache Pulsar, Apache Solr, ClickHouse, PostgreSQL et OpenSearch. Les agents Pulsar et Solr décident chaque requête à l'intérieur du système ; les agents ClickHouse, PostgreSQL et OpenSearch s'exécutent à côté du système et maintiennent son propre contrôle d'accès en accord avec les politiques, de sorte que le système vérifie lui-même chaque requête. La liste complète des changements se trouve dans la comparaison GitHub.

Apache Pulsar

• Un plug-in de service Pulsar : tenants, espaces de noms, sujets, les abonnements sous un sujet et clusters, avec produce, consume, functions, sources, sinks et packages de Pulsar et l'administration des sujets, espaces de noms et tenants ; il se connecte avec un jeton, un mot de passe, des identifiants client OAuth 2.0 ou un certificat client TLS ; voir Apache Pulsar.
• Un fournisseur d'autorisation des brokers qui décide chaque vérification successivement au tenant, à l'espace de noms, au sujet et à l'abonnement, avec des conditions sur l'adresse du client ; admin sur un cluster fait d'un rôle un superutilisateur Pulsar, et les attributions via Pulsar lui-même sont refusées ; voir l'agent Pulsar.
• Les tests d'intégration couvrent Pulsar 3.0.17, 3.3.9, 4.0.14 et 4.2.5.

Apache Solr

• Un plug-in de service Solr : les collections, les chemins de requête qu'elles contiennent comme /select ou /export, afin qu'une politique puisse autoriser une collection et refuser un gestionnaire, et le cluster ; il se connecte avec l'authentification basique ou un JSON Web Token ; voir Apache Solr.
• Un plug-in d'autorisation des nœuds qui classe les requêtes comme le plug-in à règles de Solr et décide chacune à sa collection et à son chemin de requête ; les requêtes de la Collections API nécessitent admin_collection sur chaque collection qu'elles nomment, et les rôles vérifiés d'un JSON Web Token comptent comme des groupes ; voir l'agent Solr.
• Les tests d'intégration couvrent des nœuds SolrCloud de Solr 9.8.1, 9.10.1, 9.11.0 et 10.0.0, sous le gestionnaire de sécurité de Solr 9.

ClickHouse

• Un plug-in de service ClickHouse : bases de données, tables, colonnes et le serveur ; la lecture et l'écriture sont décidées par colonne, et les opérations sur les tables, les bases de données et le serveur par leurs propres types d'accès, dont aucun n'est un groupe de privilèges, de sorte qu'une politique ne donne jamais plus que ce qu'elle nomme ; voir ClickHouse.
• Un agent à côté des serveurs qui maintient un rôle par utilisateur contenant exactement ce que donnent les politiques, et une politique de lignes par filtre de lignes ; un type d'accès autorisé sur toute une base de données sans rien de restreint en dessous est accordé sur la base de données, de sorte que les nouvelles tables l'ont aussitôt ; voir l'agent ClickHouse.
• Les accès sont rapportés depuis system.query_log ; les attributions faites hors de GrantForge qui donnent ce qu'une politique refuse sont signalées. Les tests d'intégration couvrent ClickHouse 24.8, 25.3, 25.8, 26.3 et 26.8.

PostgreSQL

• Un plug-in de service PostgreSQL : bases de données, schémas, tables et vues, et colonnes, avec les privilèges de PostgreSQL au niveau où PostgreSQL les accorde ; il se connecte avec un mot de passe ou un certificat client TLS, avec les modes TLS de libpq ; voir PostgreSQL.
• Un agent à côté des serveurs qui maintient un rôle par utilisateur dans chaque base de données, jusqu'aux colonnes, avec le CONNECT, l'USAGE de schéma et les séquences serial nécessaires, et modifie chaque base de données en une transaction ; les filtres de lignes deviennent des politiques restrictives de sécurité des lignes, qui ne font donc que restreindre ; voir l'agent PostgreSQL.
• Les accès sont rapportés depuis le journal du serveur écrit avec pgaudit. Les tests d'intégration couvrent PostgreSQL 15, 16, 17 et 18.

OpenSearch

• Un plug-in de service OpenSearch : index et flux de données, leurs champs et le cluster ; chaque type d'accès est un groupe d'actions du plug-in de sécurité ; les masques deviennent ses champs masqués et les filtres de lignes sa sécurité au niveau des documents ; voir OpenSearch.
• Un agent à côté du cluster qui maintient un rôle par utilisateur, associé à ce seul utilisateur, écrit sous forme de correctifs JSON que le plug-in de sécurité applique dans tout le cluster ; les motifs d'index restent des motifs là où toutes les politiques décident de la même façon sur eux, de sorte que les index créés plus tard sont aussitôt accessibles ; voir l'agent OpenSearch.
• Les accès sont rapportés depuis le journal d'audit du plug-in de sécurité ; les rôles hors de GrantForge qui donnent ce qu'une politique refuse sont signalés. Les tests d'intégration couvrent OpenSearch 2.19, 3.3, 3.6 et 3.9.

Moteur de politiques et agents

• Le moteur de politiques indique si quelque chose sous une ressource pourrait être décidé autrement pour un utilisateur et un accès, de sorte que les agents qui accordent dans les termes propres d'un système peuvent accorder un conteneur entier, comme toutes les tables d'une base de données.
• Les instantanés des agents montrent, en plus de leurs politiques d'accès, leurs politiques de masquage et de filtrage des lignes et les utilisateurs qu'ils nomment.

Documentation et publication

• Les plug-ins et agents Pulsar, Solr, ClickHouse, PostgreSQL et OpenSearch sont documentés dans les onze langues, et chaque README les liste avec les versions vérifiées par les tests d'intégration.
• Les barres de défilement de la documentation suivent la palette du site dans les thèmes clair et sombre.
• Les publications GitHub portent leur tag de version comme titre.

Corrections

• Le plug-in Pulsar signale un broker qui refuse les connexions comme injoignable.
• L'agent Solr est construit avec Solr 9.10.1, qui corrige des avis de sécurité des versions antérieures.
• L'agent PostgreSQL lit les abréviations de fuseau horaire comme CEST dans les heures du journal du serveur.
• L'agent OpenSearch garde SLF4J dans son jar, de sorte qu'un serveur qui l'embarque conserve sa propre journalisation.
• La console, le SDK et le site de documentation mettent à jour vite, vitest, undici et dompurify vers des versions qui corrigent des avis npm.