Cet article présente une bonne façon d’utiliser un secret dans une Logic App. En n’exposant pas ce secret directement dans le code, mais plutôt en allant le chercher dans un coffre de clefs, le service Azure Key Vault. Et même, dans la seconde partie de l’article, en utilisant une version encore améliorée de cette possibilité.
Récupérer un secret dans un Key Vault, c’est utiliser les services de façons modernes et c’est une bonne pratique. Elle doit s’accompagner de plusieurs recommandations :
Premièrement, utilisation d’une Managed Identity System pour donner accès au coffre. Une Managed Identity, c’est un compte Azure AD créé par et pour la Logic App. Cela permet de donner des droits RBAC sur le service Key Vault.
En plus de la possibilité de donner les droits, c’est également une gestion de compte lié au cycle de vie de la ressource. Le jour ou la Logic App est supprimée, son identité l’est également. Franchement, s’il y a bien un point ou il ne faut plus discuter, c’est celui là. Si le service peut porter une identité, il ne faut pas se priver.
Tous les services ne sont pas encore supportés, mais la liste est de plus en plus importante et ne cesse de s’allonger !
Seconde recommandation, activer dès que possible les accès RBAC pour les ressources. C’est une recommandation valable pour le Key Vault, mais également pour d’autres services comme les comptes de stockage. C’est même encore plus vrai pour un compte de stockage ou les clefs SAS / SAT peuvent se transférer et donner des droits importants et non contrôlés sur les données de compte. Je ne suis franchement pas FAN de ces identités que l’on peut se transférer de collègues à collègues.
Pour les Key Vault, cela se passe ici. Il faut noter que ce n’est pas cumulable, sélectionner Azure roel-based access control, c’est basculer dans ce mode d’authentification et ca ne permet plus d’utiliser les Access Policy.
Une fois cette option sélectionnée, c’est partie pour des RBAC et seulement des RBAC ! De la sécurité en + !!
Schématiquement, les accès sont donc donnés sous cette forme :
A noter que la granularité est importante, le rôle Key Vault Secrets User (Read secret contents. Only works for key vaults that use the ‘Azure role-based access control’ permission model) est le rôle le plus restrictif pour permettre à une Managed Identity de lire un secret (et uniquement un secret).
Ces quelques recommandations mises en œuvre, voici un premier test avec la préparation d’une Logic App qui va lire un secret dans le coffre et qui va récupérer ce secret. On voit dans les étapes suivantes que les accès sont effectivement obtenus par une MI (Managed Identity).
Après exécution, la valeur du secret est correctement récupérée et est visible à l’écran, tout fonctionne correctement. Ce secret peut être utilisé ensuite pour effectuer d’autres actions au travers de la Logic App.
Il existe une autre possibilité, moins connue, qui reprend exactement les mêmes étapes à l’exception des options du Get secret, étape 2 dans cet exemple. Dans les options du Get secret, il y a plusieurs possibilités et dans le cas qui nous intéresse un menu Settings. Et dans ce menu, deux options de sécurité, Secure Inputs et Secure Outputs.
Voilà qui est assez clair, on comprend facilement à quoi correspondent ces deux options.
Après activation de ces deux paramètres, on remarque que le résultat n’est plus exactement le même. La valeur est maintenant devenue « Hidden » et INPUTS et OUTPUTS affichent Content not shown due to security configuration.
Voilà des valeurs qui sont maintenant parfaitement sécurisées.
Attention toutefois, il y a quelques précautions à prendre avec ces INPUTS et OUTPUTS. Toutes les opérations intégrées de la Logic App ne prennent pas en charge l’ensemble des paramètres. Et cela donne parfois des résultats un peu étrange. Ci-dessous, la liste des entrées / sorties non compatibles.
Un peu de prudence par exemple avec les variables qui ne sécurisent l’affichage en sortie (mais Ok en entrée, même si le tableau dit le contraire) 😉
Une solution facile à mettre en œuvre et qui apporte tout de même un bon supplément de sécurité. A tester !
Il existe de très nombreux modules Powershell, certains très connus, d’autres moins. Et parmi cette seconde catégories de modules, le très utile (indispensable ?) Create-AzDiagPolicy.
C’est un peu le couteau suisse de la stratégie Azure en terme d’ajout de diagnostiques avancés sur les ressources.
Un peu de contexte avant de présenter cet outil.
Le diag, c’est la capacité à attacher un niveau de logs supplémentaires à des composants, des ressources Azure. Ce que l’on retrouve sur une majorité de ressources comme par exemple un coffre de sauvegardes Azure (Azure Recovery Vault) ou une base de données SQL.
Diagnostic setting pour un Recovery Services VaultDiagnostic setting pour une base de données
Par défaut, ces logs avancés ne sont pas directement activés sur les ressources. C’est une option complémentaire, mais plutôt une bonne pratique sur des environnements un peu sensibles comme par exemple tout ce qui concerne les ressources déployées en production.
L’ajout de ces logs peut être granulaire en ajoutant certaines valeurs directement dans le menu de sélection pour chaque ressource.
Sélection granulaire pour quelques logs
Les logs sélectionnés sont ensuite envoyés dans l’une des 4 destinations. Le workspace analytics, un compte de stockage, un event hub ou à un partenaire. C’est même un choix qui peut être fait pour l’envoi sur une ou plusieurs de ces destinations.
Petit remarque avant de passer à la suite, la sélection allLogs en haut du menu permettra lors des évolutions des paramètres de logs d’ajouter ou de retirer dynamiquement les nouveaux compteurs.
Définition dynamique
Il faut donc pour ajouter logs (et metrics) réaliser les opérations et le faire préférablement depuis des Azure Policy. C’est un élément central de la gouvernance, il ne faut pas se priver.
Il y a 3 solutions différentes pour le faire :
Par l’attachement de policy existantes.
Par l’attachement d’initiative (un regroupement de policy)
Par l’attachement de policy créées spécifiquement pour cet usage.
Première solution, attacher unitairement une policy dédiée que l’on trouve dans la catégorie Monitoring avec une recherche sur tout ce qui contient logging.
Policy de type Monitoring
Première de la liste, Enable logging by category group for Log Analytics workspaces (microsoft.operationalinsights/workspaces) to Storage qui doit être attachée sur le scope choisi (Management groups, Subscription ou Resources groups), et cette opération est à répéter pour chaque type de ressources. Efficace, mais un peu long.
Seconde solution, choisir une initiative plutôt qu’une policy unitaire. Cela permet de gagner pas mal de temps. Il existe 3 initiatives différentes qui contiennent chacune 33 policy. Seule différence, la destination des logs.
3 mêmes initiatives, mais 3 destinations.
Une nouvelle fois, c’est efficace, moins long, mais …
Une remarque, il y a un manque dans la liste des ressources. Seules 33 d’entre elles sont présentes, ce qui n’est pas exhaustif.
Impossible par exemple de trouver dans cette liste de type Builtin la ressource Data factories. Si vous êtes utilisatrices / utilisateurs des policy Azure, la première chose qui vient à l’esprit, c’est :
Pas de souci, je vais créer mes propres policy (custom) pour venir combler ce manque !
Et c’est effectivement la bonne solution et le bon réflexe. Mais c’est tout de même assez long. Pour résumer, c’est la récupération d’un Json de Policy qui existe déjà, puis l’écriture d’une règle pour identifier les ressources, puis identifier la sous-ressource diag, puis ..Etc. Rien d’insurmontable, mais quand même pas mal de chose à faire.
Une fois installé sur la machine, c’est du bonheur.
On se rend dans le répertoire du script, on créé un répertoire pour accueillir le retour du script et on appelle le script Create-AzDiagPolicy avec quelques paramètres, comme le répertoire de destination (ce que va récupérer le script) et le type de destination souhaitée côté Azure, pour mon exemple, Log Analytic (le param -ExportLA).
Et on obtient en retour un scan de sa subscription avec une proposition de création automatique d’une définition de policy pour toutes les ressources présentes sur la subscription. Et ça, c’est déjà un très bon point et c’est un vrai + de ce script.
28 types de ressources
Reste à sélectionner ce que l’on souhaite, dans mon cas, 29 All, pour obtenir 28 répertoires avec dans chaque répertoire 3 Json.
Création automatique des Json3 Json, c’est absolument tout ce dont nous avons besoin !
3 Json, c’est ce qu’il nous faut pour :
Copier / coller le contenu du fichier azurepolicy.json dans le portail Azure lorsque l’on utilise cette méthode pour créér une nouvelle définition depuis l’interface graphique.
Ou créer une définition As Code à l’aide d’une commande Powershell (qui va utiliser le fichier azurepolicy.rules.json pour les règles et azurepolicy.parameters.json pour les paramètres).
New-AzPolicyDefinition -Name 'Apply-Diag-Settings-LA-Microsoft-KeyVault-vaults' `
-Metadata '{ "category":"Monitoring" }' `
-DisplayName 'My-Diag-Apply-Diag-Settings-LA-Microsoft-KeyVault-vaults' `
-description 'This policy automatically deploys diagnostic settings to Apply Diagnostic Settings for Microsoft.KeyVault/vaults to a Log Analytics Workspace.' `
-Policy '.\Apply-Diag-Settings-LA-Microsoft.KeyVault-vaults\azurepolicy.rules.json' `
-Parameter '.\Apply-Diag-Settings-LA-Microsoft.KeyVault-vaults\azurepolicy.parameters.json'
Ce qui en retour de commande donne ce résultat :
Création d’une nouvelle définition
Et dans le portail au bout de quelques secondes, ce résultat :
Vue portail pour cette nouvelle définition.
Très chouette !
Un outil à utiliser absolument et que je range dans la catégorie pépiteabsoluequifaitgagneruntempsfou.
Ma catégorie favorite 😉
Comme d’habitude, si ce sujet vous inspire et que vous avez des remarques, ajouts, points contraires, n’hésitez pas à venir en discuter en commentaire.
Voilà un point qui pose question et inquiétude. Il y a beaucoup à dire sur ce sujet, l’article suivant présente quelques points importants, quelques pistes de réflexion qui permettront de réaligner son environnement sur le CAF (Cloud Adoption Framework). Très loin d’être exhaustif, mais plutôt destiné à mettre en appétit et à dédramatiser ce sujet.
J’ai déjà déployé mes ressources et mes charges de travail sur Azure et je l’ai fait sans respecter / connaitre / appliquer le CAF. Et je suis maintenant bien ennuyé pour gouverner correctement mes ressources.
Parce que le constat est rapide, pas de LZ (Landing Zone) cohérente, c’est une charge supplémentaire dans toutes les actions de gouvernance que je veux mener. Quelques exemples évidents :
Positionner des Azure policy ? C’est abonnement par abonnement
Positionner des RBAC, c’est abonnement par abonnement …Etc.
Faut-il jeter l’éponge ? Je ne pense pas. Il y a toujours moyen de rattraper ce manque, même post déploiement.
Ce que l’on trouve en général, et je dirais que c’est presque la meilleure des situations, ce sont des abonnements à la racine du management groupe par défaut nomme Tenant Root Group. Mais ce groupe ne doit pas servir à l’administration. Et les subscriptions à plats ne sont pas la solution.
C’est une premier constat, ça ne s’inscrit pas dans le CAF et ça ne facilite pas la gouvernance. Ce que l’on retrouve également beaucoup, c’est un positionnement de MG (Management groups) pour améliorer la lisibilité, un peu comme une arborescence de répertoires. Cela ne correspond pas non plus à un besoin de gouvernance. On gagne en lisibilité dans la console, c’est propre, mais rien d’autre.
Finalement, peu importe ce qui est en place hors du CAF, ce qui est important c’est comment réaligner au mieux l’existant.
Première tâche, la répartition des ressources. Est-elle cohérente ou bien ne l’est-elle pas ? Ce que je considère comme non cohérent, c’est par exemple un mélange des genres avec des ressources de plateforme dans le ou les mêmes abonnements que les ressources applicatives. Si cela peut convenir à très petite échelle (et encore !), c’est beaucoup plus compliqué à petite ou moyenne échelle. Ce que l’on comprend rapidement, c’est qu’il va falloir pour s’aligner sur le CAF … déplacer des ressources. Ce qui est dit au début de cet article, c’est que rien ou presque n’est impossible ou définitif, mais il y a quand même une bonne charge pour se remettre aux normes.
Il y a aussi avant / pendant cette phase un point essentiel, c’est de convaincre les équipes en place et expliquer pourquoi ces actions sont nécessaires. Et en tout premier lieu, expliquer qu’il n’y a pas de coûts liés aux MG et aux subscriptions. Ce ne sont que des conteneurs organisationnels ! Des boites vides sur lesquelles on va pouvoir positionner des stratégies et des équipes d’exploitation. Pour convaincre, je m’appuie souvent sur l’exemple ci-dessous. Comment il va être possible de passer de 4 attachements RBAC 4 attachements d’Azure Policy à 1 seul en s’appuyant sur les MG et l’héritage. Ce n’est pas une architecture cible, mais c’est un schéma simple et parlant pour commencer à expliquer les avantages et la granularité que vont amener les managements groups.
ATTENTION : Les plus pointilleuses / pointilleux vous diront qu’il est tout à fait possible d’attacher les RBAC à la racine, donc au niveau du Tenant Root Group.
Pour moi, c’est à éviter et ce n’est pas une bonne pratique. Il faut largement préférer le MG intermédiaire, qui porte dans la majorité des cas le nom de l’entreprise ou de l’organisation.
Mener ce changement, c’est créer des MG sur le modèle du CAF. C’est un prérequis au déplacement des subscriptions et des ressources.
On passe donc de l’ancienne version à gauche à la nouvelle à droite.
Seconde tâche, avant de basculer les ressources, décider de ce que seront les RBAC et les Policy Azure. C’est à dire vérifier que les policy existantes (s’il elles existent) sont reconduites. Par exemple, si il y a des policy liées aux contraintes légales sur les subscriptions existantes, il faut que le passage de la source à la cible s’accompagne des mêmes attachements de policy. Si j’ai choisi de déployer mes ressources en France uniquement, je dois porter ce choix sur ma nouvelle arborescence.
Je dois ainsi attacher cette stratégie mais sur un scope différent. Ici également, la présence de MG me donne plus de facilités. Comme ce choix est une stratégie d’entreprise qui doit être appliquée sur toutes les subscriptions, je la positionne au + haut niveau, le MG intermédiaire, plutôt que de positionner sur chacune des subscriptions.
Cette remarque est également valable pour les RBAC, je dois conduire la même réflexion sur le sujet des droits.
Troisième tâche, poursuivre l’identification et contrôler si les premiers piliers du CAF sont en place. C’est à dire (et oui …), le naming et le tagging. Je pense que la refonte de l’arborescence doit OBLIGATOIREMENT s’accompagner d’une réflexion approfondie sur le sujet naming / tagging.
Il faut avoir les idées claires sur les ressources. Trois pistes de travail :
1 / Le naming n’existe pas, alors il va falloir en mode « dégradé » s’appuyer sur des tags pour compléter l’absence de convention de nommage. Il est difficile ou impossible de renommer une ressource, la meilleur des solutions est de venir ajouter des informations normalement présentes dans la convention de nommage par des paire clefs / valeurs dans les tags.
2 / Le naming et Ok mais tagging est absent, c’est également à compléter. Mais c’est un peu plus facile
3 / Naming et Tagging sont Ok, c’est une bonne situation, il est possible de passer à la suite.
Une bonne pratique est également de traiter les tâches 2 et 3 en parallèle. Elles sont intimement liées, les Azure Policy utilisent avec bonheur le contenu des tags pour améliorer encore la gouvernance. Ce qui est présenté ici avec Philippe sur son (excellent) chaine Youtube. https://www.youtube.com/watch?v=-KvzxuwEVic&list=PLxf9spw2semQssko_pwji9lpqgUDGHxlB&index=13
Voilà pour quelques uns des points les plus importants, c’est à traiter à minima pour réussir sa transition d’environnement non gouverné ou difficile à gouverner vers le Cloud Adoption Framework, le nec + ultra ;).
Mais … il manque quelque chose. Puisqu’il est important de respecter le CAF, alors autant le faire jusqu’au bout et appliquer une des bonnes pratiques en terme de management groups. C’est à dire créer un %G spécifique qui va accueillir les subscriptions à décommissionner une fois tous les environnements basculés. Cette partie à droite, normalement coincée entre la Sanbox et la LZ.
Voilà, cette fois, tout est Ok, dans le respect du Cloud Adoption Framework ! Alors, tentées / tentés par l’aventure ?
Dans la partie 2/2, le sujet sera revu mais traité avec une approche différente appelée Brownfield. C’est une transition par duplication qui va sécurisé au maximum la bascule.
Si ce sujet vous inspire et que vous avez des remarques, ajouts, points contraires, n’hésitez pas à commenter et à partager vos expériences sur ce sujet de l’architecture conceptuelle.
Le sujet de l’architecture conceptuelle qui mène à la Landing Zone et assez vaste mais très documenté. Les références proposées par l’éditeur sont nombreuses et peuvent être dans la majorité des cas adoptées moyennant quelques adaptations.
Adapter, c’est respecter une partie de la référence du CAF (Cloud Adoption Framework) Microsoft en intégrant le spécifique du client. C’est à dire assez souvent en simplifiant l’arborescence proposée ci dessous …
Ce qui fait l’arborescence c’est en fait la partie centrale, pilier de la gouvernance avec la découpe en management group, puis en abonnement. Ce sont des conteneurs sur lesquels il va être obligatoire d’attacher des RBAC (Azure role-based access control) et des policy Azure. Plus simple à lire sous cette forme :
En blanc, les management group, en jaune, les subscriptions. Avant de penser à positionner des ressources dans ces subscriptions, on va lier des droits d’administrations, les fameux RBAC et des « contraintes », les Policy. Contraintes entre guillemets, c’est assez réducteur d’en parler uniquement sous cette forme, même si effectivement, lorsque l’on positionne dans l’arborescence une policy comme Deny network interfaces having a public IP associated, on peut parler de contrainte (utile). Ce qui n’est plus le cas par exemple lorsque l’on positionne une policy comme Deploy-Resource-Diag. Là, on comprend bien que c’est une aide à la conformité de l’architecture conceptuelle, un déploiement auto qui va permettre de s’assurer que tous les diag optionnels sont automatiquement déployés sur les ressources.
Pour en finir avec cette rapide présentation, les conteneurs sont donc utilisés pour y attacher policy et RBAC, et un mécanisme d’héritage va « descendre » les attachements du haut de l’arborescence sur tout ce qui se trouve plus bas dans l’arborescence.
Par exemple, une stratégie d’entreprise placée à haut niveau (Contoso dans l’exemple ci dessus) comme l’obligation de déployer les ressources en France uniquement est un stratégie du haut de l’arborescence qui va être appliquée par héritage sur la totalité des management group et des subscriptions (hors Tenant root group qui est un cas particulier).
Voilà le pourquoi de cette hiérarchie. Et comme il a été expliqué plus haut, on adapte pour les besoins du client avec par exemple la suppression du management group SAP, la fusion Management / Connectivity, l’ajout d’un MG (management group) NonProd sous la Landing Zones…etc. Ce sont des cas assez courants et plutôt faciles à traiter.
D’autres le sont moins et donnent lieu à interprétation. La Data (sujet de ce premier article) et l’IA (sujet d’une seconde partie qui fera l’objet d’un autre article dédié). Ou placer les suscriptions ? Besoin de créer d’autres MG ? Voici quelques pistes pour placer efficacement ces deux cas particuliers. Première réflexion, Plaform ou Landing Zones ou des MG dédiés ?
Attention, ce sont des choix discutables, des pistes de réflexion.
Se pencher sur le CAF Data, c’est… une aventure. Mais attention, pas une aventurette, une aventure, une VRAIE !
Ce que dit le CAF n’est pas très très clair. Mais comme la doc est très conséquente, je suis peut-être passé à côté d’un point de la doc (?!).
Ce que l’on peut comprendre ici, c’est le besoin d’avoir 2 LZ supplémentaires à minima. 1 Data Management et une ou plusieurs Data Landing Zones. C’est ce qui est dit dans la doc éditeur : Vous pouvez commencer avec une seule zone d’atterrissage et évoluer vers plusieurs zones d’atterrissage, puis les gouverner toutes à partir de la zone d’atterrissage de gestion des données.
Bien pour cette partie. Reste à savoir comment intégrer ces deux Landing Zone dans l’arborescence de référence.
Se baser sur ce schéma de la doc c’est comprendre que ? Ce n’est pas comprendre grand chose. On trouve 5 subscriptions dans cette vue. Identity, Management et Connectivity qui sont classiquement les 3 subscriptions à la racine 3 MG du MG de Platform…
Pour les 2 subscriptions restantes, interprétation libre.
Solution 1, pour moi, la plus cohérente. Un nouveau MG Data, au même niveau que Platform sous lequel on trouve un nouveau MG Data Management d’un côté et un second MG Data Landing Zone de l’autre. Le MG Data Management héberge la Sub Data Management et le MG Data landing Zone LES Sub Data 1, data 2 …etc. Le MG chapeau Data est utile pour attacher RBAC et policy communes au deux MG Data Management et Data landing Zone.
Si l’on essaye de projeter cette organisation en terme de management group uniquement, voilà ce que cela peut donner. Pas très lisible, mais l’essentiel est là. Intégration d’un MG chapeau Data au même niveau que le modèle de référence Platform et Landing Zones.
Complexe ? Je ne pense pas. Il ne faut jamais oublier que les Management group sont des conteneurs d’organisation, pas des ressources à part entière. Il ne faut pas se priver et l’ajout d’un peu plus de granularité est à mon sens une bonne chose. A terme, c’est faciliter la gouvernance de l’ensemble.
Solution 2, qui ne sera pas mon choix. Mais qui peut être interprétée de cette manière dans la schéma (il me semble). Intégration de Data ou du contenu de Data sous Platform. J’aime beaucoup moins cette solution, les MG Data Management et Data landing Zone héritent des policy et RBAC de Platform, ce qui n’est pas franchement cohérent. La solution 1 est plus granulaire et pour moi plus adaptée.
D’autres modèles sont à mon avis possibles. Mais je pense que la solution 1 est un bon point de départ. Si ce sujet vous inspire et que vous avez des remarques, ajouts, points contraires, n’hésitez pas à commenter et à partager vos expériences sur ce sujet de l’architecture conceptuelle. Dans la seconde partie du sujet, il sera question de l’ajout de l’IA dans cette infrastructure.
Il est maintenant temps de passer à la pratique pour mieux comprendre toutes les possibilités offertes par le module enterprise_scale qui va mettre en œuvre toutes les bonnes pratiques du CAF (Cloud Adoption Framework) par le code Terraform.
Lors de la présentation théorique, le terraform plan avait donné le résultat suivant :
Création de 233 ressources avec un peu de ressources de type management group et beaucoup de ressources de type policy + assignements + RBAC. Comme expliqué dans la première partie, dans un mode basique, il y a différents niveaux de management group qui sont attachés à différentes Archetype_definitions. Par exemple, le management group Root est attaché au fichier archetype_definition_es_root.tmpl.json, le management group enfant, Management est attaché au fichier archetype_definition_es_management.tmpl.json. Et chaque xxxxx.tmlp.json adresse différents points de gouvernance. Si cette partie n’est pas encore très claire, il faut relire l’article précédent pour bien visualiser le mode de fonctionnement.
Maintenant, qu’en est-il de la personnalisation ? Comment ajouter / retirer des policy ou des RBAC ? Tout va se passer dans l’arborescence du module et plus particulièrement dans le répertoire /Lib.
C’est un tout petit peu confus au départ. Il y a en fait 2 répertoires /Lib. Celui dispo dans le module et qui contient les modèles du CAF. C’est ici que sont posées les règles parfaites, là référence. Arborescence = .terraform\modules\enterprise_scale\modules\archetypes\lib
Le second répertoire /Lib est le répertoire de travail et de personnalisation. C’est ici que va venir toute la customisation que vous allez réaliser. /!\ Arborescence =/lib (à la racine du module) /!\
Un point d’attention ! Même si techniquement, rien n’empêche de modifier les fichiers de l’arborescence .terraform\modules\enterprise_scale\modules\archetypes\lib, ce n’est pas une bonne pratique. On doit considérer ces fichiers comme les fichiers de références pour la CAF, comme toute référence, on conserve sans modifier. Point de départ AVANT les modifications, savoir ce que propose le CAF dans son code de référence. C’est un peu toujours la même histoire. Même s’il est tentant de se jeter sur le code, le pré requis indispensable est de construire une baseline, sa référence à soi avec les adaptations nécessaires. Je ne dis pas ici qu’il faut s’éloigner de la baseline (et c’est même le contraire), attention à intégrer un maximum des points proposées par le module enterprise_scale. Sinon, ce n’est pas la peine de l’utiliser 🙂 Mais … customisation possible, c’est bien le sujet ce cet article.
Premier point, pour démarrer, les policy Azure. S’il y a bien un lien à avoir dans ses favoris (à ne pas perdre), c’est celui présentant la référence d’implémentation de policy d’une architecture conceptuelle : https://github.com/Azure/Enterprise-Scale/wiki/ALZ-Policies Pour moi, c’est un document de travail que j’utilise chaque fois que je dois définir l’architecture.
J’ai voulu pointer le module et faire le // entre la référence présentée dans le lien précédent et le module. Et j’ai eu les yeux qui piquaient un peu lorsque j’ai épluché les fichiers des répertoires policy_definitions et policy_set_definitions. Je m’attendais à trouver dans ces fichiers des Json de policy et des Json d’initiatives (regroupement de policy).
Et bien NON, pas sous la forme attendue.
Pour une raison que je ne comprends pas, ce sont bien des policy et des initiatives, mais de type Custom (pas builtin). C’est à dire que l’on ne trouve pas dans le portail et qui sont créées spécifiquement pour le code du CAF. Ce n’est pas exactement ce que j’attendais. Encore plus surprenant, ce sont des copies de policy existantes, mais qui ne portent pas le même nom. Il y a sans doute une très bonne raison à ça, mais je n’ai pas encore d’explication. Ce n’est pas très important.
Je précise que c’est la même chose côté RBAC puisque les fichiers de rôles du répertoire .terraform\modules\enterprise_scale\modules\archetypes\lib\role_definitions\ sont aussi de type custom.
Pour la suite, je propose une méthode light, il y en a d’autres, mais c’est une bonne base de départ. Dans le premier article, j’ai parlé de modifier certaines parties de la configuration. 2 possibilités pour cette configuration « maison ». L’ajout de paramètres aux paramètres du CAF ou le retrait de certains autres. La modification des configurations CAF se fera à la racine du répertoire de travail, lib\.
Il faut créer à la racine du répertoire deux fichiers archetype_extension_es_ et archetype_exclusion_es_. Ils adressent extension et exclusion. Je dis 2 fichiers, mais c’est plus exactement deux fichiers pour chaque management groupes à modifier dans la hiérarchie. C’est le suffixe que va porter le fichier qui va spécialiser son scope dans la hiérarchie.
archetype_extension_es_landing_zones.tmpl.json est le template qui va porter les ajouts pour le management group Landing Zones. Voici un exemple de Json que l’on peut ajouter dans ce fichier pour bloquer le déploiement dans certaines régions Azure.
Une remarque supplémentaire, la présence obligatoire de la ligne extend_es_landing_zones en début de Json.
Autre exemple qui concerne cette fois l’exclusion sur le scope de la Landing Zone et donc l’ajout d’un Json d’exclusion à la racine lib\. archetype_exclusion_es_landing_zones.tmpl.json. Côté Json, on retrouve la même construction avec le code suivant :
Même remarque, la présence de la ligne exclude_es_landing_zones en début de Json. Autre point, il est essentiel, l’ajout (extend) se fait de manière « libre ». L’exclusion (exlude) se fait sur la base de la liste de référence proposée par le CAF et qui est portée par le fichier .terraform\modules\enterprise_scale\modules\archetypes\lib\archetype_definitions\archetype_definition_es_landing_zones.tmpl.json pour la partie Landing Zone. Les 3 policy retirées dans le Json précédents sont dans la liste de référence, le fichier archetype_exclusion va retirer ces policy.
Voilà de quoi démarrer tranquillement le sujet. Il y a beaucoup d’autres subtilités avec ce module Terraform et plus particulièrement pour les rôles Custom RBAC et les Policy / Initiatives custom également. Je n’ai pas parlé de cette partie dans cette courte présentation, mais toutes les configurations Custom sont autorisées.
C’est à dire qu’en complément de la Custo extension / exclusion, on vient développer ses propres définitions de policy, ses propres rôles RBAC et que ces nouveaux fichiers sont intégrés directement dans le module.
Franchement, mettre un peu les mains dans le cambouis pour affiner sa gestion est un bon investissement. Et à mon avis, pas seulement lorsque l’on arrive sur Azure et que l’on doit déployer une nouvelle architecture conceptuelle qui mène à la Landing Zone. Mais aussi pour remettre à jour sa propre architecture.
Même si se réaligner intégralement sur le CAF (et plus particulièrement sur les Management group) est rarement possible, aligner ses policy sur la liste de référence est une option intéressante.
Niveau : ★★★★★ => Le niveau de difficulté est à 5 car la compréhension du sujet demande des connaissances sur un grand nombre de composants Azure.
« Le déploiement par le code, c’est super, ça va hyper vite ! »
Oui, c’est un fait. Et ? Seulement ça ? Bien heureusement, non. Plus qu’un code qui va « tout faire vite », c’est un guide, une garantie d’homogénéité. Et pour moi, c’est surtout cela. Homogénéité, reproductibilité et conformité, avant la vitesse des déploiements. Si on étend ce terme de code, on parlera plutôt d’IAC, ou infrastructure en tant que code. On déclare toujours ce que l’on souhaite déployer avant de le déployer. Mais de façon plus globale, plus industrielle. Et déclarer, c’est définir (documenter également) finement la cible. On passe donc d’un déploiement de ressources au déploiement d’un ensemble de ressources.
Par exemple, pour une nouvelle application, on doit déployer un ensemble cohérent de ressources pour que cette application soit fonctionnelle (en terme d’infrastructure). C’est une pratique assez courante (de + en +). Mais cette bonne pratique peut, par extension, toucher d’autres sujets que le déploiement d’une application. Appliquer cette bonne pratique au + tôt, c’est donc le faire (et c’est ce qu’il y a de mieux à faire dès lors que c’est possible) … dès la conception de la landing zone. La fameuse. On commence donc par le commencement, les ressources de bases qui sont les Management groups (et bien + tard, les subscriptions). Ci dessous, une image bien connue, au sommet de la landing zone, ou plutôt, au sommet de l’architecture conceptuelle d’une zone d’atterrissage (je préfère parler d’une architecture conceptuelle).
Résultat, on code, on test, on déploie, et on démarre.
Résultat, on se pose autour d’une table, et on se pose les bonnes questions.
Puisque nous en sommes au stade de la conception de base, un démarrage depuis rien, autant se faire plaisir et intégrer TOUTES les composantes d’une architecture conceptuelle cohérente et qui respecte les bonnes pratiques. Et par le code ! Et puisque c’est de ça dont il s’agit dans ce sujet, par du code Terraform.
2 solutions maintenant :
La première, lire, comprendre (et ingérer) l’intégralité de la documentation du Cloud Adoption Framework Azure (https://learn.microsoft.com/fr-fr/azure/cloud-adoption-framework/?WT.mc_id=AZ-MVP-5003759). Je conseille cette lecture attentive, mais en retenir tous les points, c’est une autre histoire. Donc on peut partir de là et appliquer toutes les bonnes pratiques et par la suite les déclarer dans le code. C’est possible, mais c’est une aventure. Une belle aventure, mais une aventure quand même.
La seconde (après lecture du CAF, cf point ci dessus), démarrer depuis un module Terraform appelé enterprise_scale
Hum, mais qui a t-il donc dans ce module ? Pas mal de choses comme permet de le voir l’init Terraform puisque : – C’est assez long – Au final le .terraform pèse plus de 400 Mo – Les messages d’initialisation sont très nombreux.
Et lorsque l’on regarde du côté du répertoire .terraform, il y a du monde !
Il y a dans cette phase d’initialisation des points extrêmement intéressants qui seront présentés en détail dans la partie 2/2 du sujet. Mais rapidement, on remarque (voir 2 photos au dessus) que les modules enterprise_scale sont suffixés de la façon suivante : enterprise_scale.connectivity_resources enterprise_scale.identity_resources enterprise_scale.management_group_archetypes enterprise_scale.management_resources enterprise_scale.role_assignments_for_policy En lien évident avec le modèle d’architecture conceptuelle !
Avant de comprendre comment cela fonctionne, voyons ce que cela fait (je commence … par la fin) . Pour les plus curieuses / curieux, le résultat du terraform plan donne un aperçu du très grand nombre de ressources adressées par ce module caf-enterprise-scale.
/!\/!\/!\ 233 to add /!\/!\/!\
Intéressant de regarder ce qu’il se trouve dans ce plan. De la ressources (un peu, mais très peu) et de la gouvernance (beaucoup). En terme de ressources, ce sont les ressources « socles » qui sont dans le plan.
En terme de gouvernance, majoritairement de la policy et de l’initiative (un regroupement de policy), de la définition de policy et des RBAC. Un exemple ci dessous avec l’assignement de l’initiative Deploy-VMSS-Monitoring
Clairement, ce qu’il faut comprendre, c’est que ce module intègre toutes les recommandations du Cloud Adoption Framework… directement dans la code.
Il y a différentes informations sur le git du projet et différents niveaux de mise en place. C’est assez graduel et cela permet de bien mieux comprendre ce qui est couvert par ce framework.
En vrac et pour démarrer tranquillement et proprement, un déploiement assez basique avec uniquement les managements groups « chapeaux » sans landing zone et avec des valeurs par défaut. Ce qui doit donner ce déploiement une fois le code appliqué.
Du très classique, on est pile dans le CAF. Alors attention, comme expliqué un peu plus haut, nous sommes bien au delà d’un déploiement de ressources de type management group (bien bien au delà même) puisque ce déploiement intègre un grand nombre de policy Azure que l’on trouve sous la forme de liste dans le répertoire .terraform\modules\enterprise_scale\modules\archetypes\lib\archetype_definitions\. Et plus particulièrement dans les fichiers archetype_definition_es_xxx.tmpl.json.
Archetype_definitions est le répertoire de définition central qui héberge les fichiers de déclarations des définitions pour chaque niveau de gouvernance / management group (puisque il faut considérer le management group comme un conteneur de règles de gouvernance). Il porte le nom du niveau de management group qu’il adresse et est suffixé tmlp.json puisque c’est un fichier Json déclaratif appelé par Terraform. Peut-être + facile à comprendre en image. Ici, chacun des fichiers va adresser les points de gouvernance au niveau ou il doit l’adresser.
Les policy Azure déclarées / liées sur le management group Management sont la sommes des déclarations pour les fichiers archetype_definition_es_root.tmpl.json (root, donc My Organisation) + archetype_definition_es_platform.tmpl.json + archetype_definition_es_management.tmpl.json. Pour ce que contient le fichier, et bien un fichier tmlp.json, ça ressemble à ça (vue partielle).
Mais ce n’est pas tout. Un petit mot supplémentaire sur l’Archetype definition qui sera présentée très en détail dans la partie 2/2 de cet article. A la lecture de cette première partie, on peut penser que c’est juste une déclaration de policy attachée à différents niveau de management group. Mais c’est beaucoup plus que cela. Voilà le fichier de définition archetype_definition par défaut (et vide) tel qu’il est constitué en plus des cartouches policy_assignments et policy_definitions de l’image précédente :
En + des définitions de policy dont il a été question + haut, on trouve également la gestion des RBAC (Azure role-based access control) dans la partie role_definitions (quelles listes de rôles) et dans la partie archetype_config les différents parameters que l’on peut déclarer. C’est à dire ? Et bien c’est la possibilité d’intégrer les paramètres de policy ou la liste des valeurs autorisées mais aussi d’attacher un compte ou des comptes aux role_definitions (RBAC) déclarés dans ce même fichier. Dans l’image ci dessous, une explication de comment fonctionne le fichier. Pour un scope donné, on assigne en vert 2 policy qui sont « Deny-Resource-Locations » et « Deny-RSG-Locations ». Comme ces policy demandent des paramètres, ils sont traités dans la partie (toujours en vert) "archetype_config": { "parameters": {
Idem pour les rôles RBAC, role_definitions (en orange) qui sont complétés par l’information access_control.
La boucle est … bouclée. Alors est-ce PARFAIT ? Non, certainement pas, si il n’y avait pas moyen de faire évoluer ces configurations.
Car évidement, une architecture conceptuelle est constituée d’un ensemble de besoins d’entreprises qui ne sont pas nécessairement les mêmes pour toutes les entreprises. Si ce « modèle parfait » est une excellente manière de démarrer au + prêt du CAF, il faut prévoir un peu de souplesse. Et la possibilité de surcharger le CAF (Attention, surcharger n’est pas nécessairement ajouter).
Pour finir, une liste non exhaustive (et qui sera présentée en pratique dans la partie 2/2) de ce qu’il est possible d’ajouter / retirer / adapter en partant du « modèle parfait », toujours par le code.
Ajouter ses « Custom rôle » pour la partie RBAC et les lier.
Ajouter ses « Custom definition » de policy, renseigner et cadrer les paramètres et les assigner.
Traiter ses configurations de subscriptions dans des fichiers différents avec des contenus différents. Sous l’arborescence de la Landing Zone se trouvent les subscriptions. Elles vont hériter du modèle des management group mais peuvent aussi demander des points de gouvernance complémentaires (Prod ? hors Prod ?…etc).
Exclure (archetype_exclusion_es_landing_zones.tmpl.json) des policy même si elle viennent d’un management group. Il faudra le faire en connaissance de cause, mais c’est une possibilité.
Et j’en oublie certainement !
Alors ? Modèle PARFAIT ? Je ne sais pas, mais certainement ce qu’il se fait de mieux et de + structuré. Après cette longue présentation théorique, place à la pratique et à la mise en œuvre dans la partie 2/2 de cet article (à venir) !
Rappel Important de cette première partie, ce n’est plus le moteur de configuration intégré (LCM) de DSC qui va traiter LE fichier de configuration mais les Azure Policy qui vont traiter LES fichiers de configuration. Différence … importante !
Il y a lorsque l’on aborde ce nouveau sujet pas mal de documentations à lire et pas mal d’étapes à dérouler pour utiliser cette fonctionnalité. Rien de mieux qu’un schéma (peut-être un peu « copieux ») pour mieux comprendre les différentes étapes de mise en œuvre.
On trouve sur la partie basse (en gris) une mise en œuvre de type CI/CD réalisée avec Azure Devops ou avec Gitlab par exemple. Mais c’est plutôt la partie haute qui va décrire les étapes de mise en œuvre. Dans cette partie 2 de l’artcile, la présentation théorique des différentes étapes.
Première étape, les prérequis pour pouvoir préparer ses configurations. Ici, on utilise Powershell Core dans sa version la plus récente si possible, ou à minima, une version 7 et +. A installer depuis le repo des releases dispo à cette adresse : https://github.com/PowerShell/PowerShell/releases Version en cours, 7.3.9
Puis on ajoute le module dédié, GuestConfiguration, qui va permettre de préparer les configurations. Rien à signaler de ce côté. Rien à signaler jusqu’au prochain article ou on verra ensemble qu’il peut y avoir quelques surprises avec ce module.
Seconde étape, préparer une configuration de type DSC. C’est à dire une configuration déclarative, ce que l’on veut obtenir (et maintenir). Pour les utilisatrices / utilisateurs de DSC, pas de différence avec l’existant. Si vous n’avez jamais utilisé DSC, voici une configuration passe partout que je présente dans un article dédié pour réaliser ses premiers pas avec DSC : https://thierrybtblog.wordpress.com/2018/06/18/votre-premiere-configuration-dsc-1-2/
Ce code va servir lors de la préparation des artefacts présentée prochainement en détail dans la partie 3/3.
Configuration Clef1 { Node ‘DSC2’ { Registry RegistryExemple { Ensure = "Present" Key = "HKEY_LOCAL_MACHINE\SOFTWARE\Clef1" ValueName = "Le nom de ma clef " ValueData = "La valeur de ma clef" }}} Clef1
3 ème étape, faire de cette configuration, un Artefact. Là, c’est assez nouveau. Une configuration DSC, c’est un fichier PS1 (Powershell) qui est compilé par des commandes DSC et qui devient un fichier Mof (Managed Object Format). Il y a maintenant l’ajout d’une étape, ce mof devient avec des commandes du module GuestConfiguration un fichier Zip. Pour résumer : PS1 => MOF => ZIP Nous verrons que ce fichier est consommée façon assez particulière.
4 ème étape, valider la conformité du fichier. C’est à dire vérifier la présence des modules et dépendances par exemple. Ce n’est pas spécifique à GuestConfiguration mais plutôt à DSC. Une parenthèse à ce sujet. DSC est livré de base avec quelques modules. Mais avec le temps, ce sont plusieurs milliers de modules qui sont disponibles. Si la configuration souhaitée fait appel à une module particulier, il faut qu’il soit disponible. Valider la conformité, c’est donc vérifier ce point (et quelques autres) avant de pouvoir se dire que l’artefact est valide. Une autre exemple, jouer à blanc le fichier pour vérifier qu’il peut contrôler la configuration ou l’appliquer.
5 ème étape, publier l’artefact. Attention, cette partie sera présentée en détail (très en détail), c’est en fait une opération de copie des fichiers Zip de configuration sur un compte de stockage Azure. Si possible (même si cette étape est facultative), en utilisant un jeton SAS pour garantir un accès sécurisé au package stocké.
6 ème étape, créer une définition Azure Policy. Ici, il va falloir s’accrocher un peu. Un peu de teasing sur la 3 ème partie du sujet.
Au premier abord, pas très inspirant…! Pourtant, on retrouve quelque uns des points dont il a été question un peu + haut. Par exemple, la variable $contentURI qui est l’URI HTTP(S) public du package de contenu configuration de machine. Dans la ligne Path = './policies/auditIfNotExists.json', la définition de policy Azure. Rien de mystérieux, mais il faudra expliquer ce contenu pas à pas. Cette partie ne peut être correctement comprise sans une mise en œuvre complète, il faudra patienter un peu avant de retrouver cella dans la partie 3/3 de l’article. Ce n’est pas tout avec cette 6ème étape. Les commandes du module GuestConfiguration ne vont créer qu’un (petite) partie de la policy. Le cœur de la configuration. Mais toutes les données périphériques sont à ajouter directement dans le Json généré par le module. Une Policy, c’est une règle ou un ensemble de règles qui vont identifier des ressources et certains de leurs paramètres. Puis y appliquer un effet, comme par exemple l’audit, le deny, la remédiation …etc. Si la partie effet et contenu est bien traitée par le module, la règle d’application peut / doit être revue. Le json va être enrichi du filtre d’application. Voir ci dessous un exemple fourni dans la documentation éditeur.
Si allOf (c’est à dire si toutes les conditions sont remplies), alors j’applique l’effet de la stratégie. Dans l’exemple si tag Owner = BusinessUnit et si tag Role = Web, alors j’applique l’effet.
Dernier point pour terminer ce sujet, l’attribution des configurations ne reprend qu’une partie des effets disponible dans les policy Azure. Si les policy « historiques » sont capables d’appliquer les effets suivants (la liste a évoluée ces derniers temps) … AddToNetworkGroup Append Audit AuditIfNotExists Deny DenyAction DeployIfNotExists Disabled Manual Modify Mutate
… les policy version GuestConfiguration sont un peu moins riches et même différentes dans le mode de fonctionnement. Deux modes disponibles, AuditIfNotExists et DeployIfNotExists . Mais complété par la valeur Type du package qui détermine si la configuration doit uniquement effectuer un audit ou si la configuration doit modifier l’état de l’ordinateur (AuditandSet ou Audit).
Surchargé du type d’attribution Audit, ApplyAndMonitor et ApplyAndAutoCorrect.
Bon, Ok, assez opaque, mais je le répète (ne fuyez pas), ce sera BEAUCOUP + clair lors de la mise en œuvre.
Toute dernière étape, mais qui n’en est pas vraiment une, la visualisation des résultats. Là, c’est habituel, direction la console Policy Azure qui offre tout ce qu’il faut pour avoir un rapport clair et précis de ses configurations.
RDV dans quelques jours pour une première mise en application. Et le moins que l’on puisse dire, c’est que c’est une solution qui DEPOTE ! Un peu subtile dans la mise en œuvre, mais ça vaut vraiment l’investissement 😉
Pourquoi conserver un compte de stockage dans sa version 1 alors que :
1 / La migration d’une V1 à une V2 se fait par un simple clic / commande, sans perte de service. Dans un seul sens par contre, c’est à dire qu’il n’est pas possible de passer d’une V2 à une V1 mais seulement d’une V1 à une V2.
Et bien, il y a pourtant 1 cas d’usage qui nécessite de rester dans une version 1. Et bizarrement, c’est du côté des transactions intensives qu’il faut regarder (?!). Oui, c’est une surprise, mais la V1 est conseillée pour les scénarios de ce type. Si l’on se réfère à la documentation officielle https://learn.microsoft.com/fr-fr/azure/storage/common/storage-account-overview#legacy-storage-account-types, il existe en fait 4 cas pour lesquels la V1 est conseillée. Dont 2 qui sont en fin de vie, le modèle de déploiement Azure Classic, dont la prise en charge se terminé en 2024 et l’API REST antérieure à février 2014 qui est également stoppée en 2024.
Pour le reste, 2 sujets toujours d’actualité : 1 / Les applications gourmandes en transactions ou qui utilisent beaucoup de bande passante de géoréplication. La V1 est un choix économique.
2 / Le cache ASR (Azure Site Recovery), ou la aussi, les transactions sont intensives et ou la V1 doit présenter un plus grand intérêt financier.
Alors il n’est pas encore temps de jeter ses « vieux » comptes et / ou de tout passer en V2, la Version 1 a encore de quoi faire de la résistance.
Dans cette cinquième partie, direction la bulle Toujours +.
Ici, ce sont des fonctionnalités que je n’ai pas placé dans les parties précédentes mais qui ont tout de même de l’intérêt.
3 points que j’ai sélectionné parce que je les trouve simples à mettre en ouevre (c’est le moins que l’on puisse dire) et très utiles.
L’Inventaire, le Site Web Statique et la Réplication. – Inventaire (ou Blob inventory). Ce sont des règles permettant de mieux connaitre le contenu des conteneurs. Ci-dessous, quelques paramètres de règles. On y trouve ce qui doit être vérifié, le type, la time range, le format de sortie, les préfix …etc.
Dans l’exemple, j’utilise ce genre d’inventaire pour traiter au mieux la partie lifecycle des données. Voir à ce sujet la partie 2/5 de cette série d’articles. Les résultats sont envoyés directement dans le conteneurs de stockage sur lequel est positionné la règle. On récupère un CSV ou un export au format Apache parquet. On trouve les fichiers dans une arborescence Année, mois, jour, heure + nom de la règle.
Reste à étudier ce fichier pour en extraire les données importantes. Sans être révolutionnaire, la fonctionnalité est intéressante.
Site Web Statique est une autre fonctionnalité intéressante. Par sa facilité de déploiement, son faible coût et les services rendus. La promesse, c’est de publier un site Web statique en quelques secondes sans se préoccuper de la façon dont sont exposées les pages (Apache, IIS…etc). Du site Web serverless en quelque sorte.
Il y a bien entendu quelques limitations puisque l’on parle de contenu statique (fichiers HTML, CSS, JavaScript et images). Mais aussi quelques options très intéressantes comme la possibilité d’utiliser le couple CDN (Content Delivery Network) pour créer un cache régional et Azure Front Door pour un contenu régional.
Lorsque je parle de simplicité, je crois qu’il n’y a pas d’autres termes. Activer un site web statique se fait en 2 clics (Enabled et Save) et deux noms de fichiers.
On récupère à la validation l’URL de son site statique. Reste à charger son index et sa 404 dans un conteneur que vient de créer l’activation et qui se nomme $web dans le compte de stockage.
Et on lance son navigateur avec son Url (mon index et ma 404).
Chrono en main, c’est environ 1 mn pour publier son site. Impossible de faire mieux. Là encore, ce sont de belles possibilités qui sont offertes.
Réplication. Dernière chose, la possibilité de répliquer des blobs de manière asynchrone entre les comptes de stockage. Il faut noter que cette possibilité est offerte sur une même Tenant mais aussi « cross tenant ». Quand même ! Très peu d’opérations pour créer une règle. Compte source, compte de destination. Avec l’ajout de filtre si nécessaire et des dates de démarrage pour ces synchros (Filters et Copy Over ci dessous).
L’écran de règles affiche ensuite les paires de synchro sous la forme from, into sur le comptes de stockage source et cible. Ici, la vue depuis le compte de stockage cible.
Le cas d’usage pour ce type de synchro sont presque infinis.
Voilà qui termine cette (longue) série sur le PAAS Azure compte de stockage.
Il y a encore à dire et ce qui a été présenté dans cette série est un choix personnel. Mais le compte de stockage est clairement un service PAAS très complet, qui offre beaucoup plus que du stockage et qu’il faut connaitre pour en apprécier toutes les possibilités.
Dans cette quatrième partie, direction la bulle Accès
Les accès, c’est tout ce qui va permettre d’exploiter la ressource ET les données qui y sont stockées. Ressource et données, ce n’est pas la même chose. Accéder à un compte de stockage, ce n’est pas forcément le droits d’accéder à une donnée Blob par exemple.
Il y a deux types de mécanismes d’accès, les clefs et les RBAC (role-based access control).
Les clefs :
Lorsque l’on parle de clefs, on parle d’Access keys, de SAS (Shared access signature), de SAT (Shared access tokens). On peut, pour être complet sur ce sujet, ajouter les Access policy, qui ne sont pas des token d’accès mais qui viennent (ou peuvent venir, elles ne sont pas obligatoires) compléter la méthode d’accès aux éléments du compte de stockage.
Voilà une belle brochette de possibilités. Au plus haut niveau d’accès, on parle d’Access keys. Et là, attention … DANGER. Il n’y a aucune granularité si l’accès se fait avec l’Access keys. Pas de limite sur le type de stockage, c’est à dire que cet accès est valable pour les conteneurs du compte, pour ses partages de fichiers, ses queues et ses tables. Et cet accès va bien au delà de la ressources compte de stockage puisque il donne également droit aux données qui y sont stockées. Donner une access keys de compte de stockage, c’est donner … les clefs du camion !
Remarque importante sur ce point, et cela a été abordé dans la partie 1/5 de ces articles, le script de connexion des File Share utilise et affiche en clair la chaine de connexion (donc l’accès keys) pour créer le mappage entre la machine et son partage de fichiers sur le compte de stockage. On comprend pourquoi Microsoft recommande d’utiliser les RBAC, et on comprend également pourquoi il est préférable de dédier un compte de stockage aux partages de fichiers sans que ce compte n’héberge d’autres types de stockage (c’est mon avis sur le sujet).
Autres informations en vrac sur l’access key :
– Elle peut être renouvelée lorsqu’elle est compromise et, bonne pratique, doit être renouvelée régulièrement. Elle est présente en double pour faciliter les opérations de renouvellement.
– Elle est utilisée pour signer les clefs SAS / SAT qui perdront leur validité si la clef d’accès est modifiée (opération Rotate key sur l’écran précédent).
Les clefs de type SAS (Shared access signature) sont différentes. Il suffit de lancer le menu pour comprendre que ce sont des accès beaucoup plus fins / granulaires.
Ici, ce ne sont plus des accès générique qui sont donnés. On trouve dans la liste des choix principaux :
– Les services (comprendre type de stockage) autorisés, c’est à dire Blob, File, Queue et Table. – Les ressources autorisées, Service, Container, Object – Les permissions Read, Write, Delete, Create …etc. – Une date de début / fin pour ce jeton d’accès. – Du filtrage IP pour les accès – La clef qui a signé ce jeton (Signing key).
Voilà une gestion des accès beaucoup plus fine que la clef du compte de stockage. Ce menu génère une URI (un token) qui est présenté pour accéder aux ressources / données.
Ce n’est pas tout. Les conteneurs bénéficient d’un traitement encore plus granulaire avec la clef SAT (Shared access tokens). C’est un paramètre de menu pour chaque conteneur. Je parle de clef SAT et cette appellation est discutable (et personnelle). Elle se nomme Shared access tokens dans le menu mais c’est un champ Generate SAS token and URL qui permet de valider la création (voir ci dessous). Ce qu’il faut simplement retenir, c’est que c’est un ajout de granularité puisque le traitement est fait pour chaque conteneur individuellement (dans l’exemple, cont1).
Dernier complément (pas le plus connu), l’Access policy. C’est une « surcharge » de clef d’accès qui combinée avec les paramètres de la signature d’accès amène des restrictions complémentaires. Je n’ai pas encore eu de cas d’usage pour ce complément, c’est donc une donnée purement théorique pour moi.
Pour en terminer avec ces différents points, l’utilisation des mécanismes de clefs est à compléter par un process d’automatisation (Azure Automation est un complément naturel). Il faut organiser les rotations de clefs pour ne pas laisser dans le temps une clef inchangée qui finirait par présenter un risque de sécurité (passage entre collègues par exemple …).
Pour toutes les raison citées précédemment, Microsoft recommande dans la mesure du possible d’utiliser les RAC pour sécuriser et accéder aux ressources des comptes de stockage.
Les RBAC (role-based access control) :
Les RBAC, ce sont des règles d’accès pour des ressources / datas. Avant de présenter le spécifique RBAC pour les comptes de stockage, il faut comprendre comment sont définis les RBAC.
C’est un fichier Json, une définition des accès pour certains types d’actions. Soit des accès à un type de ressources, soit des accès à un ensemble de ressources.
Pour prendre l’exemple d’une VM, le rôle Virtual Machine Contributor est un rôle qui étend ses droits à un provider de type VM, mais aussi, parce que c’est indispensable, à des autorisations autres (de l’Insights, du Network …Etc). Ce que je nomme ensemble de ressources.
L’ossature du Json est assez simple, avec un scope d’assignation et des permissions. Et à l’intérieur des permissions, une liste actions, notActions, dataActions et notDataActions. Dans l’exemple du Owner, le plus haut niveau de droits, la permissions actions est à *, sans autres restrictions. C’est assez clair, tout est permis.
Le compte de stockage est géré avec ce type de rôles. Mais il y a une petite différence car en + de l’accès à la ressource, il faut aussi accéder aux données qui se trouvent à l’intérieur. Ainsi, un rôle Storage Queue Data Reader, c’est le Json suivant.
Un accès à la ressource, actions, un accès aux datas de cette ressource, dataActions. La différence ? Le endpoint appelé par l’API pour les opérations de vérification des droits. J’ai essayé de représenter au mieux ces différences sur le schéma suivant :
On parle ici de plan de contrôle et de plan de données. Vers quelles API va être envoyée la requête de constitution des accès.
Voilà pour cette présentation un peu longue des RBAC, mais ce chapitre est applicable à l’ensemble des ressources, important de savoir ce qu’il se passe vraiment dans l’arrière boutique 😉
Une techno, des infos. 