Ca faisait quelques temps que j’avais remarqué un comportement « étrange » de certains de mes scripts Azure. Pour beaucoup d’entre eux, je commence par m’assurer avec un Get-AzuremContext que je suis bien authentifié. A ma grande surprise, je découvre que oui, pourtant, je n’ai renseigné aucun credential. Magie ? Nan. J’ai creusé un peu plus le sujet pour redécouvrir le module AzureRM.Profile. Ma recherche m’a amenée sur cette page : Automatic-Context-Autosave avec la découverte de quelques commandes inconnues :

 

Trois commandes ont attiré mon attention :

• Disable-AzureRmContexteAutoSave
• Enable-AzurermContextAutosave
• Get-AzureRmContextAutoSaveSettings

J’ai donc commencé par Get-AzureRmContextAutoSaveSettings avec une surprise. Mes tokens sont bien conservés dans mon profil, c’est la configuration par défaut.

 

En ce qui me concerne, d’un point de vue sécurité, c’est moche. D’une part, je me balade avec les tokens de mes clients (MFA n’est pas encore chez tous et cela ne résout pas toujours le problème). C’est dommage qu’on fasse attention à utiliser des navigateurs en mode privé pour se connecter à Azure si le module PowerShell ignore le même ce concept. D’autre part, cela induit un risque. J’ai tendance à utiliser beaucoup de scripts chez mes différents clients. Avec cette fonctionnalité, je risque de travailler sur la mauvaise souscription sans m’en rendre compte avec un impact tout aussi industriel que le script.

Pour cette raison, j’ai pris l’habitude de désactiver cette fonctionnalité avec la commande Disable-AzureRmContextAutoSave comme illustré ci-dessous :

 

Maintenant, il n’y a plus de risque pour moi.

 

Benoît – Simple and secure by design but Business compliant

De temps en temps, j’ai des clients avec des challenges. Quand on mélange Azure et PowerShell, il y a risque que je réponse présent (même si finalement, je vais me faire mal). Je vous partage donc le challenge du moment. Un de mes clients est en phase de montée en puissance sur Azure avec une exigence, un contrôle strict des flux réseaux entrants et sortants, tout comme il le pratique On-Premises. Tout de suite, ça va faire beaucoup des règles dans les Network Security group. Autant dire tout de suite que le portail ne va pas être d’une grande aide sur le sujet.

Challenge intéressant, challenge Accepté, voici AzureImportNSG.PS1. Ce script PowerShell permet de :

• Créer l’objet Network Security group (réalise une sauvegarde si existe déjà pour le rollback)
• Injecter les règles en provenance d’un fichier XML
• S’assure de la mise en place de la journalisation des flux dans votre instance Log Analytics préférée

Que reste-t-il à faire alors ? Juste lier le Network Security group à l’objet Subnet. Simple and Secure by design ! Et comme il faut pouvoir retravailler les règles, s’il y a un script d’import, il y a aussi un script d’export pour générer notre fichier XML.

Avec cela, plus d’excuse pour ne pas avoir des réseaux en béton. Les deux scripts sont disponibles sur mon repo GitHub.

Benoît – Simple and secure by design but Business compliant