Microsoft.Authorization/roleAssignments/write est la permission d'accorder des rôles RBAC. Un principal qui la détient (via Owner, User Access Administrator ou un rôle personnalisé) peut s'attribuer, ou attribuer à un principal qu'il contrôle, un rôle supérieur à n'importe quel scope qu'il atteint : une ressource unique, un groupe de ressources, un abonnement ou un groupe d'administration entier.
Accorder Owner#
# subscription-wide Owner to yourself
az role assignment create --assignee <your-object-id> \
--role Owner --scope /subscriptions/<sub-id>
# or scope it to a resource group / single resource
az role assignment create --assignee <object-id> --role Contributor \
--scope /subscriptions/<sub>/resourceGroups/<rg>
Un principal de service que vous contrôlez est un bénéficiaire plus discret que votre propre utilisateur, et survit à la désactivation de l'utilisateur.
Notes d'exploitation#
- Le scope le plus élevé sur lequel vous pouvez écrire est ce qui compte :
roleAssignments/writeau niveau d'un groupe d'administration accorde jusqu'à chaque abonnement situé en dessous. - Owner inclut
roleAssignments/write; Contributor non, donc Contributor ne peut pas se donner Owner. Cette frontière explique pourquoi elevate-access et les rôles personnalisés comptent quand vous ne détenez que des droits de type Contributor. - Les attributions sont visibles dans l'Activity Log et le portail ; une attribution restreinte sur un groupe de ressources obscur attire moins l'attention qu'une attribution Owner à l'échelle de l'abonnement.
Outils#
- az cli (
az role assignment create). - MicroBurst (les modules de l'époque
Invoke-AzureRmWebAppsExfilénumèrent et abusent du RBAC). - BARK (
New-AzureRMRoleAssignment) : attribution scriptée depuis un token.