Archives mensuelles : mai 2016

Plongée dans la mesure des usages dans Azure

Un sujet sur lequel je passe un peu de temps en ce moment. Lorsqu’on explique le Cloud, on rappelle toujours une de ses caractéristiques principales : c’est un service mesurable et donc facturable. C’est bien de le dire, encore faut-il pouvoir le prouver, dont acte.

On commence par les classiques avec l’authentification et la sélection de la souscription avec laquelle on désire travailler (jamais présupposer).

$Cred = Get-Credential

Login-AzureRMAccount -Credential $Cred

Select-AzureRmSubscription -SubscriptionName ‘Microsoft Partner Network’

clip_image001

Lorsqu’on creuse la liste des modules PowerShell, il y en a bien un a bien un qui nous intéresse : AzureRMUsageAggregates, lequel ne contient qu’une seule commande. (disponible depuis le module Azure PowerShell 0.9.4).

clip_image002

Donc, ce qu’il faut comprendre, c’est que la commande va nous permettre de faire un dump de tous les usages indépendamment des ressources dont in veut pouvoir mesurer les usages. Conclusion, il faudra affiner le résultat progressivement. Ça tombe bien, c’est le sujet de ce billet.  Pour réaliser le dump initial, en précisant une plage de date :

$startdate = « 01/01/2016 »

$enddate = « 16/05/2016 »

$Usage = Get-UsageAggregates -ReportedStartTime $startdate -ReportedEndTime $enddate -AgregationGranularity Daily -ShowDetails $True

$Usage | Get-Member

clip_image003

On récupère le tout dans la variable $Usage et on regarde ce qu’elle expose. Ce qui nous intéresse, c’est l’attribut UsageAggregations. Voyons quelques exemples, …

$Usage.UsageAggregations | Select -First 20

clip_image004

Visiblement, on a pas mal d’informations. Ce qui serait intéressant, ce serait de pouvoir faire le tri. Pour cela, explorons un peu la structure avec la commande suivante :

($Usage.UsageAggregations | Select -First 1).Properties

clip_image005

Ce qu’il faut comprendre, c’est qu’il y a eu quatre authentifications réalisées en ce premier jour de Janvier 2016. Maintenant, voyons cela à l’échelle de la période :

(($usage.UsageAggregations).properties | Where {$_.MeterName -eq « Users »}).count

clip_image006

OK, on ne peut pas dire que j’ai beaucoup bossé avec cette souscription depuis début janvier 2016. Mesurer l’usage des identités, ce n’est pas le plus intéressant. Le problème, c’est que nous avons pour le moment l’intégralité des mesures d’usages. On va commencer par filtrer uniquement un sous-ensemble qui nous intéresse. Avec l’arrivée d’ARM fin 2014, on pense tout de suite aux groupes de ressources. Voilà notre premier niveau de filtrage. Il faut juste filtrer avec l’attribut InstanceData comme illustré ci-dessous :

($usage.UsageAggregations).properties | Where {$_.instancedata -ne $null} | select -first 1

clip_image007

Lorsqu’on observe la structure, on comprend que cela inclus à la fois l’identifiant de la souscription mais aussi les ressources impliquées. Dans l’exemple ci-dessus, nous avons un groupe de ressources pour lequel il a été mesuré l’usage du service Azure Automation sur la période du 1er janvier 2016. Maintenant qu’on sait comment cela se présente, filtrer selon un groupe de ressources est assez simple :

$UsageRG = ($usage.UsageAggregations).properties | Where {$_.InstanceData -like ‘*resourceGroups/myresourcegroup*’}

$UsageRG.count

$UsageRG | Select -First 1

clip_image008

Plus que 257 entrées de mesure d’usages concernant uniquement mon groupe de ressources. Avec un peu de travail, on arrive à isoler les métriques des usages au sein de ce groupe de ressources :

$UsageRG | Select MeterName | Group-Object MeterName | Select Name

clip_image009

La liste des métriques de mesure d’usage devrait nous aider à comprendre de quoi on parle : Du trafic réseau, du compute du storage en mode page et des transactions, Vous avez deviné ? Oui, c’est bien les composants d’une machine virtuelle. On va se focaliser sur l’aspect stockage et plus particulièrement le nombre de transactions au sein de ce groupe de ressources :

$transactionUsage = $UsageRG | Where {$_.MeterName -like « *Storage Transaction* »}

$transactionUsage.count

$transactionUsage | Select -First 1

clip_image010

Cette mesure est intéressante car elle permet de répondre à une question intéressante : Combien de transaction ma machine virtuelle va-t-elle générer sur mon stockage ? C’est une métrique qui peut avoir une influence sur le coût de notre machine virtuelle.

Avec un peu de travail, on peut retrouver la mesure des usages pour les transactions IOPS réalisées pour la machine virtuelle associée au groupe de ressource pour notre période :

$transactionUsage | Select UsageStartTime,MeterName, Quantity | Out-GridView

clip_image011

Ca nous dit que notre machine virtuelle ne génère pas beaucoup de transactions. Dans un sens, c’est bien, c’est qu’elle ne va pas nous générer des coûts cachés. Est-ce de même pour les IOPS sur les VHD ?

$IOPSUsage = $UsageRG | Where {$_.MeterName -like « Standard IO – Page Blob/Disk (GB) »}

$IOPSUsage.count

$IOPSUsage | select -First 1

clip_image012

Voilà donc la volumétrie disque réalisée sur le/les VHD dépendant de mon groupe de ressources que ma machine virtuelle a utilisé, on va en extraire quelques statistiques :

$IOPSUsage | Measure-Object -Property Quantity -Average -Maximum -Minimum -sum

clip_image013

Remarque : Attention avec le stockage Premium, c’est une métrique distincte.

Autant dire tout de suite que cette machine virtuelle n’est que très peu utilisée, pas plus d’un tiers de Gb au maximum. Maintenant, on comprend l’intérêt de positionner des Tags sur nos ressources, cela simplifie grandement le filtrage de la mesure des usages.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’Azure Resource Policy

Depuis l’arrivée du modèle RBAC dans Azure, on est capable de maitriser ce qu’un utilisateur pouvait faire (et ne pas faire) dans une souscription au travers des rôles et Custom-Rôles. Oui, on peut maitriser ce qui est consommé. Par contre comment bloquer l’usage de certaines ressources sous conditions? Par exemple, comment empêcher le déploiement de ressources très couteuse, ou tout du moins mettre en place un processus pour encadrer ces usages au sein de nos souscriptions Azure?

La réponse est venue très récemment (15 avril 2016) avec l’arrivée de la fonctionnalité Azure Resource Policy. Au passage, je recommande la session Deploying, Managing, and Controlling Apps with Azure Resource Manager de la Build 2016 pour éclairer sur le sujet.

Avant de continuer, il faut comprendre une subtilité. Le modèle RBAC se focalise sur les actions qu’un utilisateur peut ou ne peut pas réaliser sur un périmètre donné, le tout au travers des groupes de ressources. Les Resources Policies ne concernent que les ressources, le périmètre peut être global ou limité à un groupe de ressources particulier.

Pour la mise en œuvre, il faut disposer d’une version récente du module AzureRM PowerShell (1.0 de mémoire) pour disposer des commandes suivantes :

clip_image001

 

Pour la suite, ça se complique un peu. Pour exprimer notre politique, nous devons nous exprimer au format JSON. A la base, une politique ressemble à cela :

{

« if » : {

<condition> | <logical operator>

},

« then » : {

« effect » : « deny | audit | append »

}

}

Définir une politique, c’est bien mais on peut être plus subtil que de simplement refuser. Techniquement, on peut :

  • Audit : Autoriser la demande de déploiement et se contenter d’une entrée dans le journal d’audit
  • Deny : Refuser la demande de déploiement et générer une entrée dans le journal d’audit
  • Append : Réaliser le déploiement en complétant celui-ci (exemple ajout de tags par défaut pour la refacturation)

 

 

Cela semble donc assez simple. La condition, c’est que nous voulons trapper lors du déploiement sur la plateforme Azure. Pour exemple, j’ai repris un exemple de la documentation officielle de Resource Manager Policy.

{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}

Je pense que c’est assez explicite pour comprendre ce qui va se passer si on tentait de déployer la moindre ressource sans aucun tag, … Traduisons cela en PowerShell :

$policy = New-AzureRmPolicyDefinition -Name AccountingCompliancePolicy -Description « Block any Azure deployment without accounting tag » -Policy ‘{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}’

$Policy

clip_image002

 

La politique a été acceptée. Avec la commande Get-AzureRMpolicyDefinition, on va retrouver notre politique mais aussi d’autres, …

Get-AzureRMPolicyDefinition | Select Name, Properties

clip_image003

 

C’est que par défaut, on a déjà quelques politiques. Celle-ci-dessous permet de s’assurer que nos ressources ne seront déployées que dans les régions européennes (North Europe et West Europe).

clip_image004

 

Mettre en place notre politique, c’est aussi définir un périmètre sur lequel nous voulons appliquer notre politique. On peut l’appliquer à toute la souscription si on veut mais pour les besoins de la démonstration, on va se limiter à un groupe de ressources particulier :

$AzureResourceGroup = Get-AzureRMResourceGroup -ResourceGroupName « ResourceManagerPolicy »

clip_image005

 

Nous avons tout ce qu’il nous faut. On a plus qu’à déclarer une nouvelle association de notre politique pour le groupe de ressources que nous venons de récupérer dans la variable $AzureResourceGroup

$policy = Get-AzureRmPolicyDefinition -Name ‘AccountingCompliancePolicy’

New-AzureRmPolicyAssignment -Name « AccountingCompliancePolicyAssignment » -PolicyDefinition $policy -Scope $AzureResourceGroup.ResourceId

clip_image006

 

Pour s’en convaincre, il n’y a qu’à tester un déploiement depuis le portail avec une simple machine virtuelle sans configurer aucun Tag. Le processus de validation ne nous remonte aucune erreur, logique, du point de vue JSON, le déploiement est conforme.

clip_image007

 

Par contre, on voit bien que par la suite, cela ne se passe pas bien. En consultant le détail, on voit bien qu’il y a eu plusieurs erreurs :

clip_image008

 

On peut consulter chaque erreur, on a la même cause. C’est bien un refus (c’était le but de notre politique). Dans la capture ci-dessous, c’est la création du Storage Account qui a échoué à cause de notre politique Resource Manager Policy :

clip_image009

 

Le nom de l’opération va nous être utile si on veut filtrer pour retrouver les logs en question.

get-azurermlog | where {$_.OperationName –eq « Microsoft.Authorization/policies/deny/action »} | select ResourceGroupName,OperationName, Category, status

clip_image010

 

Si on sait l’identifier, on peut y associer des alertes Ces alertes peuvent :

  • Envoyer un mail sur l’évènement (bof)
  • Déclencher un WebHook sur l’évènement qui va lui-même déclencher un Runbook Azure Automation

Pour finir quelques scénarios intéressants à creuser autour de cette nouvelle fonctionnalité :

  • Exiger la présence de tags / Enforcer la présence de tags dans les déploiements pour la refacturation
  • S’assurer que les ressources ne soient déployées que dans certaines régions
  • Limiter les Resources Providers utilisables
  • Bloquer l’utilisation de certaines fonctionnalités (géo-réplication du stockage par exemple)
  • Bloquer l’utilisation d’éditions particulières d’un Resource Provider (notion de SKU)
  • Imposer notre convention de nommage des objets

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)