Archives de catégorie : Réflexions

Contrôle budgétaire dans Azure

Lors de mes formations sur Azure, il y a un sujet qui revient régulièrement : Est-on capable de répondre aux exigences d’un DAF qui demande un contrôle budgétaire stricte. Autant vous dire qu’essayer d’argumenter avec de la technique. Genre : Maintenant dans Azure on peut envoyer la facture au DAF par mail, ça ne va pas le faire du tout, …

clip_image001

 

Sans contrôle, le Cloud ne sera qu’une promesse non tenue. Problème, le DAF détient les cordons de la bourse. Si nous ne sommes pas capables de répondre à cette simple question, l’expérimentation Cloud va tourner court. Histoire de poser le décor, voilà une liste des risques auxquels nous devons répondre :

  • Comment limiter la consommation pour une population donnée ?
  • Pouvons-nous accorder un crédit à une population donnée ?
  • Comment suivre facilement l’évolution de la consommation ?

 

Malheureusement, il n’y a que dans le cadre d’une souscription de type Enterprise Agreement qu’on est capable de répondre à ces problématiques :

  • La segmentation en départements avec un budget permet de répartir le crédit Azure
  • Chaque département se voit affecté un crédit qu’il est libre de consommer, charge à l’administrateur de le suivre
  • Le suivi de la consommation est réalisable via l’intégration de Power BI : Microsoft Azure Enterprise content pack for Power BI

 

Voilà pour les grandes lignes d’une souscription de type Enterprise Agreement. Maintenant voyons les moyens dont on dispose pour tous les types de souscription.

Azure Spending Limit

Le premier et le plus ancien de tous est la fonctionnalité Azure Spending Limit. Pour les souscriptions autre que CSP & EA, la fonctionnalité est accessible via l’ancien portail https://account.windowsazure.com. Dans l’illustration ci-dessous, ma souscription « Pass Azure » disposait d’un crédit de 85€ de consommation. Arrivé à 0, la souscription sera automatiquement désactivée. C’est à moi, propriétaire de la souscription de venir supprimer la limite de consommation (et d’indiquer un moyen de paiement).

clip_image002

 

A noter que configurer un moyen de paiement n’est pas obligatoire pour les souscriptions de type « Pay-As you go ». Maintenant, charge au propriétaire de suivre sa consommation, … Pour une souscription de type CSP, c’est le partenaire qui propose ce service en configurant un indicateur qui va l’informer de la consommation de son client. Attention, c’est une limite soft, juste un avertissement.

clip_image003

 

Pour un Enterprise Agreement, c’est un suivi de l’administrateur du département. Une notification par mail lui est automatiquement envoyée chaque semaine.

clip_image004

 

Tagger les ressources

Le premier contact du DAF avec une facture Azure est plutôt violent. Sa première question, c’est comment effectuer un regroupement de ces coûts selon différents critères. Savoir qu’il a payé pour du compute c’est bien mais s’il est capable de le refacturer entre les équipes, on l’aide à définir quelle est la participation de chaque entité de l’entreprise pour le poste budgétaire de l’IT. Attention, on ne parle que de coût IT. Avec le IaaS, on peut assez facilement déduire le nombre d’exploitants nécessaires par rapport au nombre de machines virtuelles et l’utiliser comme clé de répartition pour les couts de personnel. Par contre, ce ne sera plus aussi vrai pour le PaaS, encore moins pour le SaaS.

clip_image005

 

Le simple fait de tagger les ressources ne permet pas de contrôler les coûts. Pour cela, il faut forcer l’usage des tags. C’est là que la fonctionnalité Azure Resource Policy. C’est un sujet que j’avais déjà abordé dans un précédent billet (Découverte d’Azure Resource Policy). Maintenant, la fonctionnalité est présente dans le portail au niveau de la souscription avec bonus en plus quelques policies « built-in » bien pensées :

  • Imposer l’utilisation de Tag (pas de tag, pas de déploiement)
  • Affecter un tag par défaut s’il n’est pas spécifié (Pas de code d’imputation comptable, alors c’est celui de l’IT qui sera utilisé, …)
  • Interdire le déploiement de ressources en dehors des régions Azure sélectionnées
  • Interdire l’usage de certains « Sku » de stockage / machines virtuelles

Après, rien ne vous interdit de développer vos propres policies.

clip_image006

 

Ce qui est bien, c’est que ces Policies peuvent être assignées aussi bien au niveau de la souscription que d’un groupe de ressources. Là on tient une fonctionnalité intéressante puisqu’on se positionne avant même de déployer les ressources. Si on a pensé à mettre en œuvre ce type de fonctionnalité avant même de déployer des ressources dans Azure, on a déjà fait un grand pas pour convaincre le DAF. Maintenant, il faut arriver à lui montrer qu’on est capable de réduire les coûts, …

 

Les Quotas

C’est un des premiers sujets qui remonte au près du support Microsoft, l’augmentation des quotas de votre souscription. Si on peut demander l’augmentation des quotas pour les ressources que nous consommons, nous pouvons aussi demander à en réduire la valeur en fonction de nos besoins.

clip_image007

 

Par contre, attention, c’est un type de contrôle « Soft ». Il suffit d’une demande au support pour faire relever la limite. Ce qui est bien, c’est que la demande est nécessairement tracée, on retrouve donc rapidement celui qui a formulé la demande.

 

La mesure des usages

Mettre en place des Azure Resource Policies ne nous protège pas de tout. En fait, à vouloir tout contrôler, on va perdre en agilité. En plus, on peut passer à côté du plus important : La ressource sera-elle décomptée sur ma consommation Azure ou considérée comme un achat externe ? Dans le portail Azure, lorsqu’on déploie une ressource, si on nous demande de valider un achat, c’est que c’est un achat externe, même si celui-ci coute 0€ comme pour Sendgrid :

clip_image008

J’ai bien pensé à utiliser les Azure Resources Policy pour bloquer les déploiements impliquant des achats externes mais j’ai vite trouvé cela très lourd à mettre en œuvre. Déployer des composants comme le système d’exploitation RedHat ou le composant SendGrid peuvent tout à fait être légitimes. Finalement, c’est en se reposant sur la mesure des usages qu’on sera capable d’adresser ce risque. La simple commande PowerShell ci-dessous nous remonte les déploiements de ressources impliquant une facturation tierce :

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

clip_image009

 

Avec un peu d’industrialisation avec Azure Automation, on devrait être capable d’envoyer un mail au DSI et agir en conséquence. S’il avait demandé à utiliser du Kemp et qu’il se retrouve avec du F5 à la place, il devrait agir rapidement. Le risque est ainsi mieux maitrisé. Si le sujet vous intéresse, je vous renvoie vers un de mes billets sur le sujet : Mais qui est le Dédé qui a fumé 3k dans ma souscription Azure ?

La fonctionnalité Devtest Labs

La fonctionnalité DevTest est vaste. Simplement, c’est un conteneur qu’on met à disposition des développeurs pour générer leurs environnements de dev/test. L’intérêt de la fonctionnalité est de pouvoir rendre le développeur autonome dans ses activités quotidiennes tout en étant assuré qu’on ne va pas exploser les budgets (tout du moins sans en être préalablement notifié). Globalement, cela passe par un certain nombre de fonctionnalités :

  • Limitation fine des machines virtuelles que le développeur peut déployer (limitation des SKU, limitation du nombre d’instance par développeur, …)
  • Capacité à limiter les choix du développeur pour le déploiement de ressources en provenance du Marketplace
  • Capacité à proposer une liste de Custom Images prêtes à être utilisées
  • Mise à disposition d’un coffre-fort numérique pour stocker les secrets utilisés dans l’environnement de développement.
  • Création de « formules de déploiement » pour faciliter la mise en place d’environnements de tests. Ces « formules » peuvent exploiter les secrets du développeur
  • Capacité à fixer une date d’expiration à une machine virtuelle
  • Capacité à réaliser un « auto-shutdown » (ainsi qu’un « auto-Start ») des ressources pour éviter de facturer du compute inutilement.
  • Capacité à limiter les Virtual Networks sur lequel les développeurs peuvent déployer

Ce qui nous intéresse dans la fonctionnalité DevTest, c’est la possibilité de sélectionner les SKU des machines virtuelles mais aussi le contenu issu du Marketplace, aussi bien dans la SKU sélectionnée que le nombre des instances. Un bon argument pour le contrôle budgétaire.

 

Voilà pour les fonctionnalités techniques, maintenant, celle qui trait à la maitrise de la facturation. Pour chaque instance du service DevTest que l’on met en place, on peut définir des seuils de consommation avec pour chaque seuil, la possibilité de notifier mais aussi de déclencher un WebHook.

clip_image010

 

Avec cela, on peut facilement déclencher des actions avec Azure Automation pour éviter les dépassements de consommation. Exemple, arrivé à 95% du montant fixé, on arrête toutes les ressources. Par contre attention, DevTest ne limite pas la consommation. Il se contente de nous indiquer notre consommation actuelle. La mise en place d’une limite de consommation nécessite déjà d’avoir une harmonisation des API de Facturation entre les différents types de souscription.

En jouant avec les fonctions « Auto-Shutdown » et « Auto-Start », on arrive à limiter la facturation des machines virtuelles. Les environnements de développement n’ont pas besoin de fonctionner pendant les week-ends et les nuits en semaine. On peut ainsi économiser jusqu’à 40% de la facture de compute par machine virtuelle.

clip_image011

 

Azure Advisor

Azure Advisor a pour objectif de nous faire des propositions pour optimiser notre usage d’Azure. Les recommandations peuvent porter sur la disponibilité des ressources, la sécurité, la performance ainsi que les coûts.

clip_image012

 

Si Azure Advisor identifie une ou plusieurs ressources (machines virtuelles par exemples) pour lesquelles notre consommation est bien en dessous des capacités mises à disposition, nous serons informés de la possibilité de revoir le sizing de l’instance de la ressource.

Azure Reserved Instances (Update décembre 2017)

La plateforme Azure évolue. Une de ces évolutions est la possibilité de se voir proposer des prix dégressifs pour les machines virtuelles selon une durée d’engagement de un à trois ans. Aucun DAF ne peut rester insensible à 44% de remise, … Azure Reserved Instances – La fonctionnalité la plus simple à expliquer

 

Azure Cost Management (Update décembre 2017)

Microsoft ayant racheté CloudDyn, c’est Maintenant Azure Cost Management et c’est gratuit. C’est donc criminel de s’en passer.

 

Les outils tiers

Plusieurs partenaires de Microsoft se sont positionnés sur le marché des outils de suivi budgétaire sur le Cloud. Dans la liste, on peut citer :

La solution proposée par Microsoft est disponible sur Github. Elle n’est pas aussi complète que les autres solutions qui sont-elles payantes mais elle a le mérite d’exister.

clip_image013

 

La solution Azure usage and Billing portal permet à un client de s’enregistrer auprès de la solution pour autoriser la collecte des données de facturation pour ensuite leur permettre d’y accéder via Power BI. A ce jour, le support des souscriptions de type CSP n’est pas encore généralisé chez tous les éditeurs. CSP utilise actuellement une API de facturation bien spécifique qui nécessite des développements additionnels.

 

Conclusion

Pour conclure, la maîtrise de la facturation passera aussi par la capacité à votre organisation d’adopter la plateforme Cloud de Microsoft. On peut continuer à déployer des machines virtuelles pour héberger des applications mais on ne tire pas pleinement des capacités de la plateforme Azure. C’est l’automatisation et l’utilisation des solutions PaaS et SaaS (plutôt que IaaS) qui feront que le coût de revient dans Azure baissera. L’exploitation implique des coûts humains incompressibles. Cela ne veut pas dire que dans un futur proche nous n’aurons plus d’IT-Pro pour gérer nos ressources dans Azure mais qu’ils deviendront plus efficaces dans la gestion d’un plus grand nombre de ressources.

BenoîtS – 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)

Gabarit de certificat pour utiliser CMSMessage de Powershell 5.0

Honte à moi. Un certificat auto-signé dans mon dernier billet. J’avoue, je l’ai écrit sur mon canapé, et uniquement survolé la page Technet avant de me rendre compte de mon impardonnable erreur. Vu que le Technet ne donne pas les spécifications du gabarit de certificat à utiliser pour ADCS, je m’y colle en pénitence.

Comme base de travail, j’ai retenu le gabarit user. Pourquoi? Car je compte limiter ce type de certificats aux seuls comptes de services membres d’un groupe spécifique. Pas besoin que tous mes systèmes disposent de ce type de certificat. En plus avec ce choix, je vais limiter l’accès à ce certificat aux seuls comptes de service et non la totalité des comptes qui peuvent accéder au magasin personnel de l’ordinateur avec des privilèges administrateur ou supérieur.

Après, vu que pour utiliser la fonctionnalité CMSMessage, il faut PowerShell 5.0, j’ai choisi de limiter les systèmes éligibles en conséquences. Pour installer de Windows Management Framework 5.0, il faut au minimum un système d’exploitation de génération Windows 7 / Windows 2008 R2.

clip_image001

Dans l’onglet général, on nomme notre nouveau gabarit de certificat « CMS Message », pas grand-chose à dire sinon que ça ne sert à rien de publier le certificat dans l’Active Directory dans notre cas.

clip_image002

Dans l’onglet « Request Handeling », une seule chose compte, la capacité à exporter la clé privée. C’est grâce à elle qu’on sera en mesure de déchiffrer notre CMSMessage.

clip_image003

Pour la construction du Subject Name, il y a eu un peu de travail. Par défaut, le gabarit de certificat était prévu pour construire l’attribut en utilisant les informations issues de l’annuaire Active Directory. Bien, mais le problème, il est rare qu’un compte de service ou même un ordinateur se voit affecté une adresse de messagerie. Pour cela, j’ai dû procéder à quelques adaptations :

  • Ne pas inclure l’adresse de messagerie dans l’attribut Alternate Subject Name
  • Ne pas inclure l’attribut E-Mail
  • Ne pas inclure le DNS Name (pas de sens pour un utilisateur)
  • Mais bien inclure un UPN

clip_image004

C’est maintenant qu’il faut introduire la subtilité. Pour que la commande Protect-CMSMessage accepte d’utiliser notre certificat, il doit avoir un rôle bien particulier. Pas de bol, il est pas dans le gabarit de certificat que nous avons utilisé comme base de travail. Qu’à cela ne tienne, on va le personnaliser.

clip_image005

Pour être sûr que notre certificat ne soit pas détourné pour un autre usage, on va faire le ménage dans les EKU et ne positionner que « Document Encryption ».

clip_image006

Maintenant, c’est mieux.

clip_image007

On approche de la fin. Ne pas limiter la capacité d’enregistrement de certificat, c’est la porte ouverte à toutes les fenêtres, des certificats délivrés à gogo sans se soucier qu’un jour il faudra les renouveler, ce qui bien sûr arrive toujours au pire moment. En limitant la capacité d’enrôlement aux seuls membres d’un groupe, on saura déjà à qui on a délivré ces certificats.

clip_image008

Y a plus qu’à publier notre gabarit de certificat et Zou, à la signature.

clip_image009

Une fois la session ouverte avec notre compte de service, on peut réaliser la demande.

clip_image010

C’est fini. Pour s’assurer que cela fonctionne, une rapide commande Powershell « Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert » nous confirme que nous avons bien un certificat prévu pour cet usage dans le magasin. Vu que c’est le cas, y a plus qu’à chiffrer notre message :

$Cert = Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

$CMSMessage = Protect-CMSMessage -Content « Ilachangé! » -To $Cert/Thumbprint

clip_image011

 

Aller, je retourne me punir, j’ai du python sur le feu. Je ne déconne pas

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

Cacher les mots de passe dans les scripts Powershell

Nous passons tous beaucoup de temps à industrialiser avec PowerShell. Il n’est pas rare que je retrouve les mots de passe codés en dur dans les scripts. Pour éviter ces dérives, j’ai compilé dans ce billet quelques méthodes pour cacher ces mots de passe, du plus simple, au plus sexy

En PowerShell, la gestion des credentials est quelque chose que nous semble très simple. On sait tous que l’on peut « sécuriser » les mots de passe avec le fameux ConvertTo-SecureString. Le problème, c’est que cette fonction est réversible avec la méthode « Get-NetworkCredential ». Pour vous donner une idée, une rapide démonstration :

clip_image002

Le problème, c’est que dans l’exemple ci-dessous, PowerShell utilise Windows Data Protection API (DAPI). Cela signifie que seul le même compte est capable de chiffrer/déchiffrer notre secret. Stocker l’information dans un fichier ou dans le registre. On va devoir ruser pour ne pas utiliser une clé de chiffrement locale au système d’exploitation. Si on creuse un peu la commande ConvertFrom-SecureString, on trouve deux paramètres intéressants :

clip_image004

Donc si on utilise une clé externe de taille assez grande, on devrait être capable de chiffrer nos données en étant indépendant du système d’exploitation. Commençons par chiffrer notre information avec notre nouvelle clé.

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Object] $Cred = $null

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

[String] $CredFile = « $ScriptPath\CredData.ps1xml »

if ( $Cred -isnot [System.Management.Automation.PSCredential] )

{

[Object] $Cred = (Get-Credential -Message « Service Account »)

[Object] $CredData = $Cred | Select-Object -Property UserName,@{Name= »SecurePassword »; Expression={ ConvertFrom-SecureString -SecureString $_.Password -Key $Key.ToByteArray() }}

$CredData | Export-CliXml -Path $CredFile -Encoding Unicode -Force

Remove-Variable -Name CredData -Force

}

Get-Content $CredFile

clip_image006

Logiquement, on doit pouvoir faire l’inverse facilement avec le script suivant :

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

$CredFile = « CredData.ps1xml »

[Object] $CredData = Import-CliXml -Path ($ScriptPath + »\ » + $CredFile)

if ( $? )

{

$SecurePassword = ConvertTo-SecureString -String $CredData.SecurePassword -Key $Key.ToByteArray()

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ($CredData.UserName, $SecurePassword)

$Credential.GetNetworkCredential() | Format-Table *

}

clip_image008

Note : On m’a fait remarqué cette semaine que cela aurait été encore mieux d’utiliser le paramètre « -SecureKey ». Notre clé aurait alors été encodée dans un System.Security.SecureString. Merci Sylvain.

Le problème, c’est que ma clé est lisible dans le script. Ce qu’il faudrait, c’est de pouvoir la disposer d’un mécanisme me permettant de chiffrer des données avec une clé qui soit reconnue d’autres systèmes mais qu’on ait pas besoin de la même clé. Un truc comme une clé asymétrique. Chiffrer des données avec un certificat, c’est utiliser la clé publique pour cela. Pour déchiffrer, on aura besoin de la clé privée. Nous allons avoir besoin d’un certificat qui devra être présent :

  • Sur le système qui assure le chiffrement du message (en l’occurrence un mot de passe)
  • Sur les systèmes qui devront accéder à cette information

Cela implique que le certificat que nous allons demander devra être :

  • Reconnu comme issu d’une autorité de certification reconnue de toutes les parties
  • Être exportable

Ces points techniques résolus, attaquons nous au chiffrement de notre message avec quelques lignes de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Password = ‘Il a changé!’

$EncodedPassword = [System.Text.Encoding]::UTF8.GetBytes($Password)

$EncodedBytes = $Cert.PublicKey.Key.Encrypt($EncodedPassword, $True)

$EncryptedPassword = [System.Convert]::ToBase64String($EncodedBytes)

clip_image010

Quelques explications s’imposent. On commence par localiser le certificat que nous allons utiliser et encoder notre mot de passe au format UTF8. Ceci-fait, on encode notre mot de passe à l’aide de la clé publique de notre certificat et con convertit le tout en Base 64. Ca ressemble plus du tout à notre mot de passe. On peut communiquer cela tel que, aucun risque que cela puisse être décodé sans la privée. Justement, allons voir comment décoder cela sur un autre système avec un peu de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Encryptedcontent = Get-Content .\secret.txt

$Encryptedcontent

$EncryptedBytes = [System.Convert]::FromBase64String($Encryptedcontent)

$DecryptedBytes = $Cert.PrivateKey.Decrypt($EncryptedBytes, $True)

$DecryptedPassword = [System.text.Encoding]::UTF8.GetString($DecryptedBytes)

clip_image012

Si on a compris la logique, on commence par reconvertir notre contenu en une chaine de caractères pour laquelle on va utiliser la clé privée de notre certificat pour déchiffrer notre message. L’avantage de cette approche est qu’elle est indépendante du système d’exploitation, même Cross-Plateforme. Autre avantage, on peut limiter l’accès à la clé privée. Il faut juste décider qui à accès à la clé privée.

clip_image014

Ça c’était bien avec les vieilles versions de PowerShell, ça fonctionne super, même avec Orchestrator, c’est pour dire, … On ne peut pas faire plus sexy avec des versions plus récentes ? Oui, car depuis la version 5.0, on dispose de la fonctionnalité CMSMessage. L’aide intégrée de PowerShell ne vas pas vous aider beaucoup.

clip_image016

Avec la version en ligne de Protect-CMSMessage, c’est déjà mieux. On utilise toujours un certificat, sauf que cette fois, notre certificat devra comprendre l’EKU « Document_Encryption » pour qu’on puisse l’utiliser avec la commande Protect-CMSMessage. J’ai donc préparé une demande de certificat en bonne et due forme ou presque. En fait, ce sera un certificat auto-signé (j’ai fait court pour la démonstration).

clip_image018

Au passage, un switch bien pratique que je ne connaissais pas pour filtrer les certificats : Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

En une seule commande on va être capable de chiffrer notre message : $Message = Protect-CmsMessage -Content $Password -To « *benoit@simplebydesign.fr ». Après, y a plus qu’à empaqueter et transmettre.

clip_image020

De l’autre côté, même principe. On commence par localiser le certificat que nous allons utiliser pour déchiffrer à l’aide de la commande Get-ChildItem Cert:\CurrentUser\My DocumentEncryptionCert. Reste plus qu’à déchiffrer.

clip_image022

Jusque-là, on parlait On-Premises, Old-School IT. Et si on regardait comment faire de même dans Azure. Y a forcément un service pour cela. Oui, C’est Azure Key Vault. Avant cela, faut un peu préparer le terrain. On peut faire cela en PowerShell assez rapidement :

Install-Module AzureRM

Install-AzureRM

clip_image024

Justement, le dernier installé nous intéresse. Continuons notre mise en place, on y reviendra. Continuons avec l’installation du module PowerShell Azure, chargeons tous les modules Azure Resource Managers et celui d’Azure avec les trois commandes suivantes :

Install-Module Azure

Import-AzureRM

Import-module Azure

clip_image026

La première étape d’Azure, c’est l’authentification. Ça se règle en deux commandes PowerShell :

$Cred = get-Credential

Login-AzureRMAccount -Credential $Cred

clip_image028

La commande Get-AzureRMSubscription nous indique que j’ai accès à plusieurs souscriptions. Nous allons nous fixer sur l’une d’entre elle.

clip_image030

Les prérequis sont en place. Nous devons mettre en place notre Azure Key Vault au sein d’un groupe de ressources dédié (sécurité oblige)

New-AzureRmResourceGroup -Name ‘MyKeyVault’ -Location ‘North Europe’

New-AzureRMKeyVault -VaultName ‘MesPrecieux’ -ResourceGroupName ‘MyKeyVault’ -Location’North Europe’

clip_image032

A noter que lors de la création, il faudra prouver son identité. A ce niveau, nous sommes le seul à y avoir accès via l’URL suivante : . Stockons notre mot de passe avec les commandes PowerShell suivantes :

$Password = « Ilachangé! »

$SecretValue = ConvertTo-SecureString $Password -AsPlaintext -Force

Set-AzureRMKeyVaultSecret -VaultName ‘MesPrecieux’ -Name « Password » -SecretValue $SecretValue

clip_image034

Nous pouvons vérifier que nous avons bien un secret dans notre coffre aux précieux :

Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’

clip_image036

Jusque-là, ça casse pas trois pattes à un canard. Montons un peu le niveau. Si on a un coffre-fort pour nos secrets, la moindre des choses, ce serait de pouvoir retrouver l’historique de notre mot de passe, voyons le résultat de la commande Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions.

clip_image038

La ça devient intéressant. Non seulement, on a l’historique des valeurs mais on peut aussi filtrer pour utiliser le dernier disponible. Voyons comment retrouver la dernière version de notre mot de passe :

$liste = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions

$Password = $liste | Sort-object -property updated -Descending | select -first 1

$secret = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -Version $password.Version

$Secret | Get-member

$Secret.SecretValue

$Secret.SecretValueText

clip_image040

Nous avons retrouvé le dernier mot de passe associé. Entre temps, il a été changé (sécurité oblige). OK, c’est pas mal. Le problème, c’est de partager nos secrets. La, Azure Key Vault fait fort car grâce à Azure Resource Manager, on peut déléguer l’accès. La commande ci-dessous délègue l’accès à un utilisateur, uniquement pour lire le contenu de mon coffre.

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MesPrecieux’ -UserPrincipalName ‘test@XXXXXXXXXX.onMicrosoft.com’ -PermissionsToSecrets ‘Get’

Get-AzureRmKeyVault -VaultName ‘mesprecieux’

clip_image042

Après, j’aurai pu pousser le vice de déléguer uniquement l’accès à mon mot de passe. On peut même autoriser des applications à accéder aux précieux.

Pour les amateurs, quelques lectures supplémentaires :

 

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

Patching out of band, cas concrêt

C’est quand on traite des sujets qui n’arrivent jamais que ça tombe. J’avais publié voilà quelques jours une série de billets sur le Patch Management d’une infrastructure de type cloud privé. Certaines personnes m’ont demandé pourquoi devait-on prévoir un processus pour les patchs out of band, … La réponse est tombée ces jours-ci : Microsoft Security Advisory 3108638.

L’alerte est d’importance car ça touche l’Hyperviseur. En lisant plus précisément le bulletin de sécurité, on découvre que la « faille » ne se trouve pas dans Hyper-V mais dans le processeur lui-même. Conséquence, c’est toutes les versions d’Hyper-V qui sont affectées :

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2
  • Windows 8.1
  • Windows 10

C’est disponible dans Windows Update, donc pour action immédiate. Vu que c’est une problématique indépendante du logiciel, tous les Hyperviseurs sont donc affectés. Une recherche rapide sur Google Bing vous donnera les liens pour les autres hyperviseurs du marché :

Remarque : Il ne faut pas voir de mauvais esprit anti-VMWARE de ma part mais Google / bing n’a pas été mon ami pour trouver l’information chez eux sans accès à la Knowledge Base.

Alors convaincu qu’il est important d’avoir un process de patch management out of band dans votre infrastructure Cloud privé? Maintenant, vous avez deux choix :

  • Choix n°1 : Tester le déploiement en urgence à l’arrache sans concertation avec vos locataires avec un résultat attendu.

clip_image001

clip_image002

Alors, prêt à patcher?

­

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

Patch Management – Réflexions – Bonus : Les urgences

Jusqu’à maintenant, on a parlé de patching organisé. Cependant, on aura certainement un jour à traiter une urgence, avec un RSI qui nous impose le patching de notre infrastructure dans des délais beaucoup plus court que les cycles de maintenance que nous pouvons proposer. Que ce soit dans le contexte d’un cloud privé ou hybride, il faudra impliquer nos locataires. Il y a de grandes chances que le problématique rencontrée par l’hébergeur impacte aussi le locataire (cas Heartbleed). Il devra aussi prendre ses responsabilités. Si son application a bien été pensée pour la scalabilité et la résilience, alors cela devrait bien se passer. Netflix en a fait l’expérience, c’est un enseignement à méditer : Lessons Netflix Learned from the AWS Outage.

Le problème, c’est comment y faire face quand ça nous tombe dessus. Réagir implique d’organiser un cycle de maintenance dans l’urgence, donc communiquer auprès de nos locataires pour les informer des impacts sur leurs workloads. Le risque avec les cycles de maintenance exceptionnels, c’est que c’est une organisation lourde, organisée dans l’urgence, donc un fort risque d’avoir des problèmes. A côté de cela, on a déjà des cycles de maintenance en place. Donc, de mon point de vue les stratégies sont les suivantes :

  • Tenir jusqu’au prochain cycle de maintenance. Ce qui implique que les cycles de maintenances sont rapprochés et qu’on peut tenir jusqu’au prochain, genre chaque week-end. Ça peut permettre de patcher une partie de l’infrastructure en cumulant patching Microsoft et urgence au sein de la même plage de maintenance. Avec nos runbooks qui se ressemblent beaucoup, c’est juste une histoire d’intégration.
  • Improviser. Généralement, ça ressemble à du freestyle sans filet, on connait tous les résultats.
  • Appeler la terre entière pour demander à redémarrer la plateforme, ce qui va détruire nos SLA à 0 et ruiner la confiance de nos locataires

Ma préférence va à la première stratégie. Plus votre infrastructure est importante plus il devient difficile d’organiser des actions dans l’urgence. Les dépendances deviennent de plus en plus nombreuses. En ayant des cycles de maintenance courts, il est plus simple d’inscrire des actions urgentes dans ces cycles de maintenance plutôt que d’introduire des cycles de maintenance exceptionnels qu’il est complexe d’organiser sous contrainte de temps. C’est une solution envisageable uniquement si on est capable de mettre en place des mesures de mitigation pour parer aux risques encourus jusqu’à ce que l’infrastructure soit totalement patchée.

Etre en situation d’urgence sans préparation, c’est le mur assuré. Le problème, c’est qu’il faut bien apprendre. Pour cette raison, l’organisation de cycles de maintenance dans l’urgence ne doit pas être rejetée. Cela peut effectivement générer des problèmes mais on a beaucoup à apprendre de ces incidents si on en sort avec :

  • Un REX, ce qu’on en a appris, ce qu’il faut corriger
  • Un plan d’action pour prendre en compte les corrections
  • Des processus éprouvés et partagés

Après, il faut valider que nos corrections techniques / processus vont dans le bon sens. Pour cela rien de vaut de se remettre en situation de risque. Je ne dis pas qu’il faut planter tout son Cloud privé mais créer une situation de risque contrôlée

clip_image002

C’est là qu’un environnement de Prototypage un tant soit peu représentatif prend tout son intérêt!. Pour nous, c’est encore un sujet en cours de réflexion pour lequel on espère poser les bases prochainement.

L’idée générale serait d’organiser des campagnes de « Stress test » pour tester aussi bien l’infrastructure, que les processus et les équipes. Ce type de campagne devrait être organisé au moins deux fois par an. Plus, c’est qu’on a eu beaucoup trop d’urgences dans l’année écoulée. C’est possible mais mettre en place un environnement contrôlé prend du temps. Moins, c’est prendre le risque d’oublier ce qu’on veut qualifier. Quelques conseils pour organiser ces Stress tests :

  • Disposer d’un environnement de prototypage représentatif est l’idéal mais ce n’est pas toujours possible. Il faudra certainement isoler une partie de l’environnement de production
  • Procéder par itérations. On ne peut pas tout tester en un seul cycle annuel
  • Se fixer des objectifs réalistes

Pour conclure, la conception et la mise en place du Patch Management d’un cloud privé prend du temps, beaucoup de temps. Dans notre approche, nous avons tenu à observer quelques règles :

  1. Si le design ressemble à l’étoile de la mort, c’est pas bon
  2. Plus on complexifie les processus, plus on va jongler avec des briques
  3. Une brique qui tombe ça fait mal
  4. Toujours garder en mémoire les trois premiers points

Voilà pour le Patch Management d’une infrastructure cloud privé basée sur les produits System Center. Pour les locataires, c’est une autre histoire qui peut se résumer ainsi : Pets or Cattle. Nos locataires doivent t-ils être au petits soin pour leurs machines virtuelles ou les traiter comme du bétail? Ce sera un autre sujet de discussion.

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

Patch Management – Réflexions – n°5 : Les cycles de maintenance

C’est bien d’automatiser au maximum, encore faut-il planifier ces opérations. Doit-on planifier toutes ces opérations selon le même cycle de maintenance « long » (option big-bang au risque de se transformer en big-badaboum) ou des cycles « courts » (option « blind-test » pour la découverte des bugs / comportements non prévu)? La réponse est bien plus compliquée. Déjà, tous les types de Patching ne s’inscrivent pas dans le même cycle de maintenance. Raisonnons donc en fonction des différents domaines :

  • Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V : Pour maintenir la stabilité de la plateforme et le support des éditeurs, on est obligé de suivre un rythme soutenu. Certes, on n’est pas obligé de suivre au jour le jour et de s’imposer des cycles courts mais on doit quand même suivre. On aura besoin d’un à deux cycles de maintenance par an. A mon sens, difficile de faire plus car il faudra du temps pour valider que les changements opérés produisent bien les effets escomptés et qu’on n’observe pas de régression pouvant affecter nos SLA et par extension les SLA de nos locataires.
  • Patch Management Microsoft : On est tous d’accord pour suivre le rythme mensuel imposé par Microsoft. C’est sportif mais pas impossible. En fonction de la taille de l’infrastructure, on devra découper en plusieurs phases. Par exemple, patcher un certain nombre de châssis par semaine sur un cycle d’un mois. A mon sens, c’est une approche à privilégier car avec Windows 10 et Windows Server 2016, la notion de « Ring » va changer les choses. Devra t’on passer sur le modèle Long-Term Branch? C’est une bonne question, pas encore assez de recul pour juger. Par contre le choix du mode d’installation Nano devrait nous faciliter grandement la tâche pour réduire drastiquement le nombre de correctifs à installer et le nombre de redémarrages nécessaires.
  • Patch Management « Out of band » : Là, c’est la criticité qui impose le cycle. La première option serait de travailler dans le mode urgence. Pas évident à organiser et le résultat risque d’être approximatif. On peut aussi prévoir de pré-réserver des créneaux pour réaliser ce type d’opération et les utiliser ou non. C’est l’option que je préfère. On évite l’organisation dans l’urgence et on inscrit cela dans un cycle régulier, plus facile à maîtriser. Après, on peut prévoir d’intégrer ce type de patching dans le cycle du Patch Management Microsoft. C’est envisageable si on a bien prévu un cycle de maintenance court. On profite du créneau horaire du premier pour intégrer le second.
  • Patch Management de la Fabric : Avec les solutions Cloud Privé / Hybride de Microsoft, c’est facile, les équipes System Center fournissent des Update Rollup tous les trimestres. Autant on n’a pas de problème ou presque à appliquer les correctifs Microsoft & Out of Band sur notre Fabric, autant les updates UR sont trop spécifiques et nécessitent trop de tests. Pour cette raison, choix a été fait de ne pas suivre le rythme de publication de Microsoft. Il a été décidé de sauter un UR sur deux sauf si l’UR en question nous corrige des problèmes nous impactant ou apportant des fonctionnalités requises par nos locataires. En plus chaque UR apporte son lot de nouvelles fonctionnalités à mettre en place / qualifier, …

clip_image001[4]

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

Patch Management – Réflexions – n°4 : Patch Management de la Fabric

Mon préféré. Le premier qui déploie des UR de System Center en automatique, il prend aussi le chemin du mur mais avec un Jetpack dans le dos. Pour bien comprendre le problème, faut découvrir ce qui se cache dans les Updates Rollup de la gamme System Center. Tous les trimestres, Microsoft livre une nouvelle fournée. A ce jour, le dernier disponible est l’UR8 : KB3096378 : Update Rollup 8 for System Center 2012 R2.

Les KB System Center, c’est aussi digeste que l’encyclopédie. Pour Rappel, la gamme System Center ça couvre :

  • App Controller (Un truc qui a dû servir une fois)
  • Data Protection Manager (on n’y échappe pas au saucissonneur de baies de disque)
  • Operations Manager (SCOM pour les intimes)
  • Orchestrator
  • Service Management Automation
  • Service Manager (SCSM mais SM pour les intimes, …)
  • Service Reporting (Le petit dernier de la génération 2012R2)
  • Virtual Machine Manager
  • Service Provider Foundation
  • Windows Azure Pack
  • Windows Azure Pack WebSites

C’est bon ou on en rajoute ? Subtilité supplémentaire, d’un point de vue support Microsoft indique que tous ces composants doivent nécessairement être au même niveau pour être supportés. Donc pas la peine d’envisager un déploiement progressif. Dans notre contexte, App Controller et Service Reporting n’étant pas déployés, c’est déjà cela de gagné. Maintenant essayons de voir l’étendue des problèmes qu’on va rencontrer :

  • Les agents  : Certains produits tel que DPM, SCOM et SCVMM reposent sur des agents installés qu’il faut aussi mettre à niveau (SIC). Qui dit installation implique redémarrage, c’est par exemple le cas de SCVMM.
  • Les dépendances entre les produits : Qui dit nouvelle version de Management Pack SCOM dit importation de celui-ci dans SCSM ainsi que dans son Data WareHouse.
  • Les actions pré/post installation : Y a quelques produits ici et là qui ont besoin d’actions pré-post installation en PowerShell. Le genre de d’opérations qu’on ne pourra pas automatiser en plus, …
  • L’ordre d’installation : SCSM est un excellent exemple puisque c’est :
  1. Data WareHouse Server
  2. Primary management Server
  3. Secondary Management Servers
  4. All analyst consoles
  5. Self-Service Portal

Je suis presque sûr que tout le monde aurait commencé par le Primary Server SCSM. Perdu, …

Pour toutes ces raisons, on s’est contenté d’un processus de mise à niveau qui est encore manuel / semi-automatique. L’opération étant très chronophage, on n’arrive pas encore à suivre le rythme imposé par Microsoft avec une fournée d’ Update Rollup par trimestre. Conséquence, on s’est limité à appliquer un Update Rollup sur deux, sauf si la stabilité de la plateforme nous impose d’aller plus vite. Ce choix n’est pas sens conséquence. Actuellement, nous sommes en cours de migration UR5 vers UR7, on est donc en retard. A première vue, c’est simple, il suffit de suivre les KB. Sauf que les KB ont été écrites pour upgrader depuis la version précédente, pas celle d’avant. Dans l’UR6, il y a des Management Pack SCOM qui ont été mis à jour, pas dans UR7. Encore faut-il relire la KB de l’UR6 pour le découvrir. Les Updates Rollup sont cumulatifs, pas les KB de déploiement associées. Jusqu’ici c’était simple. Bientôt, notre « machin », devra évoluer / muter et intégrer d’autres composants tel que :

  • Service Provider Foundation
  • Service Management Automation
  • Service Reporting
  • Windows Azure Pack
  • Windows Azure Pack WebSites

A ce moment on pourra dire que notre « machin » va muter en super étoile de la mort. Pour rappel, voilà à quoi ressemble une infrastructure Windows Azure Pack un tant soit peu disponible :

clip_image001

Et encore, je ne suis pas tout à fait d’accord avec le schéma ci-dessus. Pour moi le portail d’administration de Windows Azure Pack est nécessairement en haute disponibilité avec deux instances. Lorsqu’on va introduire Windows Azure Pack (yumi!!), on va devoir révolutionner nos méthodes. Windows Azure Pack repose sur des Web services opérant en « State-less » avec un Load Balancer devant. Notre processus devra intégrer ces Load Balancers dans le processus de Patching pour activer / désactiver les instances de Web Services publiés. Juste pour vous donner une idée, allez relire un billet publié cette année sur DirectAccess : Monitoring DirectAccess with Kemp. C’est exactement la même problématique mais appliqué à six ou sept Web Services accessibles via un Load Balancer mutualisé. Ça promet d’être très fun.

Si jamais on arrive à intégrer tout cela, on pourra s’attaquer au patching d’une infrastructure WebSites de Windows Azure Pack répartie entre plusieurs châssis répartis eux même entre deux datacenters. Si vous avez un trou de mémoire, y j’ai écrit quelques billets sur le sujet : Architecture Windows Azure Pack WebSites–Introduction. Comme une image vaut mille mots, je pense que là vous avez compris l’étendue du problème, encore des Web services et des Load-Balancers :

clip_image003

Ce qui nous sauve avec l’architecture WebSites, c’est qu’elle a été conçue pour supporter la défaillance d’une ou plusieurs instances de chaque rôle (il y a juste une exception). Il faut juste pas tenter de mettre à niveau toutes les instances d’un même rôle en même temps, sinon c’est big badaboum comme disait Leeloo.

Alors, toujours SCCM/Windows Update en mode, je déploie comme un goret ? C’est là qu’on commence à apprécier le moteur d’orchestration des mises à jour de Microsoft Cloud Platform System. Pour l’instant, impossible pour nous de le concurrencer. Respect, c’est un super boulot. En fait, il gère tous les aspects du Patch Management que nous avons abordés jusqu’à maintenant mais en mieux.

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

Patch Management – Réflexions – n°3 : Patch Management "Out of band"

De quoi parle-t-on ? Ben des correctifs qui ne sont pas dans Windows Update, pas disponibles nativement dans SCCM. Selon les organisations, organiser le déploiement de correctifs out-of band dans SCCM, c’est un processus qui peut s’avérer long. Le problème, c’est que bien souvent, les correctifs out-of band, quand on en a besoin, c’est pour la veille. Faudra donc développer un processus automatisé pour déployer ces correctifs quand on en a besoin, donc ASAP. Si vos processus internes permettent de publier ces correctifs dans SCCM rapidement, c’est parfait. Dans notre contexte, il nous faut un processus de déploiement « alternatif » en attendant que les correctifs soient disponibles dans SCCM.

Qu’est-ce qu’on entend par correctifs « Out of band» ? C’est par exemple ceux que le support Microsoft vous recommande d’installer uniquement si vous rencontrez le problème. Dans notre contexte, la liste était déjà très fournie :

Là encore, le couple Orchestrator / PowerShell fait des miracles ou presque. Ce processus est nécessaire aussi bien pour les Clusters Hyper-V que pour nos locataires. On a tous les mêmes problèmes. La tentation est grande de développer un processus commun mais ça irait à l’encontre d’une règle sacrée : l’indépendance entre le fournisseur de l’infrastructure et ses locataires. Chacun doit pouvoir déployer ses propres correctifs sur son périmètre. C’est encore un processus en cours de développement. Dans notre approche, on a retenu de proposer deux ensembles de Runbooks :

  • Le premier à destination de l’équipe en charge des clusters Hyper-V
  • Le second plus « générique » à destination de tous les locataires

Comme le déploiement de correctifs « out-of band » a été requis par l’hébergeur, on a donc commencé par lui. Pour faire simple, disons qu’il disposera des Runbooks suivants (actuellement en développement) :

  • Mise à disposition de correctifs au sein de son périmètre (clusters Hyper-V par exemple)
  • Installation des correctifs mis à disposition sans redémarrage
  • Installation des correctifs mis à disposition avec redémarrage
  • Vérification bonne installation des correctifs mis à disposition

C’est assez simple à réaliser, tout ce qu’on avait besoin, c’était un repository central (File Share) pour déposer les correctifs à déployer. Bref, ça ne casse pas trois pattes à un canard. Maintenant, la même chose mais pour les locataires. La ça pose plusieurs problèmes :

  • L’indépendance entre l’infrastructure et le contenu hébergé
  • Les contextes d’exécution qui sont nécessairement distincts
  • L’impossibilité de répondre à tous à tous les besoins de nos locataires
  • Offrir le choix de faire simple

Bref, toutes ces raisons qui font que c’est nécessairement une prise de tête. Voyons comment on compte traiter le sujet en reprenant les points un par un :

  • L’indépendance entre l’infrastructure et le contenu hébergé : La pas le choix, il faut trancher. On ne réutilisera pas les même Runbooks. Par contre, rien ne nous interdit d’en faire des copies et de permettre à nos locataires d’accéder à la console Orchestrator Web Access pour les exécuter. En plus, en plaçant les Runbooks dans des Folders distincts, on peut limiter les populations qui peuvent y accéder, bon point pour l’indépendance.
  • Les contextes d’exécution qui sont nécessairement distincts : Par défaut, tous les Runbooks Orchestrator utilisent le même contexte d’exécution, celui accordé au compte de service Orchestrator. Pas évident que nos locataires autorisent des accès extérieurs non maîtrisés. Par contre, il est possible d’exécuter un Runbook Orchestrator sous un autre contexte. C’est une option de l’activité « Invoke Runbook ». On a juste à référencer les contexte d’exécution sous la forme de variables. Bien entendu, pour le mot de passe, la variable ne sera pas stockée en clair.

clip_image002

Remarque : Au passage, il est aussi possible de limiter l’accès aux variables en utilisant le même mécanisme de Folders et de permissions, comme pour les Runbooks. De cette manière un locataire ne peut pas utiliser les contextes d’exécution des autres.

  • L’impossibilité de répondre à tous les besoins :  Installer des correctifs pour Hyper-V et pour SQL Server, ça n’a rien à voir. Chaque produit a ses propres spécificités. On ne veut pas développer d’usine à gaz. La logique nous a amené à proposer notre approche à nos locataires mais uniquement sous une forme « générique ». Charge à eux de l’implémenter tel que ou de l’adapter en fonction de leurs besoins.
  • Offrir le choix de faire simple : Jusque-là, on ne peut pas dire que j’ai fait simple. Certains de nos locataires pourraient penser que cela ressemble à une usine à gaz, surtout pour des périmètres applicatifs très limités en terme de nombre de machines virtuelles. Pour cette raison, notre « Machin Patching out-of band » n’est jamais imposé aux locataires, juste proposé. S’il estime qu’il est plus agile en patchant ses machines virtuelles manuellement, c’est son problème, ses SLA et son périmètre de sécurité dont il est responsable. Les Runbooks génériques ne font qu’exécuter les scripts présents au sein des machines virtuelles. On peut donc utiliser les même processus en exécutant directement les scripts PowerShell. Ça reste simple pour nos locataires.

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

Patch Management – Réflexions – n°2 : Patch Management Microsoft

C’est la partie la plus simple. C’est pour cela qu’on commence par elle généralement. Un SCCM, un WSUS, SCVMM et la fonctionnalité Cluster Aware Update? Aller un peu de PowerShell au-dessus et c’est bon ? On va commencer par SCCM. Je suis pour et contre. Pour car il permet de facilement déployer les correctifs et de nous faire un reporting. Par contre dans un contexte Cluster, faudra l’interfacer avec le Cluster Aware Update de nos clusters. SCVMM pourrait être un bon candidat mais, il ne prend en charge que les mises à jour en relation avec Hyper-V. C’est donc trop limité.

Coté processus, j’étais encore partagé entre le Cluster Aware Updating et le Scripting PowerShell. Avec un peu de recul aujourd’hui, le Scripting PowerShell / Orchestrator me semble la solution la plus efficace. Le patch Management des clusters Hyper-V, c’est simple tant :

  • Qu’on dispose d’au moins un nœud de réserve pour réaliser
  • Qu’on est capable d’organiser la maintenance des nœuds de cluster

Organiser un redémarrage organisé d’un cluster avec SCCM, ce n’est pas si simple. Le seul moyen que j’ai trouvé, c’est de patcher plusieurs clusters en même temps, par vagues tel qu’illustré ci-dessous.

clip_image001

Cela revient donc à faire des collections organisées en « Waves » contenant uniquement des nœuds de clusters qui ne dépendent pas du même cluster. La planification avec SCCM, ce n’est pas simple. Or, les plages de maintenance dont on dispose ne sont pas extensibles. On a besoin d’orchestrer tout cela de façon plus rigoureuse avec une meilleure gestion des erreurs. Conclusion, Orchestrator + PowerShell = Rules the patch.

C’est maintenant qu’on rentre dans le dur. On a un processus déjà éprouvé. On va bâtir dessus et l’enrichir un peu avec quelques tricks. Le premier d’entre eux, c’est la mise à disposition des correctifs. Là, SCCM est un excellent candidat pour déployer les correctifs de manière ciblée. C’est tout ce que je lui demande. Pour l’installation et le redémarrage, on va reprendre la main. Ci-dessous une vue Macro de notre Runbook. On commence à le connaitre, focalisons-nous sur sa spécificité avec la gestion des erreurs. Le fait que les correctifs ne s’installent pas sur un nœud n’est pas critique. Attention, nous parlons des correctifs mensuels de sécurité, pas des correctifs « Out of band » qui eux font l’objet d’un traitement particulier. A la fin, c’est SCCM qui nous dira si tout s’est bien passé, si tous les nœuds au sein d’un cluster ont été correctement mis à jour.

clip_image002

Normalement, si on a bien industrialisé l’installation et la gestion de nos clusters Hyper-V, si une KB ne s’installe pas, le problème a de grandes chances d’être généralisé. Ce n’est pas critique pour nos Clusters Hyper-V. Par contre, il faudra investiguer sur les problèmes rencontrés afin de comprendre et éventuellement adapter le processus.

C’est notre mode de fonctionnement pour le patching de clusters Windows Server 2012 R2. Avec l’arrivée de Windows Server 2016 et son mode d’installation Nano, il faudra certainement revoir notre approche. La stratégie Long-Term Branch de Windows 10 / Windows Server 2016 devra être évaluée.

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