Approche pratique d’Azure Arc-Enabled Server

Avec une adoption croissante du Cloud public, on constate une multiplication des approches multi-Cloud ou hybrides.

Par ces appellations, on essaye de répondre à une inquiétude bien connue : comment se protéger en ne mettant pas tous ses œufs dans le même panier ?

Répondant à cette demande, nous avons vu le développement ces derniers temps de l’offre Azure Arc. Il s’agit bien effectivement d’une offre et pas d’un seul service, comme vous avez pu le voir sur cette vidéo d’introduction sur les enjeux de la supervision dans un environnement hybride.

Afin d’aller un peu plus dans le concret, nous vous proposons dans cet article une approche plus pratique de l’utilisation de Azure Arc-enabled Server, la partie de l’offre Arc dédiée à la gestion de serveurs en mode hybride.

Dans notre cas, nous allons nous intéresser aux possibilités qui nous sont offertes pour gérer depuis Azure des instances de calculs dans d’autres Cloud providers.

Nous commencerons par aborder la question de l’architecture, avant de regarder comment réaliser notre supervision hybride.

Azure Arc Server : principes d’architecture

Comme nous l’avons annoncé en introduction, nous faisons ici un focus sur Azure Arc Server.

Ce service nous permet de connecter à Azure des informations sur l’état du serveur pour réaliser une supervision depuis un seul point : la console Azure.

Les serveurs sont connectés à Azure Arc à travers… un agent. Et même, en réalité, à travers deux agents :

• Le premier agent, Azure Connected Machine agent, réalise la partie connexion et permet donc d’avoir un inventaire des ressources hybrides ;
• Le second agent, Log Analytics agent, bien connu des populations techniques Azure, permet de récupérer les métriques et log de ces ressources.

A propos de l’agent Connected Machine

La documentation Azure nous fournit un grand nombre d’informations sur l’agent Connected Machine. Sans reprendre toute cette documentation ici, en résumé, cet agent connecte l’instance sur lequel il est installé à Azure Arc. Les données transférées sont sécurisées par https, avec une option pour configurer un proxy si besoin.

D’un point de vue fonctionnalités, l’agent Connected Machine comprend 3 composants :

• L’Hybrid Instance Metadata Service (HIMDS) qui authentifie le serveur sur Azure AD et gère sa connexion vers Azure Arc ;
• L’agent de configuration invité, qui intervient notamment dans des évaluations de compliance ;
• L’agent d’extension qui permet d’ajouter… d’autre extensions comme l’extension Custom script, l’Azure Monitoring Agent, ou encore l’agent Log Analytics.

Notons tout de même que le trafic envoyé par les serveurs connectés à Azure Arc passera par défaut via Internet, même s’il est encapsulé par TLS.

Également, l’agent s’authentifie sur Azure AD via une application registration spécifiée au moment de l’installation.

Et si on veut une connexion privée ?

Depuis plusieurs années maintenant, la question  de la connexion privée a été posée lors des conceptions d’architectures Azure et les équipes Produits ont fait évoluer les services PaaS en développant la solution Private Link, permettant ainsi de garder une connexion aux instances PaaS sur un réseau entièrement privé.

De fait, pour des serveurs Arc-Enabled situés dans un réseau connecté à Azure via un Private Peering ExpressRoute, il est possible d’utiliser Azure Private Link Scope et ainsi de conserver ce même schéma.

Comme pour toute stratégie incluant Private Link, il convient de planifier de manière appropriée une architecture pour connecter des serveurs sur Azure Arc.

A noter : dans la suite de cet article, nous ne développerons pas davantage ces concepts.

Les prérequis de l’agent Connected Machine

Quelques prérequis doivent être à pris en compte tout de même.

En premier lieu, si le trafic sortant est contrôlé par un appliance gérant des règles basées sur des FQDN (Fully Qualified Domain Names), on peut se référer à la documentation Azure pour identifier les url requises :

Ensuite, vis-à-vis des versions compatibles, encore une fois, il est possible de retrouver dans la documentation Azure la liste des OS compatibles avec l’agent Connected Machine :

• Windows Server 2008 R2 SP1, 2012 R2, 2016, 2019, and 2022
• Windows IoT Enterprise
• Azure Stack HCI
• Ubuntu 16.04, 18.04, and 20.04 LTS
• CentOS Linux 7 and 8
• SUSE Linux Enterprise Server (SLES) 12 and 15
• Red Hat Enterprise Linux (RHEL) 7 and 8
• Amazon Linux 2
• Oracle Linux 7 and 8

Nous verrons un peu plus bas comment se passe l’onboarding dans les faits. Attachons-nous à présent à la partie observabilité.

A propos de la remontée de la télémétrie

Jusqu’ici, nous avons évoqué l’agent Connected Machine uniquement. Nous avons vu qu’il inclut un agent de gestion des extensions.

C’est cette partie qui interagit avec d’autres extensions bien connues sur Azure, sans lesquelles il ne peut pas y avoir de remontée d’informations, à l’exception de l’inventaire, celui-ci étant basé sur les metadata remontées par HIMDS.

Vis-à-vis de la télémétrie, ce sont donc des agents installés en supplément qui permettent de réaliser l’observabilité des serveurs Arc-Enabled.

Parmi les agents à considérer, on retrouvera les classiques tels que Log Analytics Agent ou encore le très attendu Azure Monitor Agent, qui doit permettre à terme de remplacer nombre d’agents de l’écosystème Azure et, de fait, de simplifier la remontée d’informations.

Les ajouts d’agents peuvent être réalisés lorsque les serveurs ont onboardé dans Azure Arc. La méthode simple reste bien entendu l’usage du portail ou encore l’usage d’Azure Policy.

Cas pratique : gestion d’instance EC2 dans Azure Arc Server

Nous avons mentionné dès l’introduction une vision Cloud hybride. Nous allons à présent regarder comment garder une visibilité depuis Azure sur des instances EC2 dans AWS.

Et si on parlait un peu d’IaC ?

Les concepts d’Infrastructure as Code (IaC) sont largement mis en avant et on a le choix entre de nombreux outils. Parmi ces outils, bien entendu, on retrouve le célèbre Terraform de Hashicorp.

Dans l’hypothèse d’une hybridation multi-Cloud après une première transition vers Azure, si l’on a déjà développé le skill set de l’IaC sur Terraform, le passage vers un autre Cloud provider peut s’en trouver facilité grâce à la versatilité de cet outil. A réfléchir donc !

Notons, sur cette approche, l’excellent contenu proposé par Microsoft avec le repository Github Azure Arc Jumpstart où l’on trouve notamment un exemple qui fait écho à notre cas d’usage.

Onboarding d’une instance EC2

L’onboarding d’instance d’un autre provider dans Azure Arc commence par une préparation dans Azure.

Le portail Azure accompagne l’utilisateur sur cet onboarding en identifiant les prérequis :

On retrouve notamment ici les urls requises pour la connectivité réseau mentionnée plus tôt :

Un Resource Group cible, ainsi que l’OS du(des) serveur(s) doivent être spécifié :

On notera ensuite, dans la partie Authentification, la nécessité d’une application registration avec le rôle Azure Connected Machine Onboarding défini ci-dessous :

Dans une approche IaC, on pourrait considérer l’usage du provider Azure Active Directory pour créer le service principal :

A la fin de toutes ces étapes, il est possible de récupérer un script d’onboarding, conditionné par la sélection de l’OS :

 Script fourni pour un serveur Windows

Script fourni pour un serveur Linux

En utilisant la fonction templatefile() de Terraform, il est possible d’automatiser l’onboarding à travers la configuration User data des instances EC2.

⚠️A noter : si la création d’une instance EC2 est plutôt rapide, le processus d’onboarding prend un certain temps.

Lorsque celui-ci est complété, nous retrouvons dans le portail Azure les serveurs Arc-Enabled :

L’observabilité hybride en action

Puisque nous avons à présent quelques instances Arc-Enabled, commençons à nous intéresser à l’observabilité.

Après l’onboarding, le serveur est visible mais ne remonte rien.

Pour commencer à récupérer des informations, rendez-vous dans la section extension :

On retrouvera les agents déjà cités proposées à l’installation :

On peut également activer implicitement l’installation de l’agent log analytics dans la section Insight, sous réserve d’avoir un log analytics workspace à disposition :

Après installation, on retrouvera dans les extensions les agents Log Analytics et Dependency Agent :

Lorsque les agents sont opérationnels, la section Insight fournit des informations sur les ressources utilisées :

Et sur les process en cours dans le serveur :

On notera la présence du process HIMDS qui, comme nous l’avons évoqué précédemment, permet la remonté des metadata requises pour l’inventaire Azure Arc.

Enfin, chose non négligeable, Azure Advisor nous donne des recommandations sur les serveurs Arc-Enabled, notamment si, comme c’est le cas ici, nous n’avons pas encore d’AzurePolicy pour installer les agents de monitoring :

Voilà pour un premier tour concret de Azure Arc Server.

En savoir plus sur Azure Arc-Enabled

Azure Arc-Enabled Server permet de rendre visibles dans Azure des serveurs venus… d’ailleurs. L’onboarding est relativement aisé, mais nécessite malgré tout de la planification pour un passage à l’échelle.

L’observabilité depuis Azure est quasi immédiate, une fois l’onboarding et l’inventaire mis en place via l’agent Connected Machine.

Quelques sujets pour approfondir :

• L’intégration des crédentials pour l’onboarding dans un vault natif du Cloud provider, et dans notre exemple, l’usage d’IAM rôle pour récupérer notamment le secret du service principal.
• La mise en œuvre d’Azure Policy pour automatiser l’installation des agents de monitoring et l’intégration à Defender for Cloud par exemple.

Vous souhaitez approfondir les sujets autour de l’hybridation ? Consultez dès à présent les autres articles de cette série :

• IoT : comment mener un projet hybride ?
• Defender for Cloud : la solution Microsoft pour la supervision de la sécurité
• Le poste de travail hybride
• Utiliser Spark avec Kubernetes
• Les applications hybrides