Trino

Le plug-in Trino recherche les catalogues, schémas, tables, colonnes et propriétés de session, et gère des politiques d’accès, de filtrage de lignes et de masquage sur ce que Trino vérifie : les données, les routines, les propriétés de session, les utilisateurs et les informations système. Son ID de plug-in et son type de service valent tous deux trino. Le plug-in de service s’exécute dans le serveur GrantForge ; l’agent Trino, installé dans le coordinator, applique les politiques.

Les tests d’intégration Testcontainers du dépôt couvrent Trino 470, 476, 479 et 484, et sur 470 et 484 HTTPS avec un fichier de mots de passe et des jetons web JSON, ainsi que Kerberos. Cela ne certifie pas toutes les autres versions.

Installation

La distribution inclut le plug-in dans plugins/trino. Vérifiez que trino est activé sous Administration de la plateforme → Plug-ins ; relancez l’analyse du répertoire des plug-ins après une mise à jour. Le plug-in parle au coordinator par le pilote JDBC de Trino (trino-jdbc 484), dans un chargeur de classes qui lui est propre, et ce pilote parle à toutes les versions de Trino ci-dessus.

Ajouter un service de données

1. Ouvrez Permissions sur les données → Services de données, ajoutez un service et sélectionnez Trino (trino).
2. Saisissez l’URL JDBC du coordinator, par exemple jdbc:trino://trino.example.com:8443.
3. Choisissez comment l’utilisateur de recherche se connecte, saisissez-le, testez la connexion et enregistrez le service. Le test se connecte et décrit le coordinator : sa version et le nombre de catalogues que l’utilisateur voit.

Les paramètres portent les noms du pilote, ils se lisent donc comme la documentation JDBC de Trino. L’utilisateur de recherche permet à GrantForge de découvrir les ressources ; il est distinct des utilisateurs qui interrogent. Un test de connexion réussi ne signifie pas que les requêtes sont déjà soumises aux politiques.

Le service est exactement ce que disent ses champs. L’URL ne peut porter ni identifiants ni ce qui connecterait autrement : user, password, accessToken, sessionUser, extraCredentials, l’authentification externe et OAuth 2.0, les fichiers et la délégation Kerberos, ainsi que les mots de passe des magasins de clés et de confiance y sont refusés. Les champs d’un autre mode de connexion sont refusés aussi, par exemple un jeton avec l’authentification par mot de passe.

Un coordinator dont le certificat ne peut être vérifié n’est pas contacté : le test le signale injoignable. Une connexion refusée, des permissions manquantes et un coordinator injoignable sont signalés comme tels.

Kerberos

Avec kerberos, GrantForge connecte le principal, depuis le keytab ou avec le mot de passe, et remet au pilote les identifiants de cette connexion ; rien d’autre sur le serveur GrantForge n’a besoin de paramètres Kerberos. Les realms dont les KDC sont saisis dans kerberos.kdc sont déclarés pour tout le serveur GrantForge, comme le font les plug-ins HDFS, Hive, Kafka et HBase, si bien que plusieurs services peuvent utiliser des realms différents côte à côte. L’utilisateur de session est le nom du principal avant le realm, comme Trino associe les principaux par défaut.

Ce que voit l’utilisateur de recherche

Une fois que l’agent Trino applique les politiques, les listes omettent ce que l’utilisateur de recherche ne peut pas utiliser : donnez-lui une politique qui autorise select sur le catalogue *, ou sur les catalogues dont l’éditeur de politiques doit suggérer les ressources.

Ressources et types d’accès

all implique select, insert, update, delete, create, drop et alter.

Une permission sur un catalogue, un schéma ou une table couvre tout ce qu’il contient : select sur le schéma sales lit chacune de ses tables, create sur un catalogue y crée des schémas et des tables. Une vérification est décidée à chaque portée qu’elle nomme, et un refus à l’une d’elles la rejette ; une politique peut donc autoriser un schéma et refuser une colonne d’une de ses tables. Les fonctions, procédures et propriétés de session s’accordent en les nommant, avec * pour toutes celles d’un schéma ou d’un catalogue, et les fonctions ont leurs propres types d’accès : une autorisation sur des routines ne vaut jamais pour des tables.

Dans les valeurs de politique, * correspond à un nombre quelconque de caractères et ? à un seul. L’éditeur de politiques suggère les catalogues, les schémas des catalogues qu’une politique nomme, les tables de ses schémas, les colonnes de ses tables et les propriétés de session de ses catalogues et du système ; les fonctions, procédures et utilisateurs ne sont pas suggérés.

Filtres de lignes et masques

Les politiques de filtrage de lignes sur une table, et de masquage sur une colonne, sont du SQL Trino que le coordinator applique à chaque requête qui les lit. Un filtre de lignes est une condition sur les colonnes de la table, comme region = 'EU' ; les noms qu’il contient se résolvent dans le catalogue et le schéma de la table.

L’agent adapte chaque masque au type de la colonne, pour qu’un masque ne casse jamais la requête qui lit la colonne : voir l’agent Trino.

Exemple de politiques

Supposons que le catalogue hive ait un schéma sales avec les tables orders, dont les colonnes incluent region, customer et card, et returns. Créez ces politiques activées dans le même service de données :

Une fois que l’agent applique le nouvel instantané, les membres de analysts lisent toutes les tables de sales sauf orders.card, et voient customer haché ; alice ne voit que les commandes européennes, écrit dans returns, et voit les requêtes de Bob dans system.runtime.queries à côté des siennes.

Appliquer les politiques

Le plug-in de service gère les politiques et recherche les ressources. Les appliquer exige l’agent Trino dans le coordinator. Voir l’agent Trino pour son déploiement et ce qu’il vérifie.

Guides associés

• Services de données, politiques et agents
• Agent Trino
• Plug-ins et types de service