Lors du développement d’un logiciel ou d’une application, des dizaines, voire des centaines d’utilisateurs interviennent. Mais tous n’ont pas les mêmes droits d’accès. Alors pour personnaliser l’accessibilité aux différentes ressources de Google Cloud Platform, il existe les GCP Custom.
Qu'est-ce-que GCP custom role ?
Les GCP custom roles correspondent aux rôles personnalisés sur IAM (Identity and Access Management).
GCP custom role sur IAM
Pour rappel, IAM est la plateforme de gestion des authentifications et des accès sur Google Cloud Platform. Plus précisément, elle définit qui (utilisateur) a accès à quoi (ressources) et comment (rôle).
- L’utilisateur : on parle également de compte principal. Il peut s’agir d’un compte Google, d’un compte de service, d’un groupe Google, d’un compte Google Workspace ou d’un domaine Cloud Identity. Chaque compte principal possède son propre identifiant (souvent une adresse e-mail).
- Les ressources cloud : ce sont les instances de machine virtuelle Compute Engine, les clusters Google Kubernetes Engine, les buckets Cloud Storage, les dossiers complets, les projets, etc.
- Le rôle : l’autorisation d’accès n’est pas accordée directement à l’utilisateur, mais passe par l’intermédiaire des rôles. Ces derniers sont alors attribués aux comptes principaux et regroupent un ensemble d’autorisations sur une ressource. Mais attention, il existe différents types de rôles.
Les différents types de rôles
L’outil Cloud IAM compte 3 types de rôles :
- Les rôles de base : ces derniers sont présents par défaut sur IAM. Il s’agit des rôles “Propriétaire”, “Éditeur” et “Lecteur”. Dès lors qu’ils sont attribués, ces derniers incluent des milliers d’autorisations sur les ressources GCP. Il est donc préférable de ne pas attribuer ce type de rôle.
- Les rôles prédéfinis : entièrement gérés par Google, ils permettent d’autoriser ou de refuser les accès aux ressources. Ainsi, lorsque de nouvelles fonctionnalités ou services sont ajoutés, les rôles prédéfinis se mettent automatiquement à jour.
- Les rôles personnalisés : ils sont définis par l’utilisateur lui-même. Cela permet d’adapter les conditions d’accessibilité en fonction des besoins spécifiques de l’organisation. Mais avec ces rôles personnalisés, il n’y a pas de mise à jour automatique après l’ajout d’une nouvelle fonctionnalité ou service.
- Les GCP custom roles de reposent sur le principe du moindre privilège. C’est-à-dire que les utilisateurs ne devraient pas avoir plus d’autorisations que nécessaire. Ainsi, lorsqu’un rôle prédéfini inclut une autorisation pour un ensemble de ressources, la création de GCP custom role permet de donner des droits d’accès pour une ressource bien spécifique et non pour l’ensemble.
Bon à savoir : bien souvent, ce sont les administrateurs système qui définissent eux-mêmes les rôles personnalisés en fonction des besoins des utilisateurs. Mais dans certains cas, ils peuvent aussi utiliser les recommandations de rôles (notamment si les attributions sont trop permissives). Dans un tel cas, ils recevront une recommandation de créer un rôle personnalisé.
Comment personnaliser les rôles sur GCP ?
Découvrez les différentes étapes pour créer un GCP custom role.
Obtenir les autorisations
Avant toute chose, il convient d’obtenir les autorisations pour gérer les rôles. À savoir modifier, lister, supprimer ou créer des rôles. Pour cela, vous devez obtenir le rôle d’« administrateur des rôles » (pour un projet) ou « administrateur des rôles de l’organisation » (à l’échelle de toute l’entreprise).
Afficher les autorisations disponibles
La gestion des GCP custom roles dépend de leur emplacement. Ainsi, si le rôle est situé au niveau de l’organisation, il ne sera pas possible d’inclure une autorisation dans un rôle personnalisé au niveau du projet.
C’est pourquoi, il est primordial de vérifier la liste des permissions disponibles avant toute création de rôles personnalisés. Pour les répertorier, vous pouvez utiliser la console de Google Cloud ou l’API Identity and Access Management.
Obtenir les métadonnées
Avant de créer un GCP custom role, vous aurez besoin de ses métadonnées. À savoir, le role ID et toutes les autorisations qu’il contient. Là encore, la console Google Cloud et l’API d’IAM vous permettent d’afficher ces métadonnées.
Créer un GCP custom role
La création de rôles se fait soit au niveau de l’organisation, soit au niveau du projet (jamais au niveau d’un dossier). Pour ces derniers, il est préférable de définir un rôle au niveau de l’organisation, puisqu’ils peuvent inclure toutes les autorisations compatibles avec les GCP custom role. Mais certains ne peuvent être utilisés qu’à l’échelle de l’organisation et non du projet. C’est par exemple le cas resourcemanager.organizations.get.
Ensuite, pour créer un rôle personnalisé, vous devez respecter les règles suivantes :
- 3 000 autorisations maximum ;
- 64 ko maximum pour la taille du titre, la description et les noms d’autorisations.
Si vous avez besoin d’attribuer plus d’autorisations, vous pouvez les répartir entre plusieurs custom roles sur GCP.
Pour créer un rôle personnalisé sur Identity and Access Management, vous pouvez utiliser la console de Google Cloud Platform, l’API d’IAM ou les différents langages de programmation (C++, C, Go, Java, Python).
Inclure une étape de lancement
Cette phase de lancement est optionnelle. L’idée est surtout de tester le rôle personnalisé avant de le déployer à grande échelle. C’est particulièrement important pour la fonction DISABLED qui implique une désactivation du GCP custom role.
Modifier un rôle personnalisé
Après création d’un GCP custom role, le plus simple est d’utiliser le modèle lecture-modification-écriture. Cela permet de mettre à jour les métadonnées d’une ressource (notamment les rôles). Mais attention, lorsque vous procédez à des modifications, veillez à ce que vous soyez le seul à le faire. En effet, si deux propriétaires utilisent le modèle lecture-modification-écriture simultanément, il peut y avoir des erreurs (échecs de modification).
Pour éviter ces conflits, n’hésitez pas à utiliser la propriété etag qui compare les valeurs de la requête avec la valeur etag existante.
Bon à savoir : certaines mises à jour n’apparaissent pas automatiquement, mais après un certain délai pouvant aller jusqu’à 24 heures. C’est par exemple le cas de l’ajout ou de la suppression des autorisations suivantes : resourcemanager.organizations.get, resourcemanager.folders.get ou resourcemanager.projects.get.
Maîtrisez les GCP custom role avec DataScientest
