--- title: "Rôles et conditions" description: "Data Platform utilise une approche de contrôle d'accès basé sur les rôles pour gérer les droits dans les projets" url: https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/iam-roles-conditions lang: fr lastUpdated: 2026-09-14 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Rôles et conditions ## Objectif Data Platform utilise une approche de [contrôle d'accès basé sur les rôles](https://en.wikipedia.org/wiki/Role-based_access_control) pour gérer les droits dans les projets. Les **Rôles** sont un ensemble de permissions pouvant être attribuées soit à un utilisateur, un compte de service (uniquement dans l'IAM du projet), soit à un groupe, afin de leur donner accès à des ressources ou des données dans votre projet/organisation. Les **Conditions** permettent d'être plus précis et de n'accorder l'accès que si des conditions spécifiées sont remplies - comme si la requête est effectuée pendant les heures de travail, ou si la ressource demandée possède un certain tag. Chaque utilisateur ou compte de service dispose de la somme totale de toutes les permissions qui lui sont attribuées 1) individuellement via des rôles, et 2) attribuées aux groupes auxquels il appartient. :::info Notez que les rôles **existent à la fois dans l'IAM du projet et dans l'IAM de l'organisation**. Les captures d'écran de cet article ont été prises dans l'IAM du projet, mais les étapes sont identiques dans l'IAM de l'organisation. ::: ## Rôles Il existe deux types de rôles dans l'IAM : - Rôles prédéfinis : qui fournissent un accès pour des combinaisons courantes de services et de ressources dans un projet ou une organisation. Ils sont gérés par Data Platform. - Rôles personnalisés : qui fournissent un accès précis basé sur une liste de permissions spécifiée par l'utilisateur. ### Rôles prédéfinis Data Platform est fourni avec de nombreux rôles IAM prédéfinis conçus pour vous aider à accorder facilement les permissions habituelles pour n'importe quel projet ou organisation. Par exemple, voici la liste des rôles prédéfinis dans l'IAM du projet, en commençant par les plus courants : - _Admin_ : donne un accès administrateur complet à l'ensemble du projet - _Application User_ : donne accès à l'interrogation des [API personnalisées](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apis.md) du projet, généralement depuis une [application](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apps.md). C'est généralement le rôle que vous accorderiez à vos utilisateurs finaux ayant besoin d'accéder à vos applications, en contrôlant l'accès aux données à l'aide d'[une condition de rôle](#ajouter-une-condition-de-rôle-sur-des-valeurs-de-données-spécifiques) - _Analytics Consumer_ : généralement attribué aux utilisateurs qui exécuteront des analyses à l'aide d'un [consumer externe](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-connectors-consumers.md). Le rôle donne un accès en lecture aux sources de données et aux tables, ainsi que la possibilité de créer et d'exécuter des requêtes sur celles-ci. - _Dashboard Editor_ : donne les permissions pour créer des requêtes et des dashboards dans l'[Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md) - _Dashboard Viewer_ : donne les permissions pour accéder à la version en lecture seule des dashboards dans l'[Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md) - _Read-only_ : donne un accès en lecture à toutes les ressources du projet - _AM Admin_ : donne un accès administrateur complet à toutes les ressources de l'[Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md) - _API & App Editor_ : donne un accès administrateur complet à toutes les [API personnalisées](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apis.md) et [applications](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apps.md) - _Control Center Editor_ : donne un accès administrateur complet à toutes les ressources du [Control Center](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-control-center.md) - _LM & AM Editor_ : donne un accès administrateur complet à toutes les ressources du [Lakehouse Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-lakehouse-manager.md) (à l'exception des Buckets) et de l'[Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md) - _DPE Editor_ : donne un accès administrateur complet à toutes les ressources du [Data Processing Engine](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe.md) - _DataStore Editor_ : donne un accès administrateur complet à toutes les ressources des [Buckets](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-buckets.md) - _Identity Access Manager Editor_ : donne un accès administrateur complet à toutes les ressources de l'[Identity Access Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-iam.md) :::info Notez que la liste des rôles par défaut est différente pour l'IAM de l'organisation, car les permissions et les cas d'usage habituels sont différents. ::: ### Créer un rôle #### Depuis l'interface de l'Identity Access Manager Dans l'Identity Access Manager, ouvrez l'onglet **Roles**. Cliquez sur **New Role** en haut à droite de l'écran. ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/new_new-role.png) Les rôles sont définis par les _permissions_ atomiques qu'ils contiennent, qui sont des droits sur des ressources spécifiques.\ Après avoir renseigné l'image, le nom, la description et les tags de votre rôle, cliquez sur **Add Permission** pour ajouter une nouvelle permission au rôle. ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/new_role-init.png) Les permissions sont définies en spécifiant les éléments suivants : - le **service** et la **ressource**, c'est-à-dire la ressource du projet à laquelle l'accès est donné par la permission (par exemple dans Data Processing Engine : actions, workflows, etc.) - l'**action**, c'est-à-dire quel accès est donné à ce service et à cette ressource (par exemple créer, lire, supprimer, etc.) :::info La valeur astérisque (\*\*\*\*\*) signifie que tous les services/ressources/actions sont sélectionnés ::: :::info Des [conditions](#conditions) sur une propriété de la ressource ou de l'agent utilisateur peuvent être définies lors de l'attribution du rôle à un utilisateur ou un groupe. ::: ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/permission.png) Vous pouvez ajouter autant de permissions que vous le souhaitez à un rôle. Par exemple, le rôle ci-dessous combine un accès complet aux Workflows dans le DPE avec une permission en lecture seule sur toutes les ressources d'un second service. ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/example-role.png) Enfin, cliquez sur **Create** pour enregistrer votre rôle. #### Via l'API ```sh # {permission} doit être remplacé par une ou plusieurs permissions. # Une permission a le format suivant : "service:resource:action" # par exemple : # "iam:user:read" : donnera un accès en lecture seule à la liste des utilisateurs d'un projet curl --request POST \ --url '/roles' \ --header 'content-type: application/json' \ --data '{ "display_name": "My role", "permissions":[{permission}] }' ``` ### Attribuer un rôle à un utilisateur, un compte de service ou un groupe #### Depuis l'interface de l'Identity Access Manager Le processus est identique pour les utilisateurs, les comptes de service et les groupes. Pour attribuer un rôle à l'un d'entre eux, rendez-vous simplement dans leur onglet respectif dans l'Identity Access Manager. Sélectionnez l'utilisateur/le compte de service/le groupe que vous souhaitez modifier, et cliquez sur le bouton **Edit** ✏️ à la fin de la ligne. ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/new_edit-group.png) Cliquez sur **Add** dans l'encadré Role Conditions. ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/new_group-edition-page.png) Choisissez le rôle que vous souhaitez attribuer dans le menu déroulant. Vous pouvez également définir une condition sur l'attribution du rôle (voir ci-dessous). ![rôles](/images/public-cloud/data-platform/product/iam/users/picts/new_assign-new-role.png) Cliquez sur **Create**, puis sur **Save**. #### Via l'API ```sh # {type} doit être remplacé par "users", "service_accounts" ou "groups" # {id} doit être remplacé par l'id de l'utilisateur, du compte de service ou du groupe que vous souhaitez modifier # {roleId and anotherRoleId} doit être l'id des rôles à ajouter ## ATTENTION : cela remplacera tous les rôles de l'objet modifié. Les autres rôles déjà présents ne seront pas conservés, faites donc attention à ne pas supprimer de rôles existants. curl --request PUT \ --url '/{type}/{id}' \ --header 'content-type: application/json' \ --data '{ "roles": [{ "role":"{roleId}" },{ "role":"{anotherRoleId}" }] }' ``` ## Conditions Les conditions sont des **filtres que vous pouvez définir sur les permissions accordées par un rôle** lorsque vous l'[attribuez](#attribuer-un-rôle-à-un-utilisateur-un-compte-de-service-ou-un-groupe) à un utilisateur / compte de service / groupe. Par défaut, les rôles sont attribués sans condition. Attribuer un rôle sans définir de condition donnera l'accès complet sans restriction décrit par les permissions de ce rôle. Ajouter une condition filtrera l'accès fourni par les permissions uniquement vers des ressources plus spécifiques, ou pour des utilisateurs validant des propriétés spécifiques. :::info Par exemple, si vous attribuez un rôle avec la permission `cc:alert:write` sans aucune condition à un utilisateur, il pourra modifier l'ensemble de la liste des alertes du Control Center. ::: Cependant, si vous ajoutez une condition telle que `Name.contains("dev-")`, ce rôle ne donne à l'utilisateur qu'un accès en modification aux alertes dont le nom contient _"dev-"_, et il ne pourra pas modifier les autres alertes. 2 modèles de conditions coexistent actuellement : les [conditions JSON historiques](#anciennes-conditions-json) et les [nouvelles conditions CEL](#nouvelles-conditions-cel). Il est impossible de créer une condition JSON historique sur un rôle qui prend désormais en charge les nouvelles conditions CEL. Voir ci-dessous les informations de compatibilité pour chaque modèle. ### Nouvelles conditions CEL :::info Les conditions CEL sont actuellement indisponibles pour les rôles contenant des permissions pour le service _API_. ::: Les conditions CEL sont exprimées à l'aide du [Common Expression Language (CEL)](https://github.com/google/cel-spec/blob/master/doc/langdef.md). Elles sont composées d'**instructions logiques** pouvant être combinées à l'aide d'opérateurs booléens (AND, OR), chaque instruction logique étant constituée des éléments suivants : - un attribut - un opérateur (qui peut être une fonction appliquée à l'attribut) - une valeur De manière générale, les conditions CEL peuvent être appliquées soit sur les **ressources** décrites par les permissions du rôle, sur le **principal IAM** auquel le rôle est accordé (_bientôt disponible !_), soit sur une combinaison des deux. En complément, des conditions peuvent également être appliquées sur des éléments des **permissions** accordées par un rôle, afin d'affiner pleinement les conditions à certaines parties du rôle uniquement. Voir ci-dessous la référence de tous les attributs et opérateurs. #### Attributs de condition Les conditions suivantes (c'est-à-dire les attributs de condition) sont actuellement disponibles dans l'Identity Access Manager : - **Conditions sur les permissions du rôle** - Service (_nom CEL :_ `Service`) : applique une condition sur le service Data Platform contenant la ressource décrite par la permission (par exemple "Data Processing Engine", "Analytics Manager", etc.) - Resource (_nom CEL :_ `Resource`) : applique une condition sur la ressource Data Platform décrite par la permission (par exemple "Workflows", "Dashboards", etc.) - Action (_nom CEL :_ `Action`) : applique une condition sur l'accès accordé à la ressource par la permission (par exemple "Read", "Write", etc.) - **Conditions sur les ressources** - ID (_nom CEL :_ `Id`) : applique une condition sur l'ID de la ressource - Nom technique (_nom CEL :_ `Name`) : applique une condition sur le nom technique de la ressource - Path (_nom CEL :_ `Path`) : applique une condition sur le chemin de la ressource - **Conditions sur les policy tags (Advanced Data Access Control)** - Valeur de policy tag (_nom CEL :_ `PolicyTags.`) : applique une condition sur la valeur d'un policy tag attribué à la ressource. Remplacez `` par le nom de clé du tag (par exemple, `PolicyTags.sensitivity == "high"`). Disponible lorsque le rôle contient des permissions pour le service `adac`. - Existence de policy tag (_nom CEL :_ `has(PolicyTags.)`) : vérifie si une clé de policy tag existe sur la ressource (par exemple, `has(PolicyTags.sensitivity)`). Renvoie true si la clé du tag est présente, quelle que soit sa valeur. :::info Lors de l'utilisation de conditions ADAC, l'attribut `Resource` accepte les valeurs `dataset`, `table` et `attribute`. La valeur de l'attribut `Service` pour Advanced Data Access Control est `adac`. Voir [Policy Tags, conditions CEL](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-cel-conditions.md#accorder-lacc%C3%A8s-avec-des-conditions-cel) pour des modèles et exemples détaillés. ::: - **Conditions sur l'utilisateur/le compte de service** : bientôt disponible ! :::warning **AVERTISSEMENT** : les conditions sur une permission de _lecture_ ne sont actuellement appliquées que lors de la récupération d'un objet via l'API - elles ne sont **pas appliquées** dans l'interface graphique lors du listing et de l'ouverture d'objets. Par exemple, avec un rôle contenant un accès en lecture aux _groupes IAM_ lié à une condition sur le _nom d'un groupe IAM_, un utilisateur pourra tout de même lister, ouvrir et voir tous les groupes IAM dans l'interface graphique, mais ne pourra appeler (GET) que ce groupe spécifique via l'API. ::: #### Opérateurs de condition Les conditions suivantes (c'est-à-dire les opérateurs de condition) sont actuellement disponibles dans l'Identity Access Manager. :::info Certains opérateurs ne sont disponibles que pour des attributs spécifiques. ::: - Égal à (modélisation CEL : `attribute == ""`) - Différent de (nom CEL : `attribute != ""`) - Dans (nom CEL : `attribute in []`) - Pas dans (nom CEL : `!(attribute in [])`) - Commence par (nom CEL : `attribute.startsWith("")`) - Ne commence pas par (nom CEL : `!(attribute.startsWith(""))`) - Se termine par (nom CEL : `attribute.endsWith("")`) - Ne se termine pas par (nom CEL : `!(attribute.endsWith(""))`) - Correspond à (nom CEL : `attribute.matches("")`) - Ne correspond pas à (nom CEL : `!(attribute.matches(""))`) - Contient (nom CEL : `attribute.contains("")`) - Ne contient pas (nom CEL : `!(attribute.contains(""))`) #### Exemples Voici quelques exemples en Common Expression Language (CEL) de conditions : 1. Restreindre l'accès uniquement aux ressources nommées "demo" : ```text Name == "demo" ``` 2. Restreindre l'accès uniquement aux workflows contenus dans le dossier "my\_folder", et donner un accès complet aux autres ressources autorisées par le rôle (à condition que le rôle donne initialement accès aux workflows et à d'autres ressources) : ```text Resource != "workflow" || ( Resource == "workflow" && Path.contains("/my_folder") ) ``` 3. Restreindre l'accès uniquement au bucket nommé "my\_bucket" (le service associé est _datastore_) et au reste des ressources dans les autres services autorisés par le rôle (à condition que le rôle donne initialement au moins accès aux buckets et à certaines ressources dans d'autres services - notez que cette condition bloquera complètement l'accès aux ressources dans _datastore_ qui ne sont pas des buckets) : ```text Service != "datastore" || ( Service == "datastore" && Resource == "bucket" && Name == "my-bucket" ) ``` 4. Appliquer les policy tags aux trois niveaux, dataset, table et attribute (le service associé est _adac_). Il s'agit du modèle recommandé pour un contrôle d'accès complet : ```text Service == "adac" && ( (PolicyTags.access_level == "level 1" && Resource == "dataset") || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "table") || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "attribute") ) ``` 5. Accorder l'accès aux tables tagguées avec `sensitivity: high`, avec transmission au niveau dataset et attribute (pas d'application de tag à ces niveaux) : ```text Service == "adac" && ( Resource == "dataset" || (PolicyTags.sensitivity == "high" && Resource == "table") || Resource == "attribute" ) ``` 6. Accorder l'accès à toutes les tables qui n'ont pas le policy tag `sensitivity` : ```text Service == "adac" && ( Resource == "dataset" || (!has(PolicyTags.sensitivity) && Resource == "table") || Resource == "attribute" ) ``` :::warning Les conditions ne permettent pas de donner accès à des ressources/actions qui n'étaient pas initialement autorisées par le rôle. Les conditions peuvent uniquement filtrer davantage un rôle. ::: #### Ajouter une condition lors de l'attribution d'un rôle Il existe 2 façons d'ajouter une condition à l'attribution d'un rôle. - Le **visual builder** offre une interface point-and-click pour spécifier des conditions à l'aide d'un champ, d'un opérateur et d'une valeur (par exemple _Resource name equals my\_bucket_). - L'**éditeur CEL personnalisé** est un rédacteur de conditions en [Common Expression Language (CEL)](https://github.com/google/cel-spec/blob/master/doc/langdef.md) pour créer des conditions similaires. [Tutoriel : comment créer une condition de rôle sur un bucket spécifique](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/tutorials-bucket-role-conditions.md) ### Anciennes conditions JSON L'**éditeur JSON historique** est un rédacteur de conditions utilisant un format JSON. Les conditions JSON sont actuellement obsolètes et seront migrées automatiquement vers les nouvelles [conditions CEL](#nouvelles-conditions-cel). #### Ajouter une condition de rôle sur des valeurs de données spécifiques :::info Cette section concerne une condition JSON historique. Les conditions JSON sont actuellement obsolètes et seront migrées automatiquement vers les nouvelles [conditions CEL](#nouvelles-conditions-cel). ::: Pour restreindre l'accès à des valeurs de données spécifiques dans votre application ou votre API, vous devez utiliser le paramètre _**filter**_ sur une permission liée à l'_**API**_. Créez d'abord un rôle ayant accès à `API * *` : ![Ajouter une condition de rôle sur des valeurs de données spécifiques — New roleenduser](/images/public-cloud/data-platform/product/iam/users/picts/new_roleenduser.png) Ensuite, [attribuez](#attribuer-un-rôle-à-un-utilisateur-un-compte-de-service-ou-un-groupe) ce rôle au groupe/utilisateur de votre choix, et ajoutez une **condition de rôle**. ![Ajouter une condition de rôle sur des valeurs de données spécifiques — Acl data1](/images/public-cloud/data-platform/product/iam/users/picts/acl-data1.png) Définissez la condition avec le paramètre _filter_ sur l'attribution. Le paramètre _filter_ prend un dictionnaire de noms d'attributs et une liste de valeurs pour chaque attribut. ![Ajouter une condition de rôle sur des valeurs de données spécifiques — Acl data](/images/public-cloud/data-platform/product/iam/users/picts/acl-data.png) ```json { "filter": { "station_id": [ 40010 ] } } ``` Vous pouvez saisir plusieurs valeurs dans le _filter_, pour filtrer sur plusieurs attributs à la fois (opérateur AND) ou sur plusieurs valeurs d'un attribut (opérateur OR). #### Ajouter une condition de rôle sur un bucket spécifique :::info Cette section concerne une condition JSON historique. Les conditions JSON sont actuellement obsolètes et seront migrées automatiquement vers les nouvelles [conditions CEL](#nouvelles-conditions-cel). ::: Pour restreindre l'accès à des buckets spécifiques dans votre [Lakehouse Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-buckets.md), vous devez utiliser le paramètre _**bucket\_name**_ sur une permission liée au _**Data store**_. :::info Data Store est le nom d'origine des buckets sur Data Platform. ::: Créez d'abord un rôle ayant accès à `datastore * *`. Ensuite, [attribuez](#attribuer-un-rôle-à-un-utilisateur-un-compte-de-service-ou-un-groupe) ce rôle au groupe/utilisateur de votre choix, et ajoutez une **condition de rôle** avec le paramètre _bucket\_name_ sur l'attribution. ![Ajouter une condition de rôle sur un bucket spécifique — Acl bucket2](/images/public-cloud/data-platform/product/iam/users/picts/acl-bucket2.png) ```json { "bucket_name": "mybucket" } ``` ## Aller plus loin Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le [canal Discord](https://discord.gg/ovhcloud) dédié. Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre [centre d'aide](https://help.ovhcloud.com/csm?id=csm_get_help). Rejoignez notre [communauté d'utilisateurs](https://community.ovhcloud.com/).