GCP-2: Gestion des permissions 🎫
Objectifs:
🎯 comprendre la hiérarchie des ressources.
🎯 définir une stratégie de gestion des ressources.
Prérequis:
💡 [ GCP-1: Présentation ]
Comme vu dans le chapitre précédent [ GCP-1: Présentation ] le cloud permet pas mal d'avantages.
Cependant la gestion des ressources cloud et des accès à ces dernières peut vite être problématique.
Nous ne voulons pas de ressources orphelines qui coûtent à l'entreprise sans que l'on s'en rende compte ou nous ne voulons pas
que des utilisateurs aient accès à des ressources dont ils n'ont pas besoin pour leurs travaux.
C'est pour cela que la gestion des permissions dans le cloud est très importante,
la bonne pratique étant de donner tout juste les droits dont les utilisateurs ont besoin.
1) Hiérarchie des ressources
Lors de la première utilisation de GCP, vous serez amené à créer une organisation ou un projet.
Si vous avez créé une organisation vous pourrez dispatcher vos projets dans différents dossiers.
La finalité d'un projet étant la consommation de services GCP pour mener à bien ses développements, déploiement, monitoring & co.
L'entité au plus haut niveau est l'organisation tandis que les entités au plus bas niveau sont les ressources des services GCP
que l'on va utiliser. Pour avoir accès aux différents éléments présentés sur le schéma, des accès pourront être déclarés à tous les niveaux: organisation, dossiers, projets, ressources des services GCP.
Les permissions suivent cette hiérarchie et se propagent à travers les différentes entités.
En d'autres mots les permissions déclarées au niveau de l'organisation seront héritées dans les dossiers à moins qu'on ne surcharge les autorisations à ce niveau,
auquel cas les permissions déclarées au niveau dossiers seront héritées par les projets enfants de ces dossiers sauf s'il existe une surcharge des permissions au niveau du projet.
Ainsi de suite jusqu'au niveau le plus bas.
2) Déclaration des permissions
Les permissions/autorisations sont données aux différents niveaux de hiérarchie des ressources à des identités IAM
via des rôles prédéfinis ou des rôles personnalisés niveaux.
Le scope mentionné sur le schéma précédent fait référence aux ressources du premier schéma.
Les différents scopes possibles sont: organisation, dossiers, projets, ressources des services utilisés.
3) Identité
3.1) Group
Je fais un focus sur cette identité IAM parce que c'est celle que j'utilise pour attribuer des rôles à des utilisateurs ou
à des comptes de service. Cela permet une répartition des permissions en fonction du type d'utilisateurs que l'on a sur notre cloud.
Par exemple, supposons que j'ai une équipe en charge de maintenir le bon fonctionnement du cloud storage
(gestion des politiques de rétention des buckets, gestion du nommage des buckets et des livrables, etc...).
Dans ce cas je crée un groupe storage_adm, puis je lui attribue le rôle "Administrateur des objets Storage".
Le rôle "Administrateur des objets Storage" va donner les permissions nécessaires à mon groupe pour créer, supprimer, modifier les objets
du cloud storage dans le projet spécifié.
Dans un second temps j'ajoute mes administrateurs user_storage_adm1 et sa_storage_adm1. Le dernier
étant un compte de service qui sera utilisé dans des scripts admins pour la gestion des buckets.
De ce fait, si pour une quelconque raison j'ai besoin que les utilisateurs de mes projets considérés comme des
admins du cloud storage aient plus ou moins de permissions que ce que je leur ai accordé précédemment. Je n'ai pas à
mettre à jour les permissions individuellement mais je mets à jour celles du groupe.
3.2) Compte de service
Pour la sécurisation de l'accès au service account depuis une application il est possible de créer un workload identity.
Mais je ne vais pas rentrer dans les détails dans ce chapitre. Nous aurons le temps d'en discuter et d'en voir des cas pratiques
dans les chapitres suivants.
Conclusion:
L'utilisation de groupes pour segmenter les permissions à attribuer à ses utilisateurs et créer des comptes de service pour
les scripts dans lesquels vous aurez besoin d'utiliser des ressources GCP sont de bonnes pratiques.
Les ressources sont organisées selon une certaine hiérarchie et les permissions en découlent avec une notion d'hérédité.
Maintenant que nous savons comment quelle stratégie adopter pour gérer nos ressources nous pouvons en créer. Je vous invite à me rejoindre dans la rubrique suivante [ GCP-3: Automatisation administration cloud storage ].