Contributor Azure sur ma Sub et pourtant …

thierrybtblog

Niveau : ★★☆☆☆

Tout se passe bien, je suis contributor sur mon abonnement, et pourtant, je n’arrive pas à assigner ou à créer de définitions de stratégies (policy) sur mon abonnement. Voilà qui est étrange.

Pas de droit en write alors que je suis contributor ? Une belle erreur (très simple à comprendre) lorsque je valide l’assignement ou la création.

Ce qui manque ici, c’est bien le provider Microsoft.Authorization avec un niveau de droit de type Write.

Un petit tour du côté des RBAC pour bien comprendre une différence fondamentale entre 2 rôles de haut niveau, le contributor et le owner. Ici, c’est un json qui expose les RBAC pour un Owner. C’est on ne peut plus simple. Le bloc actions, c’est à dire la liste de ce qu’il est possible de faire est égale à * (en rouge). Le joker, c’est bien évidemment la totalité des droits. Ce qui se fait de plus fort en terme de compte sur les ressources Azure.

        "roleName": "Owner",
        "description": "Grants full access to manage all resources, including the ability to assign roles in Azure RBAC.",
        "assignableScopes": [
            "/"
        ],
        "permissions": [
            {
                "actions": [
                    "*"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Et

Mais ce que l’on voit aussi dans ce Json, c’est qu’il ‘y à rien de noté dans ce qu’il n’est pas possible de faire, les notActions, en vert.

Et c’est une (toute) petite différence avec ce que l’on trouve dans le Json d’un rôle de type Contributor. Si la liste des actions n’a pas bougé, celle des notActions est parfaitement claire. Et toute la partie Microsoft.Authorization est dans celle liste de notActions.

        "roleName": "Contributor",
        "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
        "assignableScopes": [
            "/"
        ],
        "permissions": [
            {
                "actions": [
                    "*"
                ],
                "notActions": [
                    "Microsoft.Authorization/*/Delete",
                    "Microsoft.Authorization/*/Write",
                    "Microsoft.Authorization/elevateAccess/Action",
                    "Microsoft.Blueprint/blueprintAssignments/write",
                    "Microsoft.Blueprint/blueprintAssignments/delete",
                    "Microsoft.Compute/galleries/share/action",
                    "Microsoft.Purview/consents/write",
                    "Microsoft.Purview/consents/delete"
                ],
                "dataActions": [],
                "notDataActions": []
            }

Voilà l’explication de ce message d’erreur. Un contributor a bien accès à toutes les ressources, sauf lorsqu’il s’agit de celles permettant une élévation de privilège. Et par extension, cette permettant de travailler les définitions et les assignements de policy Azure.

Deux remarques pour terminer ce très court sujet.

  • La règle pour les droits Microsoft a été pendant de très très longues années de dire que si l’on interdisait, c’est que l’on avait mal autorisé. Interdire était donc une mauvaise pratique, mais c’est maintenant terminé !
  • Ce qui amène à mieux comprendre le second point, la construction d’un JSON de RBAC. C’est un équilibre à trouver entre ce qui doit être explicitement autorisé et ce qui doit être explicitement interdit. Par exemple, si je reprends l’exemple d’un contributor, il y a deux manière de faire.
    • La première, c’est d’autoriser tous les types de ressources de manière explicite et de ne pas mettre dans cette liste d’autorisation le provider Microsoft.Authorization. C’est possible, cela évite d’interdire une ressource, mais dans ces cas là, le json du contributor devrait intégrer plusieurs milliers de lignes ! Voir à ce sujet la constitution des rôles RBAC sur la doc éditeur : https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/?WT.mc_id=AZ-MVP-5003759
    • La seconde, c’est le fonctionnement inverse. D’ouvrir les droits largement et d’interdire quelques ressources particulières. C’est dans le cas du contributor une manière beaucoup plus rapide et plus efficace pour donner le bon niveau d’autorisations.

Plus globalement, la meilleure méthode, c’est de consulter la doc en lien ci-dessus pour travailler les rôles. Et ne pas hésiter lors de la création de rôle Custom (un besoin qui ne serait pas couvert par les rôle Builtin du portail) à éplucher les Json des RBAC pour trouver la bonne solution.

Laisser un commentaire