Dans mon précédent billet de blog, j’ai présenté les risques d’usurpation d’identité des Service Principals Azure dans les plateformes d’automatisation comme Azure DevOps.
L’une de mes recommandations était de séparer les Service Principals applicatifs des Service Principals d’IaC.
Les Service Principals d’IaC doivent avoir des privilèges élevés permettant de gérer des ressources dans Azure. L’utilisation de ceux-ci doit donc être limitée uniquement aux équipes d’infrastructures qui, en théorie, devraient avoir les mêmes privilèges dans Azure pour gérer les ressources.
Les Service Principals de déploiement applicatifs, quant à eux, devraient avoir uniquement les privilèges permettant d’écrire les fichiers des artefacts générés dans le service d’exécution applicatif : App Service, Azure Functions, etc. Ce service principal est accessible à un large panel d’utilisateur qui ont besoin simplement de déployer du code et rien d’autre.
Je souhaiterais partager avec vous ici le rôle Custom que j’utilise dans mes travaux pour attribuer les permissions permettant de déployer du code dans Azure App Service, Azure Functions, Azure Static Web Apps et Azure Storage Account aux Service Principals.
Ci-dessous la définition JSON du rôle :
{
"id": "/s",
"properties": {
"roleName": "Custom-Deploy",
"description": "",
"assignableScopes": [
""
],
"permissions": [
{
"actions": [
"Microsoft.Web/*/read",
"Microsoft.Web/sites/config/*",
"Microsoft.Web/sites/publishxml/action",
"Microsoft.Web/sites/publish/Action",
"Microsoft.Web/sites/slots/config/*",
"Microsoft.Web/sites/slots/publishxml/Action",
"Microsoft.Web/sites/slots/publish/Action",
"Microsoft.Storage/storageAccounts/blobServices/containers/*",
"Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
]
}
}
Ci-dessous le script Bicep du rôle :
resource roleDefn 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
name: guid('Custom Deployment Operator Role')
properties: {
roleName: 'Custom Deployment Operator Role'
description: 'Role for custom deployment operator'
permissions: [
{
actions: [
'Microsoft.Web/*/read'
'Microsoft.Web/sites/config/*'
'Microsoft.Web/sites/publishxml/action'
'Microsoft.Web/sites/publish/Action'
'Microsoft.Web/sites/slots/config/*'
'Microsoft.Web/sites/slots/publishxml/Action'
'Microsoft.Web/sites/slots/publish/Action'
'Microsoft.Web/sites/stop/Action'
'Microsoft.Web/sites/restart/Action'
'Microsoft.Web/sites/start/Action'
'Microsoft.Web/sites/slotsswap/Action'
'Microsoft.Web/sites/slots/start/Action'
'Microsoft.Web/sites/slots/stop/Action'
'Microsoft.Web/sites/slots/slotsswap/Action'
'Microsoft.Web/sites/slots/restart/Action'
'Microsoft.Web/serverfarms/restartSites/Action'
]
notActions: []
dataActions: [ ]
}
]
assignableScopes: [
'/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
]
}
}
Une fois le rôle créé, vous devez avoir quelque chose de similaire à ceci :
Il ne vous reste plus qu’à l’attribuer à vos comptes de services. En dehors de déployer du code, le Service Principal ne sera en mesure de faire rien d’autre.
Je vous laisse en faire bon usage dans vos travaux.