Nous avons vu récemment comment automatiser une stack Active Directory et comment directement rattacher les instances dans un domaine à la création de ces dernières. L’un des avantages majeurs du Cloud est de pouvoir scaler automatiquement l’infrastructure selon les besoins applicatifs, mais s’il est possible de joindre un domaine lors d’un scale up, il faut également pouvoir en sortir proprement lors d’un scale down. Comment éviter de faire ce nettoyage AD a posteriori ? Nous proposons ici une méthode faisant appel à Lambda.NET pour gérer de façon automatique la suppression de compte AD.

Lors du join domain, il est possible de lancer un script powershell utilisant l’user data des instances et ainsi de rejoindre le domaine. Mais lorsqu’on arrête une instance, il n’existe pas de mécanisme similaire. Il est possible de gérer cette suppression à l’aide de tâches planifiées et de SQS, mais ce système reste assez lourd, et nécessite une instance pour lancer le script.

En revanche, Cloudwatch Events permet de lancer des actions en réponse à des événements précis. Dans notre cas, on considère la fin d’une instance comme étant l’événement, et nous utilisons Lambda afin de gérer le nettoyage AD. Cela permet d’avoir une gestion centralisée, et même de l’appliquer à plusieurs groupes d’Autoscaling sur plusieurs domaines AD, ou bien directement sur des instances EC2.

Pour commencer, nous devons créer notre règle Cloudwatch et indiquer le pattern du trigger. Nous répondrons ici à la terminaison d’une instance dans le groupe d’auto-scaling « testremovead » :

Nous définissons ensuite notre target, à savoir la fonction Lambda :

Nous utiliserons l’Input Transformer pour lui transmettre l’ID de l’instance terminée ainsi que différentes informations sur le Domain Controller à contacter pour supprimer le compte. Le fait de mettre ces informations en paramètres et non directement dans notre fonction nous permet d’avoir une fonction unique déployée pour plusieurs règles Cloudwatch (correspondant à divers groupes d’auto-scaling).

Afin de ne pas divulguer le compte de domaine dans notre configuration AWS, nous utilisons le parameter store du System Manager EC2, et nous transmettons simplement à notre fonction Lambda les noms des clés, qui récupérera la valeur :

Enfin, nous devons configurer la fonction Lambda afin qu’elle puisse communiquer avec notre DC. Pour cela nous allons la lancer dans le VPC qui contient notre DC, ce qui peut être défini dans la configuration Lambda :

Si aucun DC n’est présent sur AWS, il faut alors configurer un tunnel VPN ou un Direct Connect entre le subnet d’exécution de notre Lambda et notre datacenter.

Enfin, pour supprimer le compte AD de la machine (ou le désactiver dans un premier temps), nous devons associer l’instance-id au hostname dans le domaine directement dans le code.

Notre fonction étant en dotnetcore 1.0, la résolution DNS n’est pas encore supportée, cependant en bonne pratique nous recommandons de renseigner le nom de la machine dans le tag Name ou Hostname afin d’avoir une meilleure visibilité dans la console. De ce fait, une simple récupération de ce tag permet de reconnaître l’instance dans le domaine.

Je ne détaillerai pas ici le contenu de la fonction Lambda, qui sera l’objet d’un autre article sur le déploiement de fonctions Lambda dotnetcore 1.0 et les différents cas d’utilisation pour l’administration de l’infrastructure AWS.