Agent OpenSearch

L’agent OpenSearch est un service à côté du cluster. Il maintient le contrôle d’accès propre au plug-in de sécurité en phase avec les politiques signées d’un service de données opensearch : un rôle par utilisateur qui contient exactement ce que les politiques lui donnent, associé à ce seul utilisateur, avec sécurité au niveau des champs, champs masqués et sécurité au niveau des documents. OpenSearch vérifie alors lui-même chaque requête, et l’agent ne se place jamais entre les clients et le cluster. La distribution le fournit sous forme de JAR exécutable, agents/opensearch/grantforge-agent-opensearch-<version>.jar, qui requiert Java 17 ou plus récent.

Les tests d’intégration Testcontainers du dépôt exécutent l’agent, et le JAR tel que livré, contre OpenSearch 2.19, 3.3, 3.6 et 3.9 avec le plug-in de sécurité. Cela ne certifie pas toutes les autres versions ; l’agent refuse les clusters antérieurs à 2.19 et les clusters sans plug-in de sécurité. Pour le plug-in de service, voir OpenSearch.

Fonctionnement

• Un rôle par utilisateur contient ce que GrantForge donne. Pour chaque utilisateur à qui les politiques donnent quelque chose, l’agent tient un rôle à son nom, grantforge_alice pour alice, associé à ce seul utilisateur. Sa description le marque comme celui de l’agent, et l’agent ne prend aucun rôle sans cette marque pour l’un des siens, de sorte qu’il ne modifie aucun autre rôle ni association.
• Les motifs d’index restent des motifs. Un motif d’index d’une politique, comme logs-*, est accordé comme motif partout où toutes les politiques décident de même sur toute son étendue : toute politique de tout type dont les index recoupent le motif le couvre entièrement. L’agent le décide exactement, avec des automates finis des motifs. Les index créés ensuite, comme les journaux de demain, sont alors aussitôt accessibles, y compris quand le premier document écrit les crée. Là où une politique décide autrement à l’intérieur d’un motif, comme un refus de logs-secret dans logs-*, l’agent accorde chaque index et flux de données du cluster par son nom, et les nouveaux à la synchronisation suivante.
• La sécurité au niveau des champs seulement là où quelque chose en dessous se décide autrement. Un index que l’utilisateur peut lire en entier, sans politique qui pourrait lui retirer un champ, est lu sans sécurité au niveau des champs, de sorte que les champs ajoutés plus tard sont lus aussitôt. Sinon l’utilisateur lit les champs qu’une politique autorise, parmi ceux que ses documents ont et ceux que les politiques nomment ; les multi-champs comme name.keyword suivent leur champ.
• Masques et filtres de lignes sont ceux du plug-in de sécurité. Un masque devient un champ masqué de l’entrée, et un filtre de lignes sa requête de sécurité au niveau des documents. L’API validate d’OpenSearch vérifie chaque requête avant qu’elle soit accordée ; une requête qu’OpenSearch n’exécuterait pas ne montre aucun document à l’utilisateur, et elle est journalisée. Un masque que le plug-in de sécurité ne connaît pas cache le champ à la place.
• Une entrée par ensemble de permissions. Les index et motifs aux mêmes permissions partagent une entrée ; les entrées ne se recoupent jamais, car le plug-in de sécurité combine la sécurité au niveau des champs et des documents des entrées qui se recoupent.
• Les opérations composites du cluster viennent avec la lecture et l’écriture. La lecture apporte cluster_composite_ops_ro, pour multi-search, multi-get et le défilement, et l’écriture cluster_composite_ops, pour bulk.
• Les changements sont un correctif. L’agent écrit ses rôles et associations comme correctifs JSON, que le plug-in de sécurité applique d’un coup dans tout le cluster : les rôles avant les associations qui les nomment, les associations avant les rôles qu’elles nomment et qui sont retirés. Un correctif que le plug-in de sécurité refuse est appliqué changement par changement, de sorte qu’un rôle défectueux échoue seul.
• Les politiques du moment présent. Chaque synchronisation planifie selon les politiques telles qu’elles s’appliquent à ce moment, de sorte que les périodes de validité commencent et finissent à l’heure.
• Les rôles backend sont des groupes. Une politique pour un groupe s’applique aux utilisateurs internes qui ont un rôle backend de ce nom, ainsi qu’aux groupes dans lesquels GrantForge place les utilisateurs.
• Les changements faits à la main sont annulés. L’agent compare à chaque synchronisation ses rôles et associations avec ce que détient le plug-in de sécurité ; ce qui diffère est réécrit. Quand rien n’a changé, l’agent n’envoie rien.
• Les rôles hors de GrantForge sont signalés. OpenSearch accorde ce que donne n’importe lequel des rôles d’un utilisateur, l’agent ne peut donc pas retirer ce qu’un autre rôle associé à l’utilisateur donne. Il avertit une fois de chaque rôle de ce genre qui donne ce qu’une politique refuse, en nommant le rôle, l’utilisateur, l’accès, l’index et la politique, ainsi que des utilisateurs associés à all_access, qu’aucun rôle ne lie.
• Les accès viennent du journal d’audit. L’agent lit le journal d’audit du plug-in de sécurité dans les index où il l’écrit, security-auditlog-* : ce qu’il a refusé, comme MISSING_PRIVILEGES, et ce qu’il a autorisé, comme GRANTED_PRIVILEGES lorsque la configuration d’audit les journalise. Chaque événement nomme l’utilisateur, le type d’accès, chaque index ou flux de données atteint, ou le cluster, et dit si GrantForge l’a décidé ou si un rôle hors de GrantForge l’a autorisé.

Déploiement

1. Ajoutez un service de données opensearch et configurez ses politiques. Ouvrez Autorisations sur les données → Agents, sélectionnez le service et émettez un jeton d’agent. Il n’est affiché qu’une fois ; conservez-le dans un fichier que seul le compte de l’agent peut lire.

2. Donnez à l’agent un utilisateur qui peut modifier la configuration du plug-in de sécurité : un utilisateur associé à all_access tant que plugins.security.restapi.roles_enabled le liste, ou le certificat d’administration que nomme plugins.security.authcz.admin_dn. Les tests exécutent l’agent avec l’admin de la configuration de démonstration, et avec son certificat d’administration.

3. Pour signaler les accès, gardez le journal d’audit dans le cluster (plugins.security.audit.type: internal_opensearch). Pour ce qu’OpenSearch a autorisé, retirez aussi GRANTED_PRIVILEGES des catégories désactivées de la configuration d’audit ; les refus sont journalisés par défaut.

4. Écrivez le fichier de paramètres en remplaçant les adresses, chemins et noms d’exemple :

   grantforge.server.url=https://grantforge.example.com
   grantforge.token.file=/etc/grantforge/opensearch-agent.token
   grantforge.instance=opensearch-agent-1
   grantforge.cache.dir=/var/lib/grantforge/opensearch-agent
   grantforge.opensearch.hosts=https://opensearch1.internal:9200,https://opensearch2.internal:9200
   grantforge.opensearch.user=grantforge
   grantforge.opensearch.password.file=/etc/grantforge/opensearch-agent.password
   grantforge.opensearch.tls.ca=/etc/grantforge/opensearch-ca.pem

   Ces chemins sont sur la machine de l’agent, et le répertoire de cache doit être accessible en écriture. Les fichiers de mot de passe sont lus en UTF-8 et rognés.

5. Démarrez l’agent, par exemple comme service systemd :

   java -jar agents/opensearch/grantforge-agent-opensearch-<version>.jar /etc/grantforge/opensearch-agent.properties

   Remplacez <version> par la version de la distribution. Les paramètres fournis sous la forme java -Dgrantforge.…=… -jar … remplacent ceux du fichier. L’agent s’arrête proprement sur SIGTERM et envoie ou met en file les événements en attente ; OpenSearch garde ce qu’il a reçu.

6. Transférer les rôles existants dans des politiques : les rôles associés aux utilisateurs hors de GrantForge continuent de s’appliquer à côté de ceux de l’agent. Créez les politiques correspondantes, puis supprimez ces associations ; les avertissements de l’agent nomment les rôles qui donnent ce qu’une politique refuse.

Utilisateurs, groupes et rôles

Les politiques nomment les utilisateurs d’OpenSearch tels que le plug-in de sécurité les connaît. L’agent tient des rôles pour les utilisateurs internes, pour les utilisateurs que nomment les politiques, qui peuvent se connecter par un annuaire comme LDAP ou SAML, et pour les utilisateurs dont il tenait déjà des rôles ; les utilisateurs réservés et cachés du plug-in de sécurité, comme kibanaserver, sont laissés tranquilles. Les groupes sont les rôles backend d’un utilisateur interne ainsi que les groupes dans lesquels GrantForge place l’utilisateur ; l’agent ne connaît pas les rôles backend qu’un annuaire donne à la connexion, donnez donc à ces utilisateurs leurs groupes dans GrantForge. Les rôles sont ceux que GrantForge donne à l’utilisateur.

Décisions et limites

• Sans instantané, l’agent ne change rien. Un service inutilisé, ou un jeton lié à un service dont le type n’est pas opensearch, n’accorde rien : l’agent retire ses rôles et associations, et les rôles propres du plug-in de sécurité s’appliquent.
• Tant que l’agent ne tourne pas, OpenSearch garde ce qu’il a reçu en dernier ; les changements de politiques l’attendent. Un changement atteint OpenSearch dans l’intervalle de rafraîchissement et l’intervalle de synchronisation.
• Les index accordés par leur nom, et non par un motif, reçoivent leurs permissions à la synchronisation suivante.
• Les alias atteignent les index qui les composent : rechercher dans un alias demande des permissions sur chacun de ses index, donc les politiques nomment des index et des flux de données, pas des alias.
• Un filtre de lignes ne peut tester que les champs que l’utilisateur peut lire, et un masque s’applique aux valeurs des champs text et keyword.
• Les index dont le nom commence par un point ne sont atteints que par des motifs de politique qui commencent par un point.
• L’agent ne gère pas les tenants du plug-in de sécurité pour OpenSearch Dashboards.

Guides associés

• OpenSearch
• Services de données, politiques et agents