Rôles et conditions

Objectif

Data Platform utilise une approche de contrôle d'accès basé sur les rôles 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.

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 du projet, généralement depuis une application. 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
• Analytics Consumer : généralement attribué aux utilisateurs qui exécuteront des analyses à l'aide d'un consumer externe. 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
• Dashboard Viewer : donne les permissions pour accéder à la version en lecture seule des dashboards dans l'Analytics Manager
• 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
• API & App Editor : donne un accès administrateur complet à toutes les API personnalisées et applications
• Control Center Editor : donne un accès administrateur complet à toutes les ressources du Control Center
• LM & AM Editor : donne un accès administrateur complet à toutes les ressources du Lakehouse Manager (à l'exception des Buckets) et de l'Analytics Manager
• DPE Editor : donne un accès administrateur complet à toutes les ressources du Data Processing Engine
• DataStore Editor : donne un accès administrateur complet à toutes les ressources des Buckets
• Identity Access Manager Editor : donne un accès administrateur complet à toutes les ressources de l'Identity Access Manager

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.

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.

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.)

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.

Enfin, cliquez sur Create pour enregistrer votre rôle.

Via l'API

# {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.

Cliquez sur Add dans l'encadré Role Conditions.

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).

Cliquez sur Create, puis sur Save.

Via l'API

# {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 à 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.

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 et les 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

Les conditions CEL sont exprimées à l'aide du Common Expression Language (CEL). 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.<key>) : applique une condition sur la valeur d'un policy tag attribué à la ressource. Remplacez <key> 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.<key>)) : 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.

• Conditions sur l'utilisateur/le compte de service : bientôt disponible !

Opérateurs de condition

Les conditions suivantes (c'est-à-dire les opérateurs de condition) sont actuellement disponibles dans l'Identity Access Manager.

• É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" :

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) :

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) :

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 :

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) :

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 :

Service == "adac" && (
  Resource == "dataset"
  || (!has(PolicyTags.sensitivity) && Resource == "table")
  || Resource == "attribute"
)

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) pour créer des conditions similaires.

Tutoriel : comment créer une condition de rôle sur un bucket spécifique

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.

Ajouter une condition de rôle sur des valeurs de données spécifiques

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 * * :

Ensuite, attribuez ce rôle au groupe/utilisateur de votre choix, et ajoutez une condition de rôle.

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.

{
  "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

Pour restreindre l'accès à des buckets spécifiques dans votre Lakehouse Manager, vous devez utiliser le paramètre bucket_name sur une permission liée au Data store.

Créez d'abord un rôle ayant accès à datastore * *.

Ensuite, attribuez 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.

{
  "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 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 dédié.

Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre centre d'aide.

Rejoignez notre communauté d'utilisateurs.