IAM pour Logs Data Platform - Configurer les droits d'accès
Un guide complet pour gérer les droits d'accès de Logs Data Platform avec l'IAM OVHcloud
Vue d'ensemble
Ce guide fournit les instructions pour configurer les droits d'accès sur l'IAM OVHcloud afin de gérer les permissions des différents composants de Logs Data Platform. Il vous donnera les bonnes pratiques pour gérer les droits accordés à vos utilisateurs et vous permettra de reproduire les fonctionnalités des rôles et permissions avec le système plus avancé des politiques. Ce guide utilise des fonctionnalités expliquées dans la documentation de l'IAM. Il est donc recommandé de la lire avant de poursuivre ce guide.
Prérequis
- Un compte OVHcloud
- Un accès au
- Un compte Logs Data Platform avec l'IAM activé
Politiques et identités
Ce guide s'appuie sur les utilisateurs locaux pour expliquer comment partager des ressources avec un autre utilisateur. Les politiques créées peuvent être appliquées à n'importe quelle identité OVHcloud via l'API OVHcloud. Vous pouvez utiliser ces politiques pour partager des données avec un utilisateur local, un autre compte utilisateur OVHcloud ou un client OAuth. Vous pouvez vous référer au guide spécifique Politiques IAM avec l'API pour recréer toutes ces politiques avec l'API.
L'identité verra un nouveau service apparaître dans son Logs Data Platform. Ce service contient les éléments Logs Data Platform partagés. Pour que le destinataire puisse voir les éléments partagés, nous devons partager avec lui une vue du service.
Gestion des droits d'accès
Cette section détaille comment configurer des groupes d'utilisateurs locaux/d'identités et des politiques pour reproduire le comportement de l'ancien système de rôles.
Créer un groupe pour les utilisateurs locaux
Par défaut, le groupe le moins privilégié disponible pour les utilisateurs locaux dispose d'un accès en lecture seule sur tous les produits de votre compte. Si vous souhaitez un compte encore plus restreint, capable uniquement de lire les données partagées depuis votre Logs Data Platform, nous vous conseillons de créer un groupe avec le rôle None et d'y rattacher vos utilisateurs locaux. Dans l'espace client OVHcloud, accédez à IAM > Identités > Groupes d'utilisateurs pour créer un tel groupe.
Vous pouvez ensuite créer une politique avec les droits de base pour accéder à l'espace client OVHcloud et l'attacher au groupe. Tous vos utilisateurs locaux pourront alors se connecter à l'espace client OVHcloud. Accédez à IAM > Politiques > Mes politiques pour créer cette politique et l'attacher au groupe d'utilisateurs.
Après avoir attaché le groupe, suivez les instructions de notre guide : Créer une politique IAM pour autoriser l'accès des utilisateurs à l'espace client OVHcloud.
Une fois le groupe configuré, vous pouvez alors créer les utilisateurs locaux.
Créer un utilisateur local
La création d'un utilisateur local est entièrement documentée dans la documentation dédiée. N'oubliez pas d'attacher l'utilisateur au groupe.
Créer une politique pour le service
Vous devez maintenant créer une politique pour permettre à l'utilisateur local de voir le service Logs Data Platform dans l'espace client OVHcloud. L'objectif ici est de n'avoir accès qu'au service, sans qu'aucune sous-ressource ne soit visible (c'est-à-dire aucun flux, tableau de bord, index, alias ou instance OpenSearch Dashboards). Accédez à IAM > Politiques > Mes politiques pour créer cette politique.
Ajoutez l'utilisateur local à votre politique et sélectionnez le type de produit Logs Data Platform : service pour lister vos services dans la liste déroulante Resources et activer le panneau des Actions liées au service Logs Data Platform.
La politique peut ensuite autoriser un accès en lecture seule au service choisi. Certaines actions sont obligatoires pour que les utilisateurs puissent afficher le Control Panel de Logs Data Platform sans erreur. L'ensemble minimal d'actions est listé ci-dessous :
Une fois la politique attachée à l'identité, les utilisateurs verront le nouveau service dans leur Control Panel, mais sans aucun élément disponible.
Créer un groupe de sous-ressources
Tous les éléments créés par un Logs Data Platform (flux, tableaux de bord, etc.) sont matérialisés comme des sous-ressources du service LDP. L'une des nouvelles fonctionnalités disponibles grâce à l'IAM est la possibilité de regrouper des sous-ressources dans un groupe de ressources. Un groupe de ressources permet de partager des ressources liées entre elles et constitue un moyen pratique de regrouper des éléments destinés à être utilisés ensemble. Par exemple : un flux et son tableau de bord associé, un alias et une instance OpenSearch Dashboards pour l'explorer, ou encore un alias avec tous les flux qui lui sont rattachés. Cette fonctionnalité est un bon moyen d'isoler complètement des sous-ressources et de vous éviter d'avoir à les gérer une par une dans toutes vos politiques.
Pour créer un groupe de ressources, accédez à IAM > Politiques > Groupes de ressources.
Vous devez sélectionner le type de produit (Dashboards, Streams, Alias, Index, OpenSearch Dashboards), puis sélectionner la ressource spécifique que vous souhaitez partager.
Créer une politique pour les sous-ressources
Cette politique est celle qui vous permet de reproduire effectivement les permissions des anciens rôles. Vous y attacherez des droits sur les API OVHcloud et des droits sur le backend (Graylog, OpenSearch) pour permettre aux identités de voir les éléments de leur service partagé et d'interagir avec eux dans les interfaces web et API correspondantes. Là encore, accédez à IAM > Politiques > Mes politiques pour créer une politique.
Comme pour la politique précédente, vous devez ajouter votre utilisateur local, et vous devez sélectionner le type de produit de votre ressource ou sous-ressource si vous souhaitez activer le panneau de sélection des actions pour ces sous-ressources spécifiques.
N'ajoutez pas de service Logs Data Platform à cette politique. Si vous le faites, cela donnera automatiquement accès à toutes les sous-ressources de ce service (c'est-à-dire tous les éléments LDP) aux utilisateurs locaux/identités ou groupes attachés à la politique. La politique de service précédente a été créée pour éviter ce comportement.
Vous pouvez combiner des groupes de ressources et des ressources spécifiques dans une même politique. Toutes les actions attachées à la politique seront alors appliquées à toutes les sous-ressources concernées. Chaque type de sous-ressource dispose de plusieurs actions. Par souci de concision, ce guide ne détaillera pas toutes les actions disponibles pour tous les éléments.
Voici quelques cas d'usage combinant plusieurs droits, qui peuvent tous coexister dans une même politique, illustrant la complexité rendue possible par les politiques IAM. Les actions commençant par ldp:apiovh sont des actions liées aux API OVHcloud (donc à l'interface du Control Panel). Les autres actions sont liées à leur backend spécifique : Graylog ou OpenSearch.
Cliquez sur les liens suivants pour afficher les exemples correspondants :
Ces actions donnent un accès en lecture seule à un ou plusieurs index :
Ces actions permettent de lire et de modifier un tableau de bord Graylog :
Ces actions permettent de consulter et de créer des visualisations dans une ou plusieurs instances OpenSearch Dashboards :
Ces actions donnent un accès en lecture seule, à la fois dans Graylog et dans le Control Panel, à un ou plusieurs flux :
Une fois la politique créée, l'utilisateur local/l'identité ne verra que la sous-ressource associée à la politique dans son propre Control Panel.
Analyser les résultats de votre politique
Vous pouvez vérifier l'exactitude de vos politiques à l'aide du guide de dépannage de l'IAM.
Aller plus loin avec les utilisateurs locaux
Les utilisateurs locaux sont utiles pour générer des jetons d'accès personnels (Personal Access Tokens, PAT). Ces jetons disposent d'une date d'expiration configurable et peuvent être utilisés pour interagir aussi bien avec les API OVHcloud qu'avec les backends de Logs Data Platform.
Grâce à l'IAM OVHcloud, vous pouvez ensuite déléguer les droits de création de sous-ressources (index, alias) à votre utilisateur local et interagir directement avec les API backend à l'aide de ces jetons d'accès personnels.
Les actions liées à la création d'éléments font partie des actions de service. Vous devrez les ajouter à une politique pour permettre à un utilisateur de créer des éléments avec son PAT.
Vous n'avez besoin d'autoriser aucune action des API OVHcloud pour permettre à un utilisateur local d'interagir avec les API des backends de Logs Data Platform (OpenSearch, Graylog, OpenSearch Dashboards). Les utilisateurs locaux vous permettent de générer des jetons qui ne peuvent interagir qu'avec le backend, de manière similaire aux anciens jetons Logs Data Platform.
Par exemple, ces deux droits permettent à un utilisateur local de créer des index/alias directement sur OpenSearch sans disposer d'aucun autre droit sur les API OVHcloud.
Aller plus loin
- Introduction à Logs Data Platform
- IAM pour Logs Data Platform - Présentation et FAQ
- Notre documentation
- Créer un compte : Essayez !
- Rejoignez notre communauté d'utilisateurs