2026.3.0

La 2026.3.0 estende le autorizzazioni dei sistemi esterni ad Apache Pulsar, Apache Solr, ClickHouse, PostgreSQL e OpenSearch. Gli agenti di Pulsar e Solr decidono ogni richiesta all'interno del sistema; gli agenti di ClickHouse, PostgreSQL e OpenSearch girano accanto al sistema e mantengono il suo controllo degli accessi allineato alle policy, così il sistema verifica da sé ogni richiesta. L'elenco completo delle modifiche è nel confronto su GitHub.

Apache Pulsar

• Un plugin di servizio Pulsar: tenant, namespace, topic, le sottoscrizioni sotto un topic e cluster, con produce, consume, functions, sources, sinks e packages di Pulsar e l'amministrazione di topic, namespace e tenant; accede con un token, una password, credenziali client OAuth 2.0 o un certificato client TLS; vedi Apache Pulsar.
• Un provider di autorizzazione dei broker che decide ogni verifica in sequenza sul tenant, sul namespace, sul topic e sulla sottoscrizione, con condizioni sull'indirizzo del client; admin su un cluster rende un ruolo superutente di Pulsar, e le concessioni tramite Pulsar stesso vengono rifiutate; vedi l'agente Pulsar.
• I test di integrazione coprono Pulsar 3.0.17, 3.3.9, 4.0.14 e 4.2.5.

Apache Solr

• Un plugin di servizio Solr: le collection, i percorsi di richiesta al loro interno come /select o /export, così che una policy possa consentire una collection e negare un handler, e il cluster; accede con l'autenticazione di base o un JSON Web Token; vedi Apache Solr.
• Un plugin di autorizzazione dei nodi che classifica le richieste come fa il plugin basato su regole di Solr e decide ciascuna sulla sua collection e sul suo percorso di richiesta; le richieste della Collections API richiedono admin_collection su ogni collection che nominano, e i ruoli verificati di un JSON Web Token contano come gruppi; vedi l'agente Solr.
• I test di integrazione coprono nodi SolrCloud di Solr 9.8.1, 9.10.1, 9.11.0 e 10.0.0, sotto il security manager di Solr 9.

ClickHouse

• Un plugin di servizio ClickHouse: database, tabelle, colonne e il server; lettura e scrittura sono decise per colonna, e le operazioni su tabelle, database e server con i propri tipi di accesso, nessuno dei quali è un gruppo di privilegi, così una policy non dà mai più di quanto nomina; vedi ClickHouse.
• Un agente accanto ai server che mantiene un ruolo per utente con esattamente ciò che danno le policy, e una row policy per ogni filtro di righe; un tipo di accesso consentito su un intero database senza nulla di limitato al di sotto viene concesso sul database, così le nuove tabelle lo hanno subito; vedi l'agente ClickHouse.
• Gli accessi sono riportati da system.query_log; le concessioni fatte al di fuori di GrantForge che danno ciò che una policy nega vengono segnalate. I test di integrazione coprono ClickHouse 24.8, 25.3, 25.8, 26.3 e 26.8.

PostgreSQL

• Un plugin di servizio PostgreSQL: database, schemi, tabelle e viste, e colonne, con i privilegi di PostgreSQL al livello in cui PostgreSQL li concede; accede con una password o un certificato client TLS, con le modalità TLS di libpq; vedi PostgreSQL.
• Un agente accanto ai server che mantiene un ruolo per utente in ogni database, fino alle colonne, con il CONNECT, l'USAGE di schema e le sequenze serial che servono, e modifica ogni database in una transazione; i filtri di righe diventano policy restrittive di row security, che quindi solo restringono; vedi l'agente PostgreSQL.
• Gli accessi sono riportati dal log del server scritto con pgaudit. I test di integrazione coprono PostgreSQL 15, 16, 17 e 18.

OpenSearch

• Un plugin di servizio OpenSearch: indici e data stream, i loro campi e il cluster; ogni tipo di accesso è un gruppo di azioni del plugin di sicurezza; le maschere diventano i suoi campi mascherati e i filtri di righe la sua sicurezza a livello di documento; vedi OpenSearch.
• Un agente accanto al cluster che mantiene un ruolo per utente, associato solo a quell'utente, scritto come patch JSON che il plugin di sicurezza applica in tutto il cluster; i pattern di indici restano pattern dove ogni policy decide allo stesso modo su di essi, così gli indici creati in seguito sono subito raggiungibili; vedi l'agente OpenSearch.
• Gli accessi sono riportati dal log di audit del plugin di sicurezza; i ruoli al di fuori di GrantForge che danno ciò che una policy nega vengono segnalati. I test di integrazione coprono OpenSearch 2.19, 3.3, 3.6 e 3.9.

Motore di policy e agenti

• Il motore di policy dice se qualcosa sotto una risorsa potrebbe essere deciso diversamente per un utente e un accesso, così gli agenti che concedono nei termini propri di un sistema possono concedere un contenitore per intero, come tutte le tabelle di un database.
• Gli snapshot degli agenti mostrano, oltre alle policy di accesso, le policy di mascheramento e di filtro delle righe e gli utenti che nominano.

Documentazione e pubblicazione

• I plugin e gli agenti di Pulsar, Solr, ClickHouse, PostgreSQL e OpenSearch sono documentati in tutte e undici le lingue, e ogni README li elenca con le versioni verificate dai test di integrazione.
• Le barre di scorrimento della documentazione seguono la palette del sito nei temi chiaro e scuro.
• Le release di GitHub hanno come titolo il loro tag di versione.

Correzioni

• Il plugin Pulsar segnala come irraggiungibile un broker che rifiuta le connessioni.
• L'agente Solr è compilato con Solr 9.10.1, che corregge avvisi di sicurezza delle release precedenti.
• L'agente PostgreSQL legge le abbreviazioni di fuso orario come CEST negli orari del log del server.
• L'agente OpenSearch tiene SLF4J all'interno del proprio jar, così un server che lo include mantiene il proprio logging.
• La console, l'SDK e il sito della documentazione aggiornano vite, vitest, undici e dompurify a versioni che correggono avvisi npm.