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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

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.