Architecture WAP–Design infrastructure Windows Azure Pack

Let the fun begin! Windows Azure Pack est de loin la partie la plus intéressante. Avouez, c’est uniquement la partie qui vous intéresse. J’ai déjà développé le sujet ici et la, mais sans vraiment rentrer dans le détail des explications. Pour rappel, Windows Azure Pack, c’est un ensemble de Web Services que l’on peut organiser en deux catégories, selon qu’ils ciblent les locataires ou les administrateurs de la plateforme. Le tableau-ci-dessous résume les rôles et les populations ciblées :

Rôle

Cible

Windows Azure Pack PowerShell API Administrateurs / Tenant
Windows Azure Pack Tenant API Administrateurs
Windows Azure Pack Admin Portal Administrateurs
Windows Azure Pack Tenant Portal Tenant
Windows Azure Pack Tenant Authentication Site Tenant
Windows Azure Pack Tenant Public API Tenant
Windows Azure Pack Admin API Administrateurs
Windows Azure Pack Admin Authentication Site Administrateurs
Windows Azure Pack Best Practice Analyzer Administrateurs

 

Tous ces Web Services peuvent cohabiter sur un même serveur ou être répartis sur plusieurs. Séparer en fonction des cibles est une bonne approche du point de vue de la sécurité. Un premier niveau de découpage logique donc le suivant comme illustré ci-dessous :

  • Un serveur pour héberger les rôles destinés aux Administrateurs (WAPPRIV)
  • Un serveur pour héberger les rôles destinés aux locataires (WAPPUB)

clip_image001

Le premier intérêt de cette séparation est de pouvoir placer chaque serveur dans une zone réseau distincte. Ca plaira aux barons de la sécurité. Pour eux, la Co-localisation des rôles sur un même serveur est problématique d’un point de vue sécurité. Exposer le portail d’administration ou l’API associée directement sur Internet est plutôt risqué. Si une faille impacte le serveur, il serait possible pour un utilisateur externe d’accéder aux rôles privilégiés de Windows Azure Pack. Après, il faut relativiser. Nos serveurs ne seront pas exposés directement sur Internet. Dans notre contexte Cloud privé, nous avons besoin que ces services soient hautement disponible et dans les deux datacenters. Pour le déploiement, que nous en ayons deux ou dix, c’est la même chose, tout ce que nous avons besoin, c’est d’un moyen d’industrialiser le déploiement : Powershell Deployment Toolkit.

clip_image002

 

Si on voulait pousser le vice jusqu’au bout en isoler les fonctions portail et authentification des autres. Techniquement, c’est possible mais cela complexifie l’architecture pour pas grand-chose. D’un point de vue sécurité, nos rôles destinés aux locataires ne seront pas exposés en directe mais via des mécanismes de reverse proxy (vous avez dit Web Application proxy?), l’idée étant de pré-authentifier les locataires. Justement, parlons authentification.

Authentification

Maintenant que l’infrastructure Windows Azure Pack est en place, on va passer un peu de temps sur la partie authentification. j’ai déjà évoqué ce sujet ici et . Au final, le choix est assez simple. Pour les administrateurs, le choix d’ADFS s’impose de lui-même. Cela permet de centraliser l’authentification et l’autorisation de nos administrateurs en un point unique, au sein de la zone réseau privilégiée, voire même de les pré-authentifier lorsqu’ils arrivent depuis une autre zone réseau. Dans le contexte de notre cloud Privé, cela implique qu’on disposera d’une ferme ADFS dédié à cet usage, avec haute disponibilité. Pour renforcer la sécurité, l’utilisation de Web Application Proxy est recommandé, rien que pour sa fonction External Extranet Lockout. Le bonus, c’est la possibilité d’imposer l’authentification forte à ce niveau avec Azure Multi-Factor Authentication.

clip_image003

 

Pour les locataires ADFS s’impose aussi mais pour une autre raison. Pour Microsoft, le fournisseur d’authentification par défaut ne doit pas être utilisé en environnement de production et recommande l’utilisation d’ADFS. Lorsque l’utilisateur est capable de se présenter avec sa propre identité, cela ne pose pas de problème. Ce sera par exemple le cas de certains de nos futurs clients pour lesquels on sera capable de mettre en place un Federation Trust comme documenté dans cette série de billets : Authentification des locataires de Windows Azure Pack avec ADFS.

clip_image004

 

Avec cette architecture, le client vient avec sa propre identité, charge à lui de s’assurer de sa disponibilité et sa sécurité. Par contre, cela nous coupe d’un certain nombre de nos clients qui n’ont pas encore d’infrastructure de fédération d’annuaire. Il faut bien être en mesure de leur proposer le service, sinon, on va se couper du business des TPE/PME. La question, c’est doit-on héberger ce service (et donc en être responsable) ou peut-on l’externaliser (Chez Microsoft Azure par exemple)? Le premier choix, cela signifie qu’on va :

  • Lui fournir les moyens de gérer son identité (réinitialisation mot de passe, …)
  • Garantir la sécurité de l’identité de nos utilisateurs

Le premier choix implique de mettre en place une infrastructure ADFS dédiée, sécurisée et hautement disponible. Techniquement, c’est donc une évolution de l’architecture ci-dessus dans laquelle on va ajouter une nouvelle infrastructure ADFS pour proposer notre service d’identité à nos clients. C’est facile mais ça nous rend responsable du bon fonctionnement du service et sa sécurité. Le second choix est lui plus sexy. Depuis peu, il est possible de consommer un tenant Windows Azure Active Directory sous forme ADFS. OK, la fonctionnalité est disponible uniquement pour l’édition Premium mais :

  • Microsoft nous fournit un service d’authentification sécurisé et hautement disponible
  • Microsoft nous fournit à nos futurs locataire le moyen de gérer / sécuriser leur identité

Du point de vue architecture, cela ne change strictement rien, ils sont toujours authentifiés et autorisés à accéder à leurs ressources.

 

Resources Providers

Windows Azure Pack ne serait rien d’autre qu’un portail sans ses Resources Providers. Pour ceux qui ont oublié, j’avais écrit ce billet : Introduction aux Resources Providers de Windows Azure Pack. Techniquement, ce sont des Web Services exposés de manière normalisée pour Windows Azure Pack. Avant même d’en ajouter d’autres, le billet s’attachait à configurer les premiers :

  • Monitoring
  • MarketPlace
  • Usage Service

Ils sont tous les trois livrés avec Windows Azure Pack et présents sur le serveur WAPPRIV, ou plutôt toutes les instances de nos WAPPRIV. Par contre dans la configuration par défaut, rien n’est prévu pour la haute disponibilité. Avec un peu de PowerShell, on peut aller revoir la configuration de ces Ressources providers avant configuration.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator », $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = « https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)«

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = « https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)«

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, DisplayName, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}} | Format-Table -AutoSize

clip_image005

 

Dans le billet Introduction aux Resources Providers de Windows Azure Pack, nous commencions par corriger ce point en introduisant une URL générique pour nos premiers Resources Providers. Derrière cette URL générique se cache une adresse IP portée par un boitier HLB qui se charge de rediriger les requêtes entres toutes les instances déclarées. Une fois corrigé, on obtenait le résultat ci-dessous :

clip_image006

 

Ces ressources Providers sont un peu particulier (ils sont « System Resource Provider ») car c’est autour d’eux que les autres Resources providers vont venir d’intégrer. Nos futurs ressources providers vont :

  • Proposer des ressources à nos locataires qui sera exposées via le Resource Provider Marketplace
  • Suivre l’état des ressources mises à disposition qui sera exposé via le Resource Provider Monitoring
  • Suivre la consommation des ressources mises à disposition de nos locataires Resource Provider UsageService

 

On peut maintenant s’attaquer aux autres Resources Providers :

  • MySQLServers
  • SQLServers
  • Automation
  • SystemCenter
  • CloudServices
  • Gallery
  • WebSites

Tous ces Resources Providers sont apportés par les composants additionnels que nous allons installer. Pour certains, leur existence est déjà référencée dans les portails de Windows Azure Pack (pour les plus connus d’entre eux), ne manque que la configuration nécessaire pour les exploiter. Windows Azure Pack impose son modèle avec un ensemble de Web Services :

  • AdminEndPoint (Partie visible du Resource Providers dans le portail des administrateurs)
  • TenantEndPoint (Partie visible du Resource Provider dans le portail des locataires)
  • UsageEndPoint (pour remonter le suivi des usages du Resource Provider pour chaque souscription)
  • NotificationEndPoint (pour notifier dans les portails sur l’avancement des opérations)
  • HealthCheckEndpoint (pour le monitoring du ressource provider)

 

Voilà pour l’essentiel. Maintenant, dans un contexte avec plusieurs Datacenters avec objectif de haute disponibilité, il faudra disposer d’au moins une instance de chaque serveur dans chaque Datacenter avec un mécanisme de répartition de charge réseau (F5/Kemp). Windows Azure Pack nous simplifie grandement la tâche. Ce ne sont que des Web Services pour lesquels on peut disposer d’autant instances que l’on veut. Tout ce qu’on doit faire c’est de placer un équipement d’équilibrage de charge réseau devant. En back-end, notre seule contrainte, c’est de disposer d’une infrastructure SQL Server hautement disponible en Always On, donc opérant en actif/actif. Avec deux Datacenters, cela ressemble déjà à cela :

clip_image007

 

Chaque Resource Provider est un sujet à part entière. C’est simple pour certains, compliqué pour d’autres. Vu que le plus intéressant pour beaucoup d’entre vous est le IAAS, on va commencer par lui dans le prochain billet.

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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.