Gestion des ressources Azure avec RBAC

1- Introduction

Au travers de cet article nous allons voir dans un premier temps comment l’accès aux ressources Azure est géré via l’utilisation de rôles, et comment cela rends flexible la gestion des ressources, et l’assignation de droits au niveau du portail.

Dans une deuxième partie,  nous aborderons la mise en place de rôle personnalisé permettant la mise en place de vos propres rôles au niveau de votre abonnement Microsoft Azure.

2- Avant RBAC c’était comment la gestion des ressources dans Azure?

Avant la première version du portail Azure il n’y avait pas moyen de pouvoir gérer les ressources de manière granulaire. En effet soit vous aviez accès à toutes les ressources liées à un abonnement soit vous n’aviez aucun accès. Cela rendait impossible la gestion des droits aux niveaux des ressources, si vous deviez par exemple gérer plusieurs projets avec délégation des accès pour différents groupes d’utilisateurs, vous n’aviez d’autres choix que de séparer ces différents projets dans différents abonnements ce qui est loin d’être l’idéal.

Avec la nouvelle version du portail Azure, il est maintenant possible de pouvoir gérer l’accès aux ressources de manière beaucoup plus granulaire avec l’apparition du concept de groupes de ressources, géré par Azure Resources Manager, et la mise en place de l’accès aux ressources via la définition de règles d’accès basées sur les rôles (RBAC).

L’accès aux ressources se fait via l’attribution de rôles aux différentes personnes auxquelles vous désirez donner accès à celles-ci.

Une bonne pratique est de mettre en place ces règles au niveau de groupes d’utilisateurs plutôt que de manière unitaire pour chaque utilisateur afin de faciliter la gestion de ces règles d’accès.

Via la nouvelle version du portail vous pouvez maintenant gérer les accès à différents niveaux :

  • Abonnement
  • Groupe de ressources
  • Ressource

Au niveau des rôles, il existe un grand nombre de rôles définis par Azure. 3 types s’appliquent à toutes les ressources que vous pouvez trouver dans la nouvelle version du portail. Ceux-ci sont :

  • Owner : Une personne ayant ce type de rôle, aura tous les droits sur la ressource, est pourra aussi délivrer des acccès à d’autres personnes au niveau de cet élément.
  • Contributor : Une personne ayant ce type de rôle, aura tous les droits sur la ressource mais ne pourra pas délivrer d’accès à d’autres personnes.
  • Reader : Une personne ayant ce type de rôle aura un accès en lecture seul sur la ressource, et ne pourra pas délivrer d’accès à d’autres personnes.

 

blog ai3 PortailRoles Gestion des ressources Azure avec RBAC

 

D’autres types de rôles existent suivant la ressources sur laquelle vous désirez délivrer des accès, et comme vous pouvez le voir leur nombre et assez important.

blog ai3 PortailRoles2 Gestion des ressources Azure avec RBAC

 

Les règles d’accès sont héritées d’un niveau à l’autre. Ce qui veut dire que les règles définies au niveau de l’abonnement (niveau le plus haut) seront héritées au niveaux des groupes de ressources. Et que les règles définies aux niveau des groupes de ressources seront héritées par toutes les ressources faisant partie de ces groupes de ressource. Vous pouvez bien sur casser cette héritage en définissant de nouvelles règles d’accès à un niveau plus bas.

Cependant, comme il y a toujours d’éternel insatisfait, il est possible que les rôles définis au niveau Azure ne vous conviennent pas, et que vous ayez donc besoin de définir vos propres rôles. cela tombe bien nous allons aborder le sujet dans la deuxième partie de cette article.

3- Définition et mise en place d’un nouveau rôle

Pour commencer, si vous n’avez jamais ouvert de console PowerShell passé votre chemin, pour les autres la suite devrait vous intéressée.

3.1- Mise en place du décor

Afin d’illustrer mon propos, je vous propose de mettre en place un rôle personnalisé pour la gestion d’une ressource de type Dev/Test Lab.

Faisant partie de la population des éternels insatisfaits, je n’ai pas trouver mon bonheur dans les rôles existants, et je voudrais mettre en place un rôle personnalisé respectant les prérequis suivant :

  • L’utilisateur doit pouvoir ajouter de nouvelle machine virtuelle au niveau du Labs.
  • L’utilisateur doit pouvoir voir la liste des templates de VMs disponibles, mais ne doit pas pouvoir ajouter ou supprimer de templates.
  • L’utilisateur doit pouvoir voir la liste des tailles de VMs disponibles au niveau du Labs, mais ne doit pas pouvoir ajouter ou supprimer de tailles.
  • L’utilisateur ne doit pas pouvoir modifier le nombre de machines virtuelles attribuées à son Labs.
  • L’utilisateur ne doit pas pouvoir modifier le nombre de machines virtuelles attibuées à chaque utilisateur au niveau de son Labs.

3.2- Après la théorie la pratique

Nous allons d’abord utiliser un commande PowerShell afin de voir l’ensemble des règles que nous pourrons définir afin de gérer les accès à un environnement de dev/test

Pour ce faire ouvrez une invite de commande PowerShell et entrer la ligne suivante :

Get-AzureRmProviderOperation -OperationSearchString « Microsoft.DevTestLab/* »

Au niveau du paramètre OperationSearchString il vous faudra mettre le nom de la ressource sur laquelle vous désirez lancer la commande.

Si vous ne connaissez pas le nom du provider, il vous suffit d’aller sur le portail Azure et de sélectionner la création d’un nouvelle élément….

Vous aurez ensuite accès au fichier de configuration JSON de la ressource , ou vous pourrez trouver le nom de la ressource en question.

blog ai3 ResourceManager Gestion des ressources Azure avec RBAC

Cette commande permet de voir toutes les opérations que nous pourrons prendre en compte lors de la définition de notre nouveau rôle

blog ai3 GetRessource Gestion des ressources Azure avec RBAC

Cette liste des actions disponibles au niveau des ressources vous permettra d’avoir une vue d’ensemble des différentes permissions que vous pourrez définir au niveau d’un rôle lors de la mise en place d’un rôle personnalisé.

Comme dit au début, le plus simple lors de la mise en place d’un nouveau rôle, le plus simple et de partir d’un rôle existant et de l’adapter à nos besoins. Dans le cadre de cet article nous partirons donc du rôle DevTest Labs User, que nous allons enrichir afin de pouvoir gérer les accès dans le but que ceux-ci répondent à nos exigences.

Pour se faire retourner à votre console PowerShell et entrer la ligne suivante :

Get-AzureRmRoleDefinition -Name « DevTest Labs User » | ConvertTo-Json | Out-File c:\temp\devTestLabsUser.json;

Cette commande permet dans un premier temps de récupérer la définition d’un rôle dont vous passez le nom en paramètre, et dans un second temps de sauvegarder cette définition au niveau d’un fichier au format JSON. Notre fichier étant copier nous allons pouvoir passer à la modification de celui-ci.

La première chose que nous allons faire et de donner un nom au nouveau rôle que nous allons mettre en place. Pour se faire un suffit de remplacer le contenu du paramètre Name au niveau de fichier de configuration, comme vous pouvez le voir au niveau de l’image ci-dessous. Pour ma part j’ai nommé mon rôle DevTest Admin User, mais libre à vous de le nommer comme bon vous semble.

blog ai3 Customise-Role-Name Gestion des ressources Azure avec RBAC

Ceci étant fait, il nous reste la partie la plus importante concernant l’attribution de droits à notre nouveau rôle. Pour ce faire le me suis appuyer sur la liste des actions possibles au niveau de la ressource DevTest Lab (via l’utilisation de la commande Get-AzureRmProviderOperation -OperationSearchString « Microsoft.DevTestLab/* »;) et j’ai fais mon marché. Voici les actions que j’ai rajouté au niveau de la définition de mon rôle.

  • Microsoft.DevTestLab/labs/virtualMachines/write
  • Microsoft.DevTestLab/labs/virtualMachines/read
  • Microsoft.DevTestLab/labs/virtualMachines/delete
  • Microsoft.DevTestLab/labs/galleryImages/read
  • Microsoft.DevTestLab/labs/schedules/write
  • Microsoft.DevTestLab/labs/schedules/Execute/action
  • Microsoft.DevTestLab/labs/schedules/read
  • Microsoft.DevTestLab/labs/schedules/delete
  • Microsoft.DevTestLab/labs/costs/RefreshData/action
  • Microsoft.DevTestLab/labs/costs/read
  • Microsoft.DevTestLab/labs/customImages/read
  • Microsoft.DevTestLab/labs/costInsights/RefreshData/action
  • Microsoft.DevTestLab/labs/costInsights/read
  • Microsoft.DevTestLab/labs/CreateEnvironment/action

Dans le but de connaitre la définition de chacune de ces entrées, je vous laisse lire le descriptif de chacune des actions que vous trouverez lors de l’exécution de la commande  : Get-AzureRmProviderOperation -OperationSearchString « Microsoft.DevTestLab/* »;

Afin de pouvoir ajouter ces actions, il vous suffit de vous rendre à la fin du tableau contenant les actions et de rajoutées celles définies précédemment (ou encore de télécharger le fichier tout finit ici).

Notre customisation des rôles ne pouvant s’effectuer de manière globale au niveau de Microsoft Azure, il vous faut récupérer l’Id de votre abonnement afin de le renseigner au niveau du fichier de configuration JSON de la but d’appliquer notre rôle uniquement au niveau de votre abonnement.

Pour se faire il vous suffit d’ouvrir le portail Azure et de sélectionné une ressource. Au niveau de l’URL vous aurez alors accès à l’Id de votre abonnement comme montré au niveau de l’image ci-dessous. Copier alors la partie suivante de l’URL : /subscriptions/<id abonnement>.

blog ai3 SubscriptionId Gestion des ressources Azure avec RBAC

Au niveau du fichier de configuration JSON, copier le contenu que vous venez de copier au niveau du paramètre  AssignableScopes comme montré au niveau de l’image ci-dessous.

blog ai3 SubscriptionId_Json Gestion des ressources Azure avec RBAC

Vous pouvez maintenant sauvegarder le contenu du fichier de configuration, il ne nous reste plus maintenant qu’à l’importer au niveau de l’abonnement Azure.

Pour ce faire, il vous suffit d’exécuter la commande PowerShell suivante :

New-AzureRmRoleDefinition -InputFile C:\Temp\devTestLabsUser.json

En passant en paramètre, comme vous l’aurez deviné, le chemin vers le fichier de configuration concernant la définition de votre nouveau rôle.

Si tout se passe bien vous devriez avoir un résultat se rapprochant de cela.

blog ai3 New-AzureRmRoleDefinition Gestion des ressources Azure avec RBAC

Nous allons maintenant voir si notre rôle respecte les règles que nous nous étions fixées auparavant.

Pour cela connectez vous au portail Azure, et rendez-vous sur une instance de type Dev/Test Lab.

Allez au niveau de la gestion des utilisateurs, et allez ensuite sur la partie concernant les rôles.

Première bonne nouvelle vous devriez voir apparaître le rôle que vous avez définit précédemment.

Essayez maintenant d’affecter ce nouveau type de rôle à un utilisateur, et ensuite déconnectez vous de portail, et reconnectez vous avec le compte pour lequel vous avez définit ce nouveau rôle.

Pour rappel notre nouveau rôle devais respecter les règles suivantes :

L’utilisateur doit pouvoir mettre en place de nouvelles machines virtuelles. Comme le montre l’image ci-dessous cette règle est respectée puisque l’utilisateur peut créer de nouvelles VMs.

blog ai3 AddVms Gestion des ressources Azure avec RBAC

L’utilisateur ne doit pas pouvoir modifier les templates de VMs définis par l’administrateur. Comme vous pouvez le voir l’utilisateur à bien accès à la liste des templates pouvant être utilisés au niveau de son environnement, mais il ne peut en aucun cas, ajouter ou supprimer des templates.

blog ai3 vmTemplates Gestion des ressources Azure avec RBAC

L’utilisateur ne doit pas pouvoir modifier les tailles de VMs définies par l’administrateur. Comme on peut le constater, l’utilisateur peut voir l’ensemble des tailles de machines virtuelles en niveau du Labs, mais il ne peut pas ajouter ou supprimer des tailles de Vms.

blog ai3 VmSize Gestion des ressources Azure avec RBAC

L’utilisateur ne peut pas modifier le nombre de machines Virtuelles affectées à son environnement.

blog ai3 NbVmEnv Gestion des ressources Azure avec RBAC

Et enfin, l’administrateur de l’environnement ne peut pas modifier le nombre de machines virtuelles maximales pouvant être attribuées à chaque utilisateur.

blog ai3 NbVmUser Gestion des ressources Azure avec RBAC

Notre nouveau rôle respectant toutes les règles, notre travail est maintenant terminé.

Voilà cet article touche à sa fin, le moment de nous quitter est arrivé.

A bientôt pour un nouveau sujet.

David Moïsa.

Cloud, security and Development in mind.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.