A quoi ça sert de locker ses ressources dans Azure?

La notion de Lock existe depuis un certain temps, pourtant, c’est en voyant sa disponibilité dans le portail Azure que je me suis dit que ce serait intéressant d’écrire un billet sur le sujet. Globalement, l’idée est de pouvoir verrouiller des ressources, un ensemble de ressources (groupe de ressources) ou même carrément une souscription de manière à ce qu’aucune opération de modification ne puisse être réalisée tant que le lock est présent. Pendant un déploiement, cela a du sens (éviter les conflits entre plusieurs opérations menées en parallèle). Pour moi, cela permet aussi d’éviter les erreurs fatales ou le scénario « Dédé fait du Cloud Computing ».

Imaginons un scénario dans lequel notre système d’information a basculé dans le cloud, que nous sommes capables de travailler en déploiement continu, un monde presque parfait. Avec les templates ARM, on est sur une approche d’intégration continue, on modifie son template, on teste son déploiement pour valider qu’il fonctionne puis on recommence. Pour cela, on a pris l’habitude de supprimer le groupe de ressources contenant nos ressources. C’est bien mais le problème, c’est qu’avec le temps se créé des dépendances invisibles. Dans l’organisation de notre souscription, il y a des ressources qui seront liées à la sécurité ou au réseau. Ce sont des ressources communes qui seront consommées dans d’autres groupes de ressources (quelle machine virtuelle n’a pas besoin de connectivité réseau ?). Supprimer et redéployer une machine virtuelle n’est pas risqué. Par contre si on supprime le groupe de ressources dédié aux ressources réseau, c’est beaucoup moins marrant. Imaginez qu’on réponde oui à la question suivante, juste par habitude de ne plus lire le message d’avertissement ?

clip_image001

C’est pour éviter ce type de scénario qu’on a inventé la fonctionnalité de verrouillage de ressources dans Azure. Si on a utilisé la fonctionnalité Lock, on aura la réponse suivante :

clip_image002

Si on clique sur le message, on sera amené à l’interface de gestion des locks. On découvre que même si j’ai tous les privilèges sur mon groupe de ressources (genre je suis le propriétaire), ben j’ai quand même un garde-fou qui va me rappeler que je vais peut-être faire une connerie.

clip_image003

Là, normalement « Dédé » (nous l’appelons Dédé pour ne pas dévoiler son identité) devrait se dire qu’il vient d’éviter de faire une superbe connerie. Des machines virtuelles sans connectivité réseau, ça perd quand même beaucoup de son intérêt. Si Dédé décide de s’acharner, et de passer en PowerShell, il y passera un peu de temps avant de comprendre la nature de son problème.

clip_image004

La fonctionnalité a quand même une limite. Si Dédé a les permissions suffisantes sur la ressource, le groupe de ressources ou la souscription, il peut supprimer le lock. Par contre, dans les logs, on aura la trace qu’il a délibérément décidé de se tirer une balle dans le pied. Le scénario « Dédé fait de l’Azure » est pour moi le meilleur cas d’usage du verrouillage de ressources.

Maintenant, voyons comment cela fonctionne et ce que propose le module PowerShell AzureRMresources :

Get-command -Module AzureRM.Resources -Name « *azurermresourcelock »

clip_image005

C’est donc assez simple. Vu que je viens de tenter de supprimer un groupe de ressources RGNetwork, on devrait trouver la trace de notre Lock avec Get-AzureRMResourceLock

clip_image006

Globalement, il est indiqué qu’il est interdit de supprimer le groupe de ressources. Le seul moyen de le supprimer, c’est de supprimer le verrouillage avant. Maintenant, voyons comment on a pu en arriver là en créant le lock avec la commande New-AzureRmResourceLock.

New-AzureRMResourceLock -ResourceGroupName « RGNetwork » -LockName « NetworkTeam » -LockNotes « Pense y deux fois avant de continuer, … » -Locklevel CanNotDelete -Force

clip_image007

Remarque : Aujourd’hui, on ne dispose que de deux types de Lock : Read-Only, CanNotDelete.

Après, on peut être plus fin et de verrouiller qu’une ressource particulière. D’un point de vue sécurité, la disparition de mon coffre-fort numérique contenant toutes mes clés et secrets serait plus que préjudiciable à notre ami Dédé.

 

Conclusion

Le Resource Locking est un bon moyen pour éviter les erreurs. Pour moi, une équipe qui ne verrouille aucune de ses ressources peut signifier plusieurs choses :

  • Elle n’a peur de rien, tout du moins jusqu’à ce que le pire survienne
  • Elle a évalué les risques et ce type de scénario ne surviendra jamais (jusqu’à ce que le facteur Dédé survienne)

Bref, pensez à Locker vos ressources, ça peut vous sauver la vie et le job de Dédé

­

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

Benoit

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

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.