Archives par étiquette : Resource Group As a Service

Resource Group As a Service–Enfin l’heure de consommer les API

Après un billet d’introduction et quatre pour la mise en œuvre, il serait peut-être temps de conclure et d’exploiter les API mises à disposition. Pour rappel, notre seconde instance du service Azure Function propose les API suivantes :

 

Avant de pouvoir commencer à consommer, on doit préparer un peu le terrain pour Postman. Pour ceux qui ont suivi le billet Authentifiez vos Azure Function avec Azure AD, ils sauvent que c’est l’heure de la construction des paramètres. Commençons par mettre en place une clé pour Postman au niveau de notre application Azure AD. Ce sera notre secret à consommer depuis Postman.

clip_image001

 

Ensuite, récupérons l’identifiant unique de notre tenant Azure AD (Aka TenantID) avec la commande PowerShell suivante : Get-AzureADCurrentSessionInfo | Format-List

clip_image002

 

Prochaine étape avec l’identifiant unique de notre application Azure AD ainsi que l’URL de Callback pour le retour à Azure Function après authentification. Nous obtiendrons ces deux informations avec la commande PowerShell suivante : Get-AzureRMADApplication -DisplayNameStartWith resourcegroupasaservicepublicapi

clip_image003

 

Maintenant, c’est l’heure de consommer.

 

API Get-AuthorizedSubscriptions

Testons avec la première API : Get-AuthorizedSubscriptions depuis Postman. Pour chaque API, nous allons configurer la méthode d’authentification OAuth 2.0

clip_image005

 

Pour les paramètres, je vous renvoie vers le billet Authentifiez vos Azure Function avec Azure AD. Avec tout cela, on devrait être en mesure de demander un jeton en cliquant sur le bouton Get New Access Token.

clip_image006

 

Normalement, cela devrait nous rediriger vers une mire d’authentification Azure AD. Si tout se passe bien, Azure AD rendra la main à notre application Azure AD via la CallBack URL.

clip_image008

 

Après authentification, on devrait obtenir une interface comme illustré ci-dessous avec un Token que nous allons consommer avec le bouton « Use Token ».

clip_image009

 

Attention, le token obtenu est valable une heure. Passé ce délai, il faudra penser à un demander un nouveau. Si tout se passe bien, notre API Get-AzureAuthorizedSubscriptions devrait finir par nous répondre avec une liste de GUID qui sont en fait la liste des souscriptions qui me sont autorisés pour utiliser le service.

clip_image011

 

Derrière l’appel à l’API nous avons une Azure Function. On peut constater la trace de l’appel à la fonction

clip_image013

 

En fait, quand on regarde le contenu de la table AuthorizedCallers, on comprend que la fonction a récupéré l’identité de l’appelant et recherché si l’utilisateur était autorisé ou non.

clip_image015

 

Dans mon contexte, on comprend que mon compte est autorisé à demander la création de groupes de ressources dans deux souscriptions Azure.

API Get-AuthorizedEnvironments

Chaque utilisateur autorisé sur une souscription est associé à un ou plusieurs environnements. Au final, ce sera un tag sur le groupe de ressources qui sera créé. Côté API, elle attend un paramètre : un identifiant unique de souscription. Ça tombe bien, c’est justement ce que la précédente API nous avait retourné. L’API attend un paramètre nommé SubscriptionID.

clip_image017

 

La demande initiée, on doit pouvoir constater le traitement dans Azure Function. A la lecture des logs, on constate que l’appelant serait autorisé à utiliser une seule valeur pour le tag Environnement.

clip_image019

 

De retour dans Postman, on constate bien que l’appelant pourra uniquement demander la création de groupes de ressources tagués TESTS pour la souscription donnée. Toute demande de création pour un autre environnement sera automatiquement rejetée.

clip_image021

 

API Get-AzureAuthorizedRegions

Resource Group As a service permet de limiter les régions Azure pour la création des groupes de ressources. Quelque part, c’est un peu le rôle de Azure Policy me direz-vous ? Oui mais Azure Policy est intégré à ARM qui n’a aucune idée de qui réalise le déploiement. L’API Get-AzureAuthorizedRegions permet de répondre à cette problématique. Chaque utilisateur accrédité pour une souscription donné est limité à une liste de régions Azure donnée. Logiquement l’API attend un identifiant unique de souscription Azure pour répondre à la question. En retour, nous sommes informés des régions Azure dans lesquelles nous sommes autorisés à demander la création d’un groupe de ressource dans la souscription Azure indiquée en paramètre.

clip_image023

 

Côté Azure Function, on peut voir le déroulement de l’exécution.

clip_image025

 

API Get-AuthorizedCostCenters

Resource Group As a Service contribue à la maitrise des coûts. Chaque groupe de ressources qui sera créé se verra assigné un tag CostCenter. Chaque utilisateur autorisé pour une souscription donnée est associé à une liste de valeurs autorisées pour ce tag. Encore une fois, il faut préciser la souscription Azure pour laquelle on veut connaitre les valeurs du tag qui nous sont autorisées.

clip_image027

 

En retour, on obtient. On une liste des valeurs que l’on pourra utiliser pour demander la création de notre groupe de ressources.

 

API Request-ResourceGroup

On a enfin tous les paramètres pour demander la création d’un groupe de ressources. C’est le rôle de l’API Request-ResourceGroup. A ce niveau, on a un peu plus de monde dans la section Body. En fait, on retrouve beaucoup des informations que nous avons déjà abordées :

  • ResourceGroupName : Pas la peine d’expliquer
  • Region : La région Azure dans laquelle créer le groupe de ressources (doit être autorisée)
  • ProjectName : Tag optionnel
  • SubscriptionID : Pas la peine d’expliquer
  • Environment : Une des valeurs qui nous sont autorisées
  • Backup : Tag optionnel
  • CreatedOn : Tag optionnel
  • SLA : Tag optionnel

 

clip_image029

 

Il faut être un peu patient, entre l’authentification, la création du groupe de ressources et la mise en place des tags, ce n’est pas instantané mais 14 secondes, c’est pas cher payé quand on a toute une équipe de développeurs qui attend la création d’un groupe de ressources pour travailler (je ne parle même pas du TJM cumulé, …).

clip_image031

 

Le résultat

Au final, ce qui nous intéresse, c’est quand même le résultat. Jusqu’à maintenant, on est capable de déclencher la création d’un groupe de ressources dans une souscription Azure.

clip_image001[1]

 

En regardant d’un peu plus près, on retrouve même tous les tags demandés. Pour certains, il y a même eu interprétation (CreatedOn, Owner, …)

clip_image002[1]

 

Pourtant, il y a un truc qui manque, les permissions. C’est là ou Resource Group As a Service a besoin de nous. Si on ne lui dit rien sur ce sujet, il ne fera rien. Par contre, si on lui communique les bonnes indications dans la table AuthorizedIAMTemplateRole, ça changera du tout au tout. Le contenu attendu est le suivant :

  • PartitionKey : L’identifiant unique de votre souscription
  • RowKey : Guid unique au sein de la Partition Key
  • Azure AD Group : Groupe Azure AD qui sera utilisé pour assigner un rôle
  • Role : Nom du Rôle Builtin / custom à assigner au niveau du groupe de ressources
  • Environment : Valeur du tag Environnement

 

Chaque ligne dans la table AuthorizedIAMTemplateRole représente donc une assignation de rôle Builtin / custom pour un environnement donné et une souscription donnée.

C’est grâce à cela que Resource Group As a Service prend tout son intérêt. Les permissions positionnées sur le groupe de ressources dépendront de la valeur du tag Environnment utilisée par le demandeur. Ce qui manque, c’est quelques entrées dans une table Azure. Easy en quelques lignes de PowerShell :

$RGName = « <Groupe de ressources contenant le Storage Account contenant les tables> »

$storageAccountName = « <Nom du storage Account> »

$SubscriptionID = « <Azure Subscription ID> »

$AuthorizedIAMTemplateRoleTableName = « AuthorizedIAMTemplateRole »

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName $RGName -Name $storageAccountName

Import-Module -Name AzureRmStorageTable

$IAMTable = Get-AzureStorageTableTable -resourceGroup $RGName -tableName $AuthorizedIAMTemplateRoleTableName -storageAccountName $storageAccountName

Add-StorageTableRow -table $IAMTable -partitionKey $SubscriptionID -rowKey (new-guid).guid -property @{« AzureADGroup »= »GROUPE »; « Environment »= »TESTS »; »Role »= »Reader »}

clip_image003[1]

 

Si on recommence la création du groupe de ressources, on pourra alors constater qu’il y a bien un assignement de rôle qui a été réalisé pour le groupe Azure AD indiqué et le groupe de ressources nouvellement créé.

$AdGroup = Get-AzureADGroup -SearchString GROUPE

Get-AzureRMRoleAssignment -ObjectID $groupe.ObjectID

clip_image004

 

Maintenant Resource Group As a Service prend tout son sens.Si vous êtes arrivés jusque-là, c’est que votre implémentation manuelle de Resource Group As a Service est opérationnelle, félicitations. Pour les plus fainéants, la prochaine version sera 90% industrialisée et comprendra le déblocage de quelques features actuellement cachées.

 

Benoît – Simple and secure by design but business compliant.

Resource Group as a Service–Mise en place de l’API resourcegroupasaserviceinternalapi

C’est maintenant qu’on commence à rentrer dans les API. Pour commencer nous allons mettre en place l’instance Azure Function qui portera les API à usage interne. J’ai fait le choix d’utiliser le Hosting Plan « App Service Plan » pour des raisons de performance. Cela aura un coût mais mon instance App Service Plan sera disponible 24/24 avec une SKU Standard S1, c’est amplement suffisant. Ce choix permet de disposer d’un service de sauvegarde mais aussi de la fonctionnalité Scale Up. Les logs de cette instance d’Azure Function seront stockés dans le premier Storage account créé. C’est un choix de ma part car lorsqu’on va procéder au renouvellement des clés (primaires / secondaires), avoir trop de dépendances à corriger serait plus que risqué.

clip_image001

Par ce que je veux aller vite, nous allons uploader le contenu de l’API directement dans Azure Function. Pour cela, nous avons besoin d’un peu de FTP. Comme pour une simple WebApp, on peut activer la prise en charge de FTP/FTPS pour charger du contenu, voire même récupérer des logs. J’ai donc reconfiguré le FTP avec un compte et noté le mot de passe dans un coin.

clip_image002

Le contenu que nous allons importer est le fichier resourcegroupasaserviceinternalaip.zip disponible sur mon Github. Une fois récupéré, nous allons utiliser la fonctionnalité Zip Push Deployment pour uploader le contenu via FTP. Derrière, c’est du WebDeploy. Quelques lignes de PowerShell et zou, uploadé dans notre première instance d’Azure Function.

$username = « <Compte FTP> »

$password = « <Mot de passe FTP> »

$filePath = « <emplacement local du fichier resourcegroupasaserviceinternalapi.zip> »

$apiUrl = « « 

$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes((« {0}:{1} » -f $username, $password)))

$userAgent = « powershell/1.0 »

Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization=(« Basic {0} » -f $base64AuthInfo)} -UserAgent $userAgent -Method POST -InFile $filePath -ContentType « multipart/form-data »

clip_image003

Dans l’état actuel des choses, mon processus d’importation ne prend pas encore la configuration des Application Settings. En fait, c’est une bonne chose car il faut préserver la configuration déjà en place pour certaines variables essentielles comme AzureWebJobsDashboard ou AzureWebJobStorage). Nous devons juste ajouter les variables ci-dessous documentées ci-dessous :

Nom

Contenu

AuthorizationModuleExpirationPeriod 30
AuthorizationModuleKeyVault resourcegroupasaservice
AuthorizationModuleStorageAccountMasterKey AuthorizationModuleStorageAccountMasterKey
AuthorizationModuleStorageAccountName Resourcegroupasaservice3

 

La variable AuthorizationModuleExpirationPeriod est utilisée pour configurer la durée de vie de la clé du SAS Token qui sera générée par l’API Get-ValetKeyforAzureTableRead. La variable AuthorizationModuleKeyVault désigne le nom de l’instance du service KeyVault qui sera utilisée pour stocker les secrets consommés par les API. La variable AuthorizationModuleStorageAccountName désigne le nom du Storage account qui contient les Azure Tables de configuration. Enfin, la variable AuthorizationModuleStorageAccountMasterKey désigne le nom du secret référençant la clé primaire du stockage désigné par la variable AuthorizationModuleStorageAccountName.

En attendant une industrialisation avec un beau Template ARM, voilà quelques lignes de PowerShell pour configurer nos premières Application Settings. C’est encore artisanal, et donc perfectible.

$webapp = Get-AzureRmWebApp -ResourceGroupName ResourceGroupAsAService -Name resourcegroupasaserviceinternalapi

$AppSettings = @{}

$AppSettings = $webapp.SiteConfig.AppSettings

$hash = @{}

ForEach ($kvp in $AppSettings)

{

$hash[$kvp.Name] = $kvp.Value

}

$hash[‘AuthorizationModuleExpirationPeriod’] = « 30 »

$hash[‘AuthorizationModuleKeyVault’] = « resourcegroupasaservice »

$hash[‘AuthorizationModuleStorageAccountMasterKey’] = « AuthorizationModuleStorageAccountMasterKey »

$hash[‘AuthorizationModuleStorageAccountName’] = « resourcegroupasaservice3 »

Set-AzureRMWebApp -ResourceGroupName resourcegroupasaservice -AppServicePlan resourcegroupasaserviceinternalapi -Name resourcegroupasaserviceinternalapi -AppSettings $hash

clip_image004

Au sein de notre instance Azure Function, notre fonction va devoir accéder aux secrets contenus dans l’instance du service Key Vault dédié à la solution. Pour cela, nous allons utiliser la fonctionnalité Managed Service Identity. Une fois activée, il faut juste penser à ne pas oublier de cliquer sur le bouton Save.

clip_image005

A ce stade, notre application dispose d’une identité dans Azure AD ainsi que d’un Service Principal qui lui est associé. C’est celui-ci que nous allons référencer comme ayant les permissions de parcourir la liste des secrets et accéder à ceux-ci.

$ADDObject = Get-AzureADServicePrincipal | where {$_.displayname -eq « resourcegroupasaserviceinternalapi »}

$ADDObject

Set-AzureRmKeyVaultAccessPolicy -VaultName resourcegroupasaservice -ObjectId $ADDObject.ObjectID -PermissionsToSecrets Get, List

clip_image006

Pour valider que le tout fonctionne bien, nous pouvons appeler notre Azure Function à l’aide du bouton « Run » dans l’éditeur de code d’Azure Function. Normalement, on doit constater qu’un SAS Token nous a été retournée en résultat.

clip_image007

 

Par sécurité, nous devons restreindre l’accès à notre fonction en mettant en imposant l’utilisation d’une Function Key pour utiliser notre fonction et nous allons restreindre les verbes HTTP utilisables à POST uniquement.

clip_image008

Imposer l’utilisation d’une Function Key, c’est aussi en créer une comme illustré ci-dessous.

clip_image009

De retour dans l’éditeur de code de notre Azure Function, en cliquant sur le lien « Get Function URL », on peut retrouver les URL d’accès de notre fonction. Dans la zone de liste, j’ai sélectionné le nom de ma Function Key, ce qui me permet de récupérer l’URL complète.

A partir de maintenant, c’est en utilisant cette URL associée à cette Function Key qu’il sera possible d’appeler l’API Get-ValetKeyforAzureTableRead.

$url = « https://resourcegroupasaserviceinternalapi.azurewebsites.net/api/Get-ValetKeyforAzureTableRead?code=<FunctionKey> »

Invoke-RestMethod -Uri $Url -Method POST -ContentType ‘application/json’


clip_image011

 

En retour, nous avons un SAS Token consommable pour s’authentifier auprès de mon troisième Storage Account. Pour rappel, c’est lui qui contient les Azure Tables que nous avons mis en œuvre.

Voilà pour la mise en place de la première API. La démarche sera sensiblement la même pour la seconde instance d’Azure Function. On va juste ajouter la brique Azure AD pour l’authentification.

BenoîtS – Simple and Secure by Design but Business compliant

Resource Group As a service–Mise en place des Key Vaults

Le stockage, c’était facile. Maintenant, on va s’attarder sur la sécurité. Pour le développement de nos API, il n’était pas question de références des comptes / mot de passe ou clé d’accès à un Storage Account en clair. On va donc avoir recours au Service Key Vault. En fait, nous allons avoir plusieurs usages. Dans mes Design Principles, j’ai retenu le support de multiples souscriptions Azure et la contrainte des moindres privilèges. En stockant tous les secrets dans une même instance de Key Vault. Problème, les permissions ne sont pas positionnées individuellement sur chaque secret mais sur les secrets. Afin de segmenter les informations, la solution implémente deux types de KeyVault

  • Le KeyVault nécessaire au stockage des secrets utilisés par l’API
  • Les KeyVault mis en œuvre pour stocker les secrets d’accès d’une souscription Azure

 

Commençons par la mise en place de la première instance dédiée aux secrets de la solution :

New-AzureRmKeyVault -Name resourcegroupasaservice -ResourceGroupName resourcegroupasaservice -Location « West Europe » -Sku Standard

clip_image001

 

Note : La commande PowerShell New-AzureRmKeyVault nous rappelle que contrairement au portail Azure, elle ne positionne pas d’Access Policy pour l’instance de KeyVault nouvellement créée. Nous devons donc configurer notre compte pour disposer des permissions sur les secrets qui seront stockés :

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘resourcegroupasaservice’ -UserPrincipalName ‘<Votre compte>’ -PermissionsToKeys create, import, delete, list -PermissionsToSecrets set, delete

clip_image002

 

On reviendra plus tard sur les permissions d’accès au secret pour cette instance de Key Vault. Pour l’instant, on va positionner notre premier secret, à savoir la clé primaire du Storage Account que nous avions configuré dans le billet précédent pour le stockage de nos Azure Tables. Les identités qui pourront accéder aux secrets pourront donc accéder aux Azure Tables de la solution.

$Secret = ConvertTo-SecureString -String $Keys[0].value -AsPlainText -Force

Set-AzureKeyVaultSecret -VaultName ‘resourcegroupasaservice’ -Name ‘AuthorizationModuleStorageAccountMasterKey’ -SecretValue $Secret

clip_image003

 

J’avais indiqué que nous avions plusieurs usages du service Key Vault. Le second usage, c’est pour stocker les credentials d’accès aux souscriptions dans lesquelles la solution va créer (Dans cette première version, c’est un compte Azure AD. Dans la prochaine, il est déjà prévu de supporter les Services Principals avec certificats). Nous avons déjà vu que les permissions se positionnent sur les secrets et non sur un secret donné. Pour cette raison, j’ai retenu de créer autant d’instances de Key Vault que de souscriptions qui seront configurées pour la solution. Dans la table AuthorizedCallers, nous avons référencé la souscription courante. Ce dont l’API a besoin maintenant, c’est d’une instance de KeyVault pour stocker les secrets nécessaires à l’accès à cette souscription. Les secrets contenus dans cette instance de KeyVault seront accessibles à :

  • Nous même
  • L’application Azure AD qui représente l’instance Azure Function portant nos API publiques (celles pour lesquelles une authentification Azure AD est exigée).

Etant donné que les noms des instances de Key Vault sont publics dans l’espace de nom « vault.azure.net », j’ai pris la précaution de générer des noms aléatoires sur la base de la chaine de caractères « mysecrets ».

$KeyVaultName = « mysecrets » + (get-random -Minimum 1 -Maximum 9999)

New-AzureRmKeyVault -Name $KeyVaultName -ResourceGroupName $resourcegroupname -Location $location -Sku Standard

clip_image004

 

Vu que c’est notre souscription, nous allons donc positionner des permissions nous permettant de gérer les secrets pour cette instance de Key Vault. Ce sont nos secrets, nous en sommes responsables.

Set-AzureRmKeyVaultAccessPolicy -VaultName $KeyVaultName -UserPrincipalName « <nom compte Azure AD> » -PermissionsToKeys create, import, delete, list -PermissionsToSecrets set, delete, List, Get

clip_image005

 

Nous reviendrons ultérieurement sur cette seconde instance de Key Vault. Avant de poursuivre, il nous faudra mettre en œuvre nos Azure Function et leur accorder la possibilité de consulter les secrets mis à disposition dans les instances de Key Vault. Ce sera pour le prochain billet.

 

BenoîtS – Simple and Secure by Design but Business compliant

Resource Group As a service – Mise en place du stockage

Après, un précédent billet pour poser les bases, il est temps de poser les fondations pour nos API. Première brique, un Resource Group. L’intégralité des ressources Azure sont stockées dans un groupe de ressources : New-AzureRMResourceGroup -ResourceGroupName ResourceGroupAsAService -Location « West Europe »

clip_image001

 

Côté stockage, j’ai identifié trois usages. Etant donné que nous allons avoir deux instances du service Azure Function, nous avons déjà deux instances de Storage Account. Techniquement, on peut très bien mutualiser mais je préfère isoler. Cela ne change rien au niveau de la facturation. La dernière instance, sera destinée à stocker les données utilisées par les API (Azure Table). La nature de ces données étant relativement sensibles, j’ai volontairement retenu une instance dédiée. Ci-dessous la commande PowerShell pour créer la première instance du Storage Account :

New-AzureRmStorageAccount -ResourceGroupName resourcegroupasaservice -AccountName resourcegroupasaservice1 -Location « West Europe » -SKUName « Standard_LRS » -Kind StorageV2 -EnableHttpsTrafficOnly $True

clip_image002

 

Puis la seconde instance : New-AzureRmStorageAccount -ResourceGroupName resourcegroupasaservice -AccountName resourcegroupasaservice2 -Location « West Europe » -SKUName « Standard_LRS » -Kind StorageV2 -EnableHttpsTrafficOnly $True

clip_image003

 

Et enfin la troisième instance : New-AzureRmStorageAccount -ResourceGroupName resourcegroupasaservice -AccountName resourcegroupasaservice3 -Location « West Europe » -SKUName « Standard_LRS » -Kind StorageV2 -EnableHttpsTrafficOnly $True

clip_image004

 

Nous allons passer un peu de temps avec cette troisième instance puisqu’elle va contenir des Azure tables qui vont être utilisées par les API. Commençons par récupérer les clés de cette instance de Storage Account : $keys = Get-AzureRmStorageAccountKey -ResourceGroupName resourcegroupasaservice -Name resourcegroupasaservice3

$keys

clip_image005

 

Nous allons utiliser la première clé pour nous créer un contexte pour créer les Azure tables suivantes :

  • AuthorizedCallers
  • AuthorizedEnvironments
  • AuthorizedIAMTemplates
  • DefaultCostCenter

 

$context = New-AzureStorageContext -StorageAccountName resourcegroupasaservice3 -StorageAccountKey $keys[0].value

« AuthorizedCallers AuthorizedEnvironments AuthorizedIAMTemplateRole AuthorizedPolicyAssignment DefaultCostCenter ».Split() | new-AzureStorageTable -Context $context

clip_image006

 

Avoir des tables c’est bien mais on a aussi besoin d’un peu de contenu. Pour cela, nous allons faire appel au module PowerShell AzureRmStorageTable disponible sur la PowerShell Gallery. Commençons par poser quelques bases :

Install-Module -Name AzureRmStorageTable

$resourcegroupname = « resourcegroupasaservice »

$Storageaccountname = « resourcegroupasaservice3 »

$location = « West Europe »

clip_image007

 

Jusqu’ici rien de bien sorcier. Mes tables sont localisées dans le groupe de ressources resourcegroupasaservice3, lui-même dépendant du Storage Account resourcegroupasaservice. Continuons avec l’alimentation de la première table Authorizedcallers. Celle-ci permet aux API de déterminer :

  • Si l’utilisateur est accrédité à utiliser le service ou non pour une souscription Azure donnée
  • La liste des valeurs acceptées pour le tag CostCenter qui sera associé au groupe de ressources à créer en fonction du demandeur
  • La liste des valeurs acceptées pour le tag Environnment qui sera associé au groupe de ressources à créer en fonction du demandeur
  • La liste des régions azure autorisées pour la création du groupe de ressources en fonction du demandeur

 

$table = Get-AzureStorageTableTable -resourceGroup $resourceGroupname -tableName « Authorizedcallers » -storageAccountName $Storageaccountname

$partitionkey = (Get-AzureRmContext).Subscription.ID

$rowkey = ‘Simplebydesign@bsautierehotmail.onmicrosoft.com’

Add-StorageTableRow -table $table -partitionKey $partitionKey -rowKey $rowkey -property @{« Authorized »= »true »; »AuthorizedCostCenters »= »ITDEPT,FINANCEDEPT »; »AuthorizedDefaultRegion »= »WestEurope »;

« AuthorizedEnvironments »= »TESTS »; »AuthorizedRegions »= »WestEurope,NorthEurope »}

clip_image008

 

L’utilisateur indiqué est déclaré autorisé à demander la création d’un groupe de ressources dans la souscription courante avec des valeurs prédéfinies pour les tags CostCenter et Environment. Voilà le mécanisme d’autorisation.

Passons à la table AuthorizedEnvironments. Lors de l’appel à l’API Request-ResourceGroup, l’appelant peut préciser quelle valeur associer au tag Environnement (dans la liste des valeurs autorisées). Si l’appelant ne précise aucun environnement en particulier, alors, l’API va consulter cette table pour déterminer la valeur par défaut.

$table = Get-AzureStorageTableTable -resourceGroup $resourceGroupname -tableName « AuthorizedEnvironments » -storageAccountName $Storageaccountname

$partitionkey = (Get-AzureRmContext).Subscription.ID

$rowKey = « TESTS »

Add-StorageTableRow -table $table -partitionKey $partitionKey -rowKey $rowkey

clip_image009

 

Maintenant, si nous appelions l’API Request-ResourceGroup sans préciser de valeur pour le tag Environnement, la valeur par défaut retenue serait « TESTS ». Pour le tag CostCenter, c’est le même principe. Si l’appelant ne précise pas une des valeurs qui lui sont autorisées pour la création d’un groupe de ressources dans une souscription Azure donnée, alors, l’API ira chercher la valeur par défaut à utiliser dans la table DefaultCostCenter

$table = Get-AzureStorageTableTable -resourceGroup $resourceGroupname -tableName « DefaultCostCenter » -storageAccountName $Storageaccountname

$partitionkey = (Get-AzureRmContext).Subscription.ID

$rowkey = ‘Simplebydesign@bsautierehotmail.onmicrosoft.com’

Add-StorageTableRow -table $table -partitionKey $partitionKey -rowKey $rowkey -property @{« CostCenter »= »ITDEPT »}

clip_image010

 

Ceci clos la partie stockage. Prochaine étape, on s’attaque à la gestion des secrets dans la solution avec du KeyVault à tout va.

 

BenoîtS – Simple and Secure by Design but Business compliant

Resource Group as A service – Introduction

Lors de ma session sur la gouvernance Azure au Global Azure Bootcamp, j’avais fait la démonstration du premier prototype de mon ensemble d’API « Resource Group as a Service ». Pour rappel, l’idée générale était de répondre à la problématique de la gouvernance Azure, en particulier au niveau des groupes de ressources. Le but de Resource Group as a service est de proposer un intermédiaire qui prend en charge la création et la configuration des Resources Groups pour le compte des demandeurs. Le développement a maintenant bien avancé (Pas encore une V1 mais au moins une Beta stable). Cette série de billets sera consacrée à cette API. Nous allons commencer par les Design Principles retenus pour ce développement.

Design Principles / contraintes imposées

  • Langage de développement : OK, c’est pas un vrai Design Principle. Normalement, le langage utilisé ne rentre pas en ligne de compte. Dans mon contexte, c’est plus ma contrainte imposée pour permettre un développement simple : PowerShell
  • Support de nos API : Azure Function. C’est mon choix. Pas la peine de mettre en œuvre une instance de Service Fabric pour porter quatre API. Pour rappel, une Azure Function a un temps d’exécution limité à 300 secondes, ce qui sera largement suffisant pour créer un groupe de Ressource. Ici aussi ce choix implique une contrainte car :

    • A ce jour le support de PowerShell en encore expérimental dans Azure Function
    • Le niveau de performance ne sera pas équivalent si on avait retenu C#
  • Authentification : Chaque appel à nos différentes API devront être authentifiés. Dans le contexte d’Azure Function, le choix le plus simple a été retenu avec la prise en charge de l’authentification via Azure AD. On reviendra sur ce choix ultérieurement car il aura quelques conséquences
  • Autorisation : L’authentification et l’autorisation sont deux choses bien distinctes. Ce n’est pas par ce qu’on va avoir accès aux API que tout nous sera autorisé. Dans mes Design Principles, j’ai retenu les points suivants :

    • Chaque utilisateur devra être enregistré comme autorisé pour pouvoir soumettre une demande de création de groupe de ressource
    • Le niveau d’autorisation sera individualisé au niveau de chaque souscription prise en charge par l’API
    • Le niveau d’autorisation prendra la notion de CostCenter au niveau de chaque souscription. Dans notre contexte, c’est un TAG positionné au niveau du groupe de ressources. Chaque utilisateur sera accrédité à un ou plusieurs codes d’imputation comptables qui sera associé au tag CostCenter
    • Le niveau d’autorisation prendra en compte la notion d’environnement au niveau de chaque souscription. Dans notre contexte, c’est un TAG positionné au niveau du groupe de ressources. Chaque utilisateur sera accrédité à demander la création d’un groupe de ressources avec une sélection de valeurs pour le TAG environnement.
    • Le niveau d’autorisation prendra en compte la notion de région pour limiter la création du groupe de ressources pour un ensemble de régions Azure donnée
  • Contexte d’exécution : Pour créer des ressources Azure, on a besoin d’une identité. Hors de question de coder des comptes / mots de passe ou même des clés d’accès au stockage. Choix a été fait d’utiliser la fonctionnalité Managed Identity Services pour nos Azure Function. Cela a quand même quelques implications :

    • Toutes les API regroupées dans une même instance du service Azure Function utiliseront donc la même identité
    • L’identité en question prendra la forme d’une application Azure AD et d’un Service Principal, lequel devra disposer des rôles nécessaires
  • Support de multiples souscriptions : Un contexte d’exécution propre à chaque souscription Azure sera nécessaire. Etant donné que ces multiples souscriptions peuvent ne pas utiliser le même tenant Azure AD comme fournisseur d’authentification, il ne sera pas possible d’utiliser l’identité des Azure Function (Managed Identity Services). Pour adresser cette problématique, il a été retenu que la solution associer un contexte d’exécution pour chaque souscription. Les secrets nécessaires pour chaque souscription seront stockés dans une instance distincte du service KeyVault. Cette séparation des secrets permettra de proposer aux gestionnaires des souscriptions de mettre à jour eux même le contexte de chaque souscription
  • Informer les consommateurs de leurs droits : Les principes retenus pour le mécanisme d’autorisation font que les consommateurs pourront disposer de privilèges bien différents selon les souscriptions. Afin de les informer des privilèges qui leurs sont associés, des API spécifiques seront proposées afin leur permettre de déterminer :

    • Les souscriptions auxquelles ils ont accès
    • Les tags Environnements qu’ils peuvent utiliser au sein d’une souscription Azure donnée
    • Les tags CostCenters qu’ils peuvent utiliser au sein d’une souscription Azure donnée
    • Les régions Azure qu’ils peuvent utiliser au sein d’une souscription Azure donnée
  • Stockage des données : Dans notre contexte, il a été retenu d’utiliser le service Azure Table pour gérer le mécanisme d’autorisation des API
  • Principe du moindre privilège : Principe essentiel pour le développement des API. A chaque fois que ce sera possible, le niveau d’accès de « moindre privilège » sera utilisé.

 

Ressource créée dans la souscription

  • Groupe de ressources : C’est quand même le but. Je n’ai pas encore prévu d’intégrer de contrôle sur le charte de nommage
  • Tags : Les groupes de ressources créé par l’API seront configurés avec un ensemble de Tags obligatoires et d’autres optionnels. Le notions d’environnements et de CostCenter sont eux obligatoires. L’utilisation de certains tags sera contrainte par les autorisations précisées dans les différentes tables Azure Table.
  • RBAC : Selon la configuration mise en place au niveau des Azure table, les groupes Azure AD seront positionnés avec des rôles builtin ou custom en fonction de la souscription Azure
  • Policies : Selon la configuration documentée dans les Azure Table, une ou plusieurs Azure policies seront positionnées en fonction de la souscription Azure.

 

Liste des API

Resource Group as A service, ce n’est pas qu’une seule API. En fait, c’est un peu plus compliqué que cela. Le tableau ci-dessous résume les API qui seront proposées via Azure Function :

Nom

Accès public

Méthode d’authentification

Managed Identity Service

Get-AuthorizedSubscription Oui Azure AD Activé
Get-AuthorisedEnvironments Oui Azure AD Activé
Get-AuthorizedCostCenters Oui Azure AD Activé
Get-AuthorizedRegions Oui Azure AD Activé
Request-ResourceGroup Oui Azure AD Activé
Get-ValetkeyForAzureTableRead Non Function Key Activé

 

Pour les quatre premières API, on comprend que c’est l’implémentation de la fonctionnalité permettant aux consommateurs de déterminer de quels privilèges ils disposent au sein des souscriptions prises en charge. Logiquement, ces APIs sont directement accessibles par les consommateurs pour peu qu’ils soient correctement authentifiés par Azure AD. Il en est de même pour l’API Request-ResourceGroup as a Service. Par contre, pour l’API Get-ValetkeyForAzureTableRead, la méthode d’authentification sera différente. Cette API sera utilisée pour respecter le principe du moindre privilège. Toutes les données relatives au mécanisme d’autorisation seront stockées dans des Azure Table au sein d’un Storage Account. La clé primaire de ce Storage Account sera bien stockée dans un Key Vault mais nous allons utiliser le Cloud Design Pattern Valet-Key pour générer un contexte d’accès limité à la permission Read sur les Azure Table, avec une durée de vie limitée.

clip_image001

 

Cette API ne sera pas consommée directement par les consommateurs mais en tant qu’API interne pour générer une clé d’accès au stockage. Il aurait été possible d’utiliser Azure AD comme méthode d’authentification (avec Managed Service Identity) mais cela introduisait un risque. Dès lors qu’un consommateur de l’API connait l’URL et se présente avec une identité Azure AD vérifiée, il aurait eu la possibilité de se générer des clés d’accès au stockage. Clairement une fausse bonne idée d’un point de vue sécurité. Pour cette raison, nous allons introduire une segmentation au niveau des API. Cette segmentation permet :

  • D’isoler une API qui donne accès à des informations sensible (il sera nécessaire de connaitre la Function Key qui sert de secret d’accès)
  • De distinguer les identités (Managed Identity Services) qui vont accéder aux instances de KeyVault et donc respecter le principe du moindre privilège

Quand on sait que toutes les API hébergées dans une même instance Azure Function partagent la même identité Managed Identity Service et la même méthode d’authentification, il apparait donc nécessaire d’introduire deux instances du service Azure Function pour héberger nos API.

  • Resourcegroupasaservicepublicapi
  • Resourcegroupasaserviceinternalapi

Voilà pour l’introduction. Dans le prochain billet, on va rentrer dans le dur du sujet.

 

BenoîtS – Simple and Secure by Design but Business compliant