Faciliter l’accès à la facture Azure

Azure, ce n’est pas que pour les IT-Pro, Dev ou Dev-Ops, c’est aussi pour le DAF. C’est lui qui paie la facture. Or jusqu’à il y a quelques jours, pour permettre à un DAF d’accéder à la facture Azure, il devait avoir les privilèges les plus élevés sur la souscription. Lui donnant aussi le droit d’annuler la souscription. Or, la première chose que demande le DAF, c’est de pouvoir accéder simplement à la facture.

Depuis quelques jours, c’est maintenant possible. Dans la gestion des souscriptions, on dispose d’une rubrique « Send my Invoice » comme illustré ci-dessous :

clip_image001

Ne reste plus qu’à référencer une adresse mail de destination et vos pourrez enfin répondre à la première demande de votre DAF.

clip_image002

Attention, je dis bien la première demande de votre DAF. Après il reviendra avec beaucoup d’autres questions tel que :

Pour la dernière, faudra passer un niveau de comptabilité avec comptabilité analytique.

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

Découverte Azure Queue

Dans mes projets Azure, j’accompagne souvent des clients qui migrent leurs applications vers Azure. Ces applications sont souvent organisées en front-end / back-end. Généralement, ça prend le forme d’un serveur web IIS/Apache pour la partie frontale et SQL Server / MySQL pour la partie back-end. D’un point de vue technique, il est tout à fait possible de migrer l’application dans Azure tel que. Pour une migration rapide, cela fonctionne. Par contre, il ne faut pas se leurrer, on aura des problèmes de scalabilité. Augmenter le nombre d’instance (scale-out) du composant frontal ne pose pas de problème particulier. Par contre, pour le composant dorsal, c’est un peu plus compliqué. On va être limité au Scale-Up. Or, si on multiplie le nombre de composants Front-end en conservant une unique instance du composant back-end (quel que soit la taille de l’instance), ça va pas le faire. Rien que la saturation des ports TCP, ça va être fatal.

C’est là qu’il est intéressant de passer un peu de temps dans les Design Patterns du Cloud (Azure). Un des Design Patterns va nous intéresser, celui nommé Queue-Based Load leveling. Le mécanisme de la Queue permet de jouer le rôle de buffer entre les multiples instances de notre composant frontal et notre unique composant dorsal. Cette approché permet de réduire l’impact de pics de charge et la disponibilité de notre application.

clip_image001

Dans le contexte de notre application, nous allons donc avoir de multiples instances qui vont déposer des messages dans une file d’attente qui sera dépilée par la partie back-end. Toujours dans les Design Patterns, on en trouve un très intéressant : Competing Consumers Pattern.

clip_image002

Si on arrive à introduire un service qui traite les messages déposés avant d’attaquer la base de données, on autoriser le traitement des messages en parallèle, augmentant la puissance de traitement tout en offrant scalabilité, disponibilité pour notre application. Voilà pour la théorie. Passons maintenant à la pratique dans Azure. Dans Azure, nous avons deux services de queues mis à notre disposition :

  • Azure Queues
  • Azure Service bus Queues

D’un point de vue technique, on peut dire qu’Azure Queues est la version basique et Azure Service bus Queues la version haut de gamme capable de gérer :

  • Des messages de plus grande taille
  • Une file d’attente de plus grande taille

Pour illustrer le propos, regardons ce qu’on peut faire avec la fonctionnalité Azure Queue qui est un sous-composant du Storage Account. On va commencer par se créer un environnement avec un groupe de ressources avec un Storage Account :

New-AzureRmResourceGroup -Name StorageQueue -Location « West Europe »

New-AzureRmStorageAccount -ResourceGroupName StorageQueue -Name storagequeuetp -Location « West Europe » -SkuName « Standard_LRS » -Kind Storage

clip_image003

 

Maintenant, nous avons juste besoin de récupérer la clé primaire d’accès à notre Storage Account pour générer une clé de contexte SAS et générer notre file d’attente :

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName storagequeue -Name storagequeuetp

$context = New-AzureStorageContext -StorageAccountName storagequeuetp -StorageAccountKey $keys[0].value

New-AzureStorageQueue -name « tpabc » -Context $context

$Queue = Get-AzureStorageQueue -Name « tpabc » -Context $context

clip_image004

 

Positionnons-nous du côté de l’émetteur des messages, la partie front-end de notre application. En PowerShell, ce n’est pas aussi simple. Faut jouer un peu avec Dot.Net.

$message = New-Object -TypeName Microsoft.WindowsAzure.Storage.Queue.CloudQueuemessage -ArgumentList « Message à stocker dans la queue »

$Queue.cloudqueue.AddMessage($Message)

$Queue = Get-AzureStorageQueue -Name tpabc -Context $context

$Queue

clip_image005

 

En actualisant la variable $Queue, on constate que l’on a bien un message déposé dans la file d’attente. Maintenant, plaçons nous coté Back-End de l’application et dépilons les messages reçus

$InvisibleTimeout = [System.TimeSpan]::FromSeconds(10)

$dequeuemessage = $queue.cloudqueue.getmessage($InvisibleTimeout)

$dequeuemessage

clip_image006

 

Nous n’avons fait que lire ce message. Une fois le message traité, nous devons le supprimer de la queue :

$Queue.CloudQueue.DeleteMEssage($dequeuemessage)

$Queue = Get-AzureStorageQueue -Name tpabc -Context $context

$Queue

clip_image007

 

Constat : le compteur est revenu à 0.

Conclusion, migrer une application dans le Cloud ne la rend pas « Cloud native ». Cela implique bien souvent de la repenser en fonction des différents Design Patterns. Ça sert de venir à mes cours Azure. Que du TP custom avec des vrais morceaux de projets Azure.

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’AD FS Rapid Restore Tool

Avec le Cloud, il y a toujours des passages obligés. Après avoir convaincu les acteurs réticents (DAF, RSI/RSSI), le sujet de l’identité arrive en tête de liste avant même les aspects réseau. Avec en plus le Règlement Général sur la Protection des Données qui pointe le bout de son nez en 2018, autant dire que le sujet identité dans Azure est un sujet Top priorité. Pour un certain nombre de mes clients, cela implique la mise en œuvre d’une infrastructure ADFS (ou la migration) vers une version plus récente (genre Windows Server 2016). C’est pendant l’une de ces migrations que j’ai découvert un outil nommé AD FS Rapid Restore Tool. Au premier abord, j’ai pensé que l’outil était juste un outil de sauvegarde / restauration de configuration ADFS (ce qui est déjà très bien). Une fois installé, cela prend la forme d’un module PowerShell :

Import-Module ‘C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll’

Get-Command | where {$_.Source -like « ADFSRapidRecreationTool »}

clip_image001

Si on creuse on peu, on est tout de suite intéressé par certaines fonctionnalités. Normalement, cela devrait vous sauter aux yeux.

clip_image002

En plus, coté mise en œuvre, ça tient en une seule ligne de PowerShell

Backup-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSBACKUP\” -EncryptionPassword “P@ssw0rd1234” -BackupComment “Clean Install of ADFS (FS)” -BackupDKM

clip_image003

La seule limite, c’est la capacité à exporter la clé privée de votre certificat. La même avec de la bonne volonté, il ne peut pas le faire. Par contre toute la configuration de votre infrastructure ADFS, sa base de données, tout est disponible sous la forme d’un package prêt à l’emploi pour une restauration. C’est bien plus efficace qu’un snapshot ou une sauvegarde du System State.

Là où le process est super intéressant, c’est qu’on peut aussi l’utiliser pour reconfigurer une infrastructure ADFS existante. Dans mon cas, je voulais basculer la base de données depuis des instances Windows Internal Database vers un véritable serveur SQL.

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSBACKUP\” -DecryptionPassword “P@ssw0rd1234” -ADFSName “adfs.simplebydesign.fr” -DBConnectionString “data source=fox.adfslab.local;initial catalog=adfsconfiguration;integrated security=true” -GroupServiceAccountIdentifier “ADFSLAB\MSAADFS$”

type c:\users\FOX.ADFSLAB\AppData\Local\ADFSRapidRecreationTool\PostRestore_Instructions01022017-213311.txt

clip_image004

OK, ça ne restaure pas non plus les fournisseurs d’authentification forte tiers (RSA, Gemalto, …). En même temps, je n’en ai pas besoin mon client a commandé l’utilisation de Windows Hello comme mécanisme d’authentification forte à son père noël. La configuration une fois restaurée est immédiatement opérationnelle.

Get-AdfsProperties | select ArtifactDbConnection

clip_image005

Un seul petit bémol à ce niveau, si la collation de votre nouvelle instance SQL n’est pas celle que vous vous attendez mais une version localisée, pensez à personnaliser la chaine de connexion SQL, sinon cela ne fonctionne pas. Pour les « Old School comme moi », avant la migration cela ressemblait à un truc comme cela :

clip_image006

Au passage, il ne faut pas oublier comment cela marche car c’est toujours comme cela qu’on va basculer les serveurs secondaires de la ferme, …

L’outil est compatible Windows Server 2012, Windows 2012 R2, Windows Server 2016, donc tout de suite utilisable pour une migration.

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

ADFS 4.0 – subtilité de la page de logon

Pour finir l’année en beauté, j’ai un ADFS 4.0 à me mettre sous la dent. Une simple évolution du 3.0 inclus dans Windows Server 2012 R2 que je me suis dit. ADFS, je le connais depuis la version 1.1. Ça fait longtemps qu’on se côtoie. Jusqu’à maintenant, dans sa mise en œuvre, j’avais toujours pris l’habitude d’inclure une étape de validation après l’installation du premier serveur ADFS de la ferme, histoire de bien démontrer que ça fonctionne avant de continuer. Là j’ai eu une surprise :

clip_image001

Derrière, dans les logs, j’ai trouvé ça :

clip_image002

Intéressant. C’est en creusant le sujet en passant sous la moquette que j’ai découvert la présence du paramètre EnableIdPInitiatedSignonPage dans les propriétés du Get-AdfsProperties.

clip_image003

Par défaut, la page de la mire de logon est désactivée. C’est con mais quand on veut tester que son infrastructure fonctionne, on commence par le plus basique : La page de logon. Une fois réactivée, cela fonctionne tout de suite mieux.

 

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

Migration CSP : Notes from the Field

Voilà un sujet qui m’occupe beaucoup en ce moment, migrer des clients vers des souscriptions Azure CSP. Je reviendrais bientôt sur le processus et les pièges à éviter mais tout de suite, je voulais partager un détail post-migration, quand on pense avoir fait le plus dur, on peut encore avoir des problèmes.

En préparant la migration de mon client, j’avais identifié un composant non éligible à la migration : SendGrid. C’est un composant d’un partenaire qui permet d’envoyer des mails. Le client l’utilise dans son application. Dans sa souscription « Pay As You Go », le client est bien capable de souscrire à ce service :

clip_image001

Coté CSP. Pour que ce composant puisse être utilisé, il faut un Resource Provider. Ça tombe bien, il est bien disponible dans CSP, il fallait juste l’activer.

clip_image002

Le problème, c’est que même si le portail Azure propose la ressource et que le Resource Provider est bien enregistré, cela ne veut pas dire que la dite ressource est réellement disponible dans une souscription CSP.

clip_image003

Le portail Azure nous indique clairement que ce type de ressource n’est pas disponible dans une souscription CSP, alors que la même ressource est tout à fait disponible dans la même région Azure dans une souscription « Pay as You Go ».

Conclusion, méfiez-vous des ressources qu’on ne peut pas migrer avec CSP, elles peuvent réserver des surprises. Incident ouvert auprès de Microsoft, …

­

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

Mais qui est le Dédé qui a fumé 3k dans ma souscription Azure?

OK, le titre est racoleur mais, c’est comme cela que le problème m’a été présenté par un ancien collègue ce vendredi soir. Il se reconnaîtra :). Recherche désespérément quel Dédé a fumé le crédit de ma souscription Azure. Le billing et le contrôle budgétaire sont bien souvent les dernières roues d’un projet de transformation numérique. Pourtant, le DAF a son mot à dire dans le domaine. Quand on leur vante les promesses du Cloud, on leur vante la capacité à maîtriser ses couts. Ça se complique quand sa réponse est OK, montrez-moi avec un cas concret : Retrouvez-moi à qui affecter une dépense inconsidérée sur ma facturation et comment m’en prémunir, … La autant vous dire que développer un argumentaire uniquement basé sur la calculatrice Azure est voué à l’échec.

Pour répondre à la question de mon ex-collègue (et celle d’un DAF), c’est possible. Toute plateforme cloud qui se respecte doit être en mesure de produire des métriques précises de l’usage de ses différents services afin de pouvoir facturer l’usage des services consommés. Autant vous dire tout de suite que ce n’est pas la partie la plus sexy d’Azure mais à moins que vous ne vouliez avoir un auditeur vous demander de justifier vos dépenses en crédit Azure, … A vous de voir.

Ce qui nous intéresse, ce ne sont pas réellement les métriques de services consommés. Première question : Est-ce la consommation d’un service produit par Microsoft ou par l’un de ses partenaires ? La question a son importance. Si c’est de la consommation de services Azure Microsoft, on va rechercher de la consommation excessive. Dans ce cas, c’est le billet Découverte d’Azure Resource Policy qui vous aidera à éviter que cela ne se reproduise. Par contre, si c’est un service externe, on trouvera la solution dans le portail à la rubrique « External Services » de la souscription. Dans l’illustration ci-dessous quelques expériences passées sur une de mes souscriptions :

clip_image001

 

J’ai été joueur en tentant de provisionner une appliance virtuelle F5 Big-IP. Heureusement pour moi, j’avais annulé l’opération rapidement. Même si j’ai rapidement supprimé la ressource, on a quand même la trace de l’acte d’achat. Dans mon cas, si on n’a pas le groupe de ressources on a au moins la date d’achat. C’est tout ce dont nous avons besoin pour commencer notre enquête.

clip_image002

 

La plupart du temps on ne se rend pas compte, mais la différence on la voit au moment du déploiement dans le portail avec un onglet « Buy » comme illustré ci-dessous :

clip_image003

 

Dans l’illustration ci-dessus, on a même le cas de la « Double Peine » avec la ressource F5 BIG-IP. On paie pour le compute mais aussi pour la licence payée à F5 passé les trente jours de découverte. BYOL, c’est Bring Your Own License. C’est là que le comportement diffère selon le type de votre souscription. Dans mon cas, il m’est clairement que mon crédit Azure ne peut être utilisé pour acquérir ce type de produit (BYOL). Même s’il me coute 0€ (pour l’instant), c’est un service externe. Ce comportement est lié à ma souscription. Sur une souscription de type Enterprise Agreement, c’est une décision que le propriétaire du contrat va prendre et configurer dans son portail.

 

Note : Il arrive de temps en temps que même des produits Microsoft soient considérés comme du « External services ». Non, ce n’est pas une blague.

 

Maintenant que les présentations sont faites, voyons comment traquer le coupable, même s’il a tenté de cacher son méfait en supprimant le groupe de ressources la semaine dernière. Ce qui est bien avec le Cloud, c’est que pour être facturable tout service est nécessairement mesurable, il faut juste savoir quelle opération rechercher dans les Aure Logs. Dans le cas qui m’occupe, c’est de trouver qui a bien pu provisionner ce F5. Dans qu’on parle de log Azure, c’est le module PowerShell « AzureRm.Insights » qui va nous intéresser :

clip_image004

 

Immédiatement, on localise une commande Get-AzureRMLog. Elle va tout nous dire. On va être sélectif et lui demander uniquement les actes d’achat sur le MarketPlace :

Get-AzureRMLog | Where {$_.OperationName -eq »Microsoft.Resources/marketplace/purchase/action »}

clip_image005

 

D’où sort mon filtre ? Facile, lors de l’étape de validation d’un déploiement dans Azure, on a la possibilité de consulter le template ARM. J’ai donc demandé le déploiement de services externes. On a deux lignes. La première indiquant clairement l’acceptation du déploiement. Bonne nouvelle, on connait maintenant le nom du Dédé qui a fumé nos 3K€. Quand on lui a dit acheter, il a cliqué sur le bouton « OK » sans même lire les recommandations. La seconde, c’est que le déploiement a été autorisé, que le crédit Azure a pu être utilisé ou que sa Carte de crédit est toujours valide, …

On a les actes d’achat. Ce qui nous manque, c’est de retrouver ce qui a été déployé avec. Après tout, il peut avoir commandé le déploiement d’une ressource de type ClearDB. Ce que je recherche, c’est l’acte d’achat pour du F5 Big-IP. A partir de cette entrée de l’Azure Log, on va rechercher toutes les autres entrées qui y sont liées. On va donc jouer un peu avec PowerShell :

$Logs = Get-AzureRmLogs

$Logs | Where {$_OperationName -eq « Microsoft.Resources.MarketPlace/Action »}

clip_image006

 

Ce qui va m’intéresser maintenant, c’est de retrouver l’opération « Microsoft.Resources/deployments/write » qui va avec cet acte. Pour cela, on va utiliser le CorrelationID pour faire le lien.

$CorrelationID = ($Logs | select -first 1).CorrelationId

$CorrelationID

$Logs | Where {$_.CorrelationID -eq $CorrelationID} | Where {$_.OperationName -eq « Microsoft.Resources/deployments/write »}

clip_image007

 

Ca y est, on a trouvé le coupable, on va pouvoir le présenter au bourreau (auditeur) au lieu de monter nous-même sur l’échafaud en tant que coupable par négligence. Là nous ne parlons que de 3k€. Imaginez que demain, on recherche qu’elle est la buse intergalactique qui a provisionné un truc bien plus gros. Disons un SAP HANNA déployé sur des instances de machines virtuelle de type G5.

Maintenant, les mauvaises nouvelles. La capacité à exporter les logs d’Azure est limitée. Dans le portail, on peut extraire l’activité des 90 derniers jours alors qu’en PowerShell on est limité à 15. Ceci amène deux recommandations :

Pour finir, quelques conseils pour vous éviter de passer vos journées en face d’un auditeur financier (ce ne sont pas les personnes les plus drôles). Dans une souscription de type Enterprise Agreement, vous avez des rapports de suivi de consommation, utilisez-les au lieu d’attendre que la prochaine facture n’arrive. S’il y a un pic e consommation, il doit être lié à un projet (Idéalement les ressources sont mêmes taguées).

clip_image008

 

Toujours dans une souscription Enterprise Agreement, vous avez la possibilité de faire parler ces données via Power BI, ne nous en privez pas. L’auditeur sera ravi qu’on mettre à sa disposition de type d’outil.

clip_image009

 

Pour finir. Faire du Cloud, ce n’est pas uniquement s’adresser aux IT-Pro, Dev ou aux métiers en vantant les possibilités infinies de la plateforme. En face de vous, il y a deux acteurs qui vous attendent au tournant :

  • Le contrôle de gestion : Vous avez promis une maîtrise des coûts, prouvez-le sinon ils vont atomiser notre nouvelle agilité avec une quantité de processus contrôles sans fin
  • Le RSSI : Vous avez promis un meilleur contrôle de la sécurité. Lui sa préoccupation actuelle c’est le RGPD et comment vous-vous allez-vous y conformer ASAP.

Tu fais du cloud sans impliquer le contrôle de gestion ? Mais allo quoi?

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

Le Cloud est un perpétuel recommencement

Le Cloud, c’est une infrastructure et des services en perpétuelle évolution. Dans Azure, historiquement dans les machines virtuelles, on avait la Série A. Avec le temps Microsoft a étoffé son service IaaS en proposant de nouvelles configurations. Avec l’arrivée de la série D, on avait 60% de performances en plus. A cette époque, l’étude comparative de Cloud Spector démontrait l’intérêt de réaliser des migrations technique (qui en plus apportaient un gain financier). Avec DV2, la promesse de Microsoft est de 35% de performance en plus pour un prix inférieur de 5%. Cloud Spector a mis à jour son étude, comparant la série DV1 avec la nouvelle offre DV2.

Bref, ce que nous avons mis en production devra nécessairement être réévalué. Certes, on bénéficie de la baisse continue des prix. A chaque fois qu’un des grands acteurs du Cloud baisse les prix, les autres s’alignent ou surenchérissent. C’est en réévaluant nos besoins par rapport aux nouvelles capacités de la plateforme qu’on peut réaliser les meilleures optimisations techniques et financières. Avec la Série Av2, l’histoire recommence.

Prochainement, c’est notre approche de la haute disponibilité que nous allons devoir remettre en cause. Historiquement, le seul moyen que nous avions de garantir la disponibilité d’une machine virtuelle (et donc un SLA de la part de Microsoft) passait par les Availability Set qui permettait de répartir deux ou plusieurs instances de notre machine virtuelle dans des domaines de panne et des domaines de maintenance distincts. Grand merci à l’article de Samir Farhat sur le sujet. Avec cette nouvelle fonctionnalité, la haute disponibilité dans Azure deviendra beaucoup plus abordable. Certes, je ne pense pas que cela concerne tous les workloads et qu’il faudra par exemple continuer à utiliser des Availability Sets pour un cluster SQL en Always-On. Comme l’indique Samir Farhat, beaucoup de clients ont refusé de migrer certains workloads à cause des contraintes financières de la haute disponibilité dans Azure.

Plus généralement, dans le Cloud, la notion d’état stable n’est qu’une notion temporaire entre deux cycles d’optimisations techniques & financières.

clip_image001

Notre problème, ce sera de savoir comment évaluer les opportunités techniques et financières qui se présentent à nous. Si on regarde une plateforme comme Microsoft Azure, en 2015, c’est plus de 500 nouveaux services ou évolutions de services mis à disposition des clients. Evaluer toutes les possibilités d’évolution qui se présentent à nous n’a pas de sens :

  • Une évaluation individuelle pour chaque application ne fera que complexifier chaque application
  • Une évaluation individuelle augmentera le nombre de service distincts à gérer et ne va pas aller dans le sens de la gouvernance

Nous n’allons donc pas évaluer toutes les possibilités mais retenir un ensemble de fonctionnalités qui peuvent être généralisées pour un ensemble de workloads. Plus nos workloads pourront partager de services et fonctionnalités en commun, il deviendra simple de profiter des effets d’échelle aussi bien du point de vue de la performance que des prix. Conclusion, le Cloud, ce n’est pas qu’une transformation technique, c’est aussi une transformation de la manière dont nous allons organiser ceux-ci ainsi que l’organisation pour les gérer. C’est une nouvelle approche de l’infogérance qui se dessine.

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (3/3)

Maintenant, les détails qui comptent. On a noté que notre certificat a une durée de vie de trois mois. Mais comment alors sera-t-il renouvelé ? Réponse, grâce à un WebJob. Le problème, c’est qu’au terme de la mise en œuvre, ce WebJob est arrêté, donc aucune possibilité que le renouvellement automatique fonctionne.

clip_image001

 

Une fois démarré, ce sera beaucoup mieux.

clip_image002

 

Par ce que le diable se cache toujours dans les détails, essayons de lire les logs associés à la Web Extension Lets’ Encrypt. Il doit manquer quelque chose :

clip_image003

 

Ce qui manque, c’est un repository pour déverser les logs. Ce que nous dit le message, c’est que la configuration de la Web Application ne fournit pas les informations nécessaires pour la Web Extension. Ça tombe bien, j’avais justement prévu un compte de stockage pour cela :

Get-AzureRmStorageAccount -ResourceGroupName DemoLetsencrypt -StorageAccountName DemoLetsencryptlogs

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName DemoLetsEncrypt -StorageAccountName DemoLetsEncryptLogs

clip_image004

 

Ce qui nous reste à faire, c’est de formater convenablement les informations dans cela dans une Application Settings nommé :

AzureWebJobsDashboard avec le contenu suivant :

DefaultEndpointsProtocol=https;AccountName=DemoLetsencryptlogs;AccountKey=<Contenu de ma clé primaire>;

clip_image005

 

Au passage on découvre que les paramètres que nous avons renseignés lors de la configuration de la Web Extension. Ne reste plus qu’à les sauvegarder et redémarrer le Web Job. Si la chaine de connexion est correctement formatée, alors, on devrait trouver la journalisation de l’extension dans le Storage Account que nous avons provisionné lors de la mise en place des prérequis.

clip_image006

 

Si on regarde dans la WebJob elle-même, on peut consulter ses logs directement à ce niveau.

clip_image007

 

Au passage, les logs vont vous apprendre un dernier truc. Pensez à activer l’option « Always-On » sinon en cas de crash du compute qui porte notre Web App, notre WebJob ne redémarre pas automatiquement. Donc pensez à activer cette option.

clip_image008

 

Voilà ce qui clos notre mise en œuvre de Let’s Encrypt dans le Paas Azure.

­

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (2/3)

Après la mise en place des prérequis, passons à la configuration de Let’s Encrypt. Techniquement c’est une extension de la Web Application. C’est un plug-in que l’on va venir positionner.

clip_image001

 

Une fois l’extension ajoutée, on la retrouve dans la liste.

clip_image002

 

En cliquant sur la Web Extension, on peut avoir quelques informations et surtout l’accès au bouton « Browse ».

clip_image003

 

On obtient ainsi l’accès à la page de configuration de la Web Extension. C’est maintenant que cela commence à devenir intéressant.

clip_image004

 

Pour le premier paramètre, c’est simple, c’est notre tenant Azure Active Directory. La Web Extension va avoir besoin d’importer le certificat nouvellement généré dans la configuration de la Web Application. Le problème, c’est qu’une Web Extension n’a pas d’identité au sens propre. On va donc avoir besoin de lui en créer une. On y viendra. Pour l’instant, on a juste besoin du Tenant Azure Active Directory.

clip_image005

 

Pour le SubscriptionID, on va le retrouver simplement avec la commande Get-AzureRmContext :

clip_image006

 

C’est maintenant que cela se complique. Première chose dont on va avoir besoin, c’est le nom sous lequel la Web Application va se présenter à l’authentification devant le tenant Azure Active Directory. Avec un peu de PowerShell, on va extraire l’information :

$WebApp = Get-AzureRmWebApp -ResourceGroupName DemoLetsEncrypt

$WebApp

clip_image007

 

Ce qui va nous intéresser plus précisément c’est le hostname sous lequel le site web va être référencé comme application dans Azure Active Directory.

$WebApp.Hostnames

$Uri = $WebApp.HostNames | Select -Last 1

$Uri

clip_image008

 

$Uri = « https://$($uri)« 

$AppName = « DemoLetsEncrypt »

$Password = ‘{P@ssw0rd123}’

$NewApp = New-AzureRmADApplication -DisplayName $AppName -HomePage $uri -IdentifierUris $uri -Password $password

$NewApp

clip_image009

 

Il ne nous reste plus qu’à créer un nouveau Service Principal (un peu compte un compte de service du vieux temps du On-Premises) :

New-AzureRmADServicePrincipal -ApplicationId $Newapp.ApplicationId

clip_image010

 

Puis de lui affecter des permissions sur notre application nouvellement créée :

New-AzureRmRoleAssignment -RoleDefinitionName « Contributor » -ServicePrincipalName $NewApp.ApplicationId

clip_image011

 

Dernière chose dont nous allons avoir besoin, c’est l’ApplicationID associé à notre nouvelle application :

$NewApp.ApplicationId

clip_image012

 

Pour finaliser la configuration, nous avons juste besoin d’une permission pour l’application sur la Web Application

clip_image013

 

Si vous creusez un peu vous découvrirez les permissions minimales nécessaires pour cela. Prochaine étape, configurer les permissions sur le groupe de ressources ou plus précisément sur la Web Application.

clip_image014

 

Reste plus qu’à cliquer sur le bouton « Next ». Si les permissions sont les bonnes alors cela devrait fonctionner. L’extension est bien configurée mais pour l’instant le certificat n’est pas encore généré.

clip_image015

 

Pour générer notre certificat, il manque quelques informations. Cliquons donc sur le bouton « Next ». La première, ce sera de sélectionner le hostname pour lequel nous allons générer le certificat. Au moment de la rédaction de cet article, Let’s Encrypt ne propose pas encore la prise en charge des certificats Wildcard (bientôt).

clip_image016

 

Pour délivrer un certificat, nous avons besoin de fournir une adresse de messagerie et cliquer sur le bouton « Request and Install certificate ».

 

Remarque : Let’sEncrypt impose une limite, celle de ne de délivrer que cinq certificats par semaine pour un même domaine DNS. Il faudra utiliser le staging slots pour contourner cette limitation.

 

C’est l’heure du tour de magie. Si tout se déroule sans accros (un bon plan), alors nous devrions avoir le résultat ci-dessous :

clip_image017

 

Remarque : Faites attention à la date d’expiration du certificat. Oui, les certificats délivrés par l’autorité Let’s Encrypt ont une durée de vie de trois mois. Nous allons y revenir.

 

Nous pouvons revenir sur l’interface du portail Azure et constater la présence du certificat dans la Web Application

clip_image018

 

Ne nous reste plus qu’à mettre en place le binding

clip_image019

 

Le binding est maintenant en place

clip_image020

 

Et effectivement, le site web répond bien en HTTPS sur le Custom Domain configuré.

clip_image021

 

Au passage, le truc est propre puisque voilà le résultat au test SSL de Qualyst :

clip_image022

 

Maintenant, plus d’excuse pour les développeurs à continuer d’utiliser des certificats auto-signés. Il ne nous reste plus qu’à gérer les points de détails.

 

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (1/3)

Le cloud, c’est un jeu de lego. Pour produire un service, on va combiner différents services. Ce qui est intéressant, c’est qu’il n’y a pas une seule combinaison mais bien plusieurs. Plus les Plateformes développent leurs services, plus on dispose de nouvelles combinaisons.

Dans ce jeu de Lego, on retrouve souvent des certificats. Lors du déploiement de solutions dans Azure, on va utiliser des solutions comme Azure Key Vault pour y stocker nos certificats. C’est un sujet que j’ai déjà évoqué dans plusieurs billets sur Azure Key Vault. Dans Azure, on peut aussi demander de générer nos propres certificats avec le App Service Certificate. Ce service permet de générer automatiquement (ainsi que renouveler) nos certificats. Au moment d’écrire ce billet, le service App Service Certificate ne propose que GoDaddy comme fournisseur. C’est une démarche intéressante mais pour nos développeurs, c’est une solution payante. En toute logique, nos développeurs vont se tourner vers des certificats auto-signés (beurk). Pourtant, en creusant un peu dans les tréfonds des Web Application, on peut trouver des solutions bien plus élégantes. Le projet Let’s Encrypt et celle-ci et est disponible sous forme de Web App Extension dans les App Services. C’est un peu moins intégré que le App Service Certificate mais ce n’est pas impossible à mettre en œuvre. C’est le sujet de ce billet : Comment utiliser la solution Let’s Encrypt avec Paas App Service. Ce billet sera organisé en plusieurs parties :

Dans mon introduction, j’ai parlé de Web Application. Donc logiquement on connait déjà les prérequis ou presque :

  • Un groupe de ressources histoire de regrouper nos ressources.
  • Un Service Plan qui va porter notre Web App (subtilité, il nous faudra un Service Plan nous autorisant d’utiliser le SSL et les Custom Domains)

 

Commençons par créer notre groupe de ressources avec simple ligne PowerShell :

New-AzureRmResourceGroup -Name « DemoLetsEncrypt » -Location « West Europe »

clip_image001

 

Ci-dessous la configuration retenue pour la Web Application.

clip_image002

 

Dans ma configuration, je n’ai pas retenu d’implémenter App Insight. A l’heure où j’écris ce billet, App Service est encore en Preview et pas disponible dans toutes les régions Azure. La subtilité, c’est le choix de l’App Service Plan. J’ai retenu le plan B1 qui est le premier à proposer le support des Custom Domains ainsi que celui des certificats.

clip_image003

 

Avec un peu de PowerShell, on peut retrouver les ressources provisionnées :

Get-AzureRmResourceGroup -Name DemoLetsEncrypt | Find-AzureRmResource

clip_image004

 

Avant de poursuivre, on va mettre en place les prérequis pour le Custom Domain. Dans ma zone DNS « Simplebydesign.fr », j’ai créé un enregistrement CNAME pour le nom « DemoLetsEncrypt » qui pointe sur le nom DNS Azure de mon site « demoletsencrypt.azurewebsites.net ». Pour instant le site ne répond qu’au seul hostname « demoletsencrypt.azureWebsite.Net ». On va juste lui en adjoindre un nouveau :

clip_image005

 

Si on n’a pas été patient dans la propagation de la zone DNS, cela va échouer. A noter que dans Azure, on peut contourner ce genre de problème et obtenir un service plus intégré en utilisant le service DNS d’Azure. Techniquement, un sous-domaine DNS de la zone « simplebydesign.fr » serait délégué au service Azure DNS qui se chargera de la gestion de cette zone. Avec cette approche, nous pourrons créer l’enregistrement DNS depuis Azure et nous assurer de sa propagation dans les secondes qui suivent mais revenons à notre billet. Lorsqu’on est patient, cela fonctionne.

clip_image006

 

Quelques secondes plus tard, notre site web répondra à son nom Azure mais aussi à son nouveau Custom Domain

clip_image007

 

Dernière étape dans nos prérequis, la mise en place d’un Storage Account. Nous allons en avoir besoin avec Lets’Encrypt pour permettre à la Web Extension d’y déverser ses logs :

New-AzureRmStorageAccount -ResourceGroupName « DemoLetsEncrypt » -AccountName « demoletsencryptlogs » -Location « West Europe » -SkuName « Standard_LRS » -Kind « Storage »

clip_image008

 

Remarque : Pour faire simple, j’ai utilisé un Storage Account standard, je n’ai pas cherché à optimiser avec du stockage chaud/froid. Ce n’est pas le but de ce billet.

 

Voilà pour les prérequis à la mise en œuvre de la Web Extension de Lets Encrypt. Prochaine étape, son installation et sa configuration.

 

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