Attention, âmes sensibles, arrêtez vous ici. j’y ai laissé une boite d’aspirine et des nuits sans sommeil. Si vous n’êtes qu’un locataire d’une plateforme Windows Azure Pack, passez votre chemin. Par contre, les exploitants sont invités à rester enfermé dans la salle des tortures de mon donjon avec moi.
Maintenant qu’on a quelque chose de présentable du point de vue end-user, intéressons-nous à ce que nous présentons sous la moquette. Le portail, c’est bien mais pour nos clients, des services cloud, c’est bien plus qu’un portail, c’est aussi un jeu d’API exposé pour consommer les services. C’est un sujet que j’avais volontairement exclus du billet précédent car je voulais y consacrer un billet pour explorer à la fois la partie serveur mais aussi cliente. On verra qu’il y a beaucoup de parallèles avec son grand frère.
Partons de l’expérience de notre locataire
Lorsque nos locataires se connectent sur le portail, voilà l’interface qui leur est présentée. S’il dispose déjà d’un compte sur la plateforme, il peut s’authentifier. Les mécanismes d’authentifications feront l’objet de plusieurs billets (c’est presque un monde à part).
Pour ceux qui se posent la question et ne peuvent pas attendre les prochains billets, ce compte a été créé par WAP dans sa base SQL. Ce ne sont pas des comptes AD. Coté utilisateur, on peut aussi lui proposer de créer son propre compte. Celui-ci ne sera actif qu’après validation.
C’est un choix du fournisseur de la plateforme de Windows Azure Pack. Plus généralement, Windows Azure Pack propose des fonctionnalités pour gérer le cycle de vie des comptes de ses locataires (réinitialisation de mot de passe, vérification de compte, …).
A mon sens, ce n’est pas une bonne idée de laisser les utilisateurs se créer leurs propres comptes ainsi. Les informations fournies par l’utilisateur sont très minimalistes. En tant que fournisseurs de service, on ne dispose pas assez d’informations pour savoir à qui adresser la facture. Des mécanismes de notification peuvent être activés (envoi de mail de confirmation, …). Bref, c’est pas si mal que cela pour une V1. J’ai hâte de voir la V.Next.
Dans le cas présent, j’ai déjà un locataire (oui il a fuit lâchement mais on le torturera plus tard, …) sur ma plateforme, et il a souscrit à un plan.
Nous avons donc un client provisionné, il peut utiliser son portail ou accéder directement à l’API publique lui permettant de manipuler son tenant.
Un peu de travail coté client avant de commencer
Si Windows Azure Pack est le petit frère de Microsoft Azure, c’est pas pour rien. Il réutilise déjà la même plateforme pour installer ses prérequis : Le web Plateform Installer. S’il est pas déjà installé, c’est disponible à cette adresse dans Microsoft Azure. Dans la section "Command-Line Tools", il y a une sous-section Windows PowerShell. Y a plus qu’à cliquer sur Install.
Avec un peu de patience (surtout vi vous avez un débit en download proche du néant), ça fini par arriver.
On passe par cet installer pour installer l’API PowerShell de Microsoft. Elle inclus celle de Windows Azure Pack, on verra plus loin que c’est un sous-ensemble.
Dans ma liste de course, un seul élément : Microsoft Azure PowerShell. La taille du download peut varier en fonction de l’évolution de l’API mise à disposition par Microsoft (oui elle évolue vite) et des autres prérequis qui peuvent être nécessaires (Framework Dot.Net 4.0).
Même si c’est pas indiqué dans l’interface, il y a du monde dans les prérequis, donc il faut prendre son mal en patience.
Le processus d’installation est direct, pas de questions superficielles. Jusqu’à maintenant, c’est de l’Azure-like.
Au terme de l’installation, on peut nous demander de redémarrer notre poste de travail. En même temps, vu le nombre de composants installées, c’est normal. Attention, si un redémarrage est nécessaire, c’est que peut être des composants vont continuer à s’installer après.
Après redémarrage, on constatera que le module demandé est bien installé.
Au final, voilà la liste des composants installé sur le poste de travail de mon locataire.
Un rapide tour du propriétaire nous confirme que Windows Azure Pack a bien Microsoft Azure comme parent. Cela veut dire qu’ils auront beaucoup de choses en commun.
A ce stade, pas possible d’aller plus loin et pour cause, l’accès au TenantAPI nous sera refusé. What? Ouvrez la boite d’aspirine et avalez la tout de suite. Bienvenu dans la salle de torture de mon donjon.
Les APIs du tenant
C’est maintenant que ça se complique car elles sont deux et il n’y en a qu’une qui nous intéresse tout de suite, c’est la TenantPublicAPI. C’est un composant de Windows Azure Pack. A ce titre, il dispose donc d’un namespace que nous pouvons explorer avec le module PowerShell que nous connaissons déjà.
La différence entre TenantAPI et TenantPublicAPI tiens au fait que l’une est censé être exposée sur Internet, l’autre non. Donc c’est TenantPublicAPI qui nous intéresse. Comme pour les autres modules, il est configuré pour utiliser un certificat auto-signé et un port exotique. La commande PowerShell Get-MgmtSvcFQDN nous le confirmera. Coté IIS, on a bien un site web MgmtSvc-TenantAPI.
Vu l’expérience précédente avec les deux portails, on se doute bien de ce qu’on va trouver dans IIS (c’est toujours aussi moche).
Pas la peine de faire un dessin. Le certificat auto-signé du Web Service devra être remplacé avec un certificat délivré par une autorité reconnue par nos futurs locataires. Comme pour le portail des locataires et le TenantAuthSite, c’est un composant que nous devrons exposer sur Internet. Dans ma maquette, tous les composants de Windows Azure Pack sont installés sur la même plateforme. La bonne pratique serait de localiser les modules TenantAuthSite, TenantPortal et TenantPublicAPI en DMZ, sur un même serveur. D’un point de vue sécurité, l’erreur est de localiser le TenantAPI et le TenantPublicAPI sur la même machine exposée sur Internet. Pour faire simple, on va conserver la même adresse IP ainsi que le port exotique. Dans mon DNS interne, j’ai donc créé l’entrée suivante : TenantPublicAPI.WindowsAzurePack.Lan et demandé le certificat ci-dessous :
Ce certificat sera utilisé pour remplacer le certificat existant sur le binding tout en conservant le port par défaut (30006).
Note : Redémarrer le site web est encore essentiel. On va écraser le binding actuel, le TenantPublicAPI ne répondra plus.
Les puristes de IIS me reprocheront de ne pas utiliser la fonctionnalité Server Name Indication (SNI) disponible depuis IIS 8.0. Certes, cela permet de binder plusieurs certificats sur une même adresse IP en conservant le port 443 plus "user-friendly" mais dès lorsqu’on va faire du scale-out avec Windows Azure Pack, on va finir par dédier un serveur et donc une adresse IP. En plus, cela implique que les navigateurs Internet de vos clients le supporte (impose l’usage de TLS). Enfin, avec la haute disponibilité, est-ce que votre matériel supporte le SNI? Au final, même si cela fonctionne, c’est imposer une forte contrainte d’accès à notre service Cloud. Voulez-vous vous priver d’une partie de vos futurs locataires? Au passage, offrez une boite d’aspirine à votre équipe réseau. Elle en aura besoin lorsqu’on commencera à parler haute disponibilité .
Nous revoyons la commande Set-MgmtSvcFqdn que nous avions déjà utilisée. C’est pas plus compliqué que cela. Vu qu’on a déjà reconfiguré le TenantAuthSite,
Note : Ne pas oublier de redémarrer le Web Service.
Voilà pour l’API exposée à nos futurs locataires. Passons maintenant à la TenantAPI. Microsoft a séparé l’API dédiée au tenants en deux parties pour isoler certaines fonctions, pour que celles-ci ne soient pas accessibles depuis Internet.
Allons l’explorer un peu la configuration de ce namespace avec la commande Get-MgmtSvcFQDN :
Il opère donc sur le port 30005 et utilise un certificat auto-signé. On va donc avoir une nouvel enregistrement DNS tenantapi.windowsazurepack.lan, donc un nouveau certificat issu de mon autorité de certification interne.
Dans la console IIS, on va remplacer le certificat auto-signé tout en conservant le port 30005.
Note : On n’oublie pas de redémarrer le site web pour que la configuration soit active.
Encore une fois, il faut aussi actualiser l’information dans la base de données de Windows Azure Pack avec la commande Set-MgmtSvcFqdn que nous avions déjà utilisée.
Y a des détails qui changent tout
On est prêt coté serveur. Pourtant, il reste un truc qui me chiffonne. Comment Windows Azure Pack pouvait-il accepter de fonctionner avec des certificats auto-signés. Y avait forcément un truc sous la moquette. Dans le billet sur le Best-Practice Analyzer de Windows Azure Pack, on avait mis le doigt sur un sujet important :
Y a des résidus. OK, on pourrait directement attaquer les fichiers de configuration IIS ou utiliser le module Powershell WebAdministration pour corriger le problème. C’est faisable mais pas élégant. En plus Windows Azure Pack à mieux à proposer. Revoyons un peu la liste des commandes mises à disposition par le module de configuration de Windows Azure Pack.
Explorons un peu la configuration de nos deux namespaces du moment (TenantAPI et PublicTenantAPI), on a des choses à voir.
On va commencer par reconfigurer le namespace TenantAPI pour bien vérifier les certificats SSL qui lui sont présentés.
Idem pour le TenantPublicAPI.
Là où cela devient intéressant, c’est que ce paramétrage des namespaces a été poussé sur tous les serveurs raccordés à notre infrastructure Windows Azure Pack. C’est donc un moyen très efficace de propager des paramétrages quel que soit la taille de notre infrastructure.
Back to client-side
Coté Windows Azure Pack, c’est bon. Revenons à notre locataire qui veut utiliser le module PowerShell de Microsoft Azure pour piloter les actions dans son tenant. Pour simplifier les choses, mon utilisateur de test est déjà enregistré et a souscrit à un plan. Dans son portail, il n’y a pas grand-chose. On retrouve des rubriques que nous connaissons déjà dans le portail de son grand frère.
Note : Je suis sur un client qui reconnait l’autorité de certification émettrice du certificat Wapcloud.Windowsazurepack.lan et en mesure de récupérer sa CRL. Sinon, c’est tout de suite moins fun .
Comme pour Microsoft Azure, ce qui nous intéresse c’est le fichier XML PublishSettings.XML. Dans Microsoft Azure, c’est disponible à cette adresse https://windows.azure.com/download/publishprofile.aspx. Dans Windows Azure Pack, c’est le même principe, y a juste l’adresse qui change. Dans ma maquette, il est disponible à l’adresse suivante https://wapcloud.windowsazurepack.lan/publishsettings.
Si on regarde le contenu, on retrouve beaucoup d’éléments que nous connaissons déjà. On constate aussi qu’il était temps de modifier l’URL de Service Management (TenantPublicAPI).
Passons maintenant au plat de résistance, le module PowerShell. Comme indiqué, les commandes relatives à Windows Azure Pack sont un sous-ensemble de celles de Microsoft Azure.
Avec Microsoft Azure, on utiliserait la commande Import-AzurePublishSettingsFile pour se connecter à notre tenant. Avec Windows Azure Pack, c’est presque cela : Import-WAPackPublishSettingsFile.
Ce fichier contenait un peu plus d’informations que prévu. Il contenait un certificat installé dans notre magasin personnel (avec sa clé privée). Cherchez pas, c’est encore un auto-signé.
C’est ce même certificat que nous retrouvons dans le portail du locataire dans la section "Management certificates". Nous conservons la clé privée. Coté Windows Azure Pack, il n’y a que la clé publique de référencée.
Note : Vu ce que contient mon fichier publishsettings, la recommandation est de le supprimer dès que l’importation a été réalisée.
Ca y est, on a fini. Bienvenu dans ton cloud locataire (oui j’ai osé la faire ).
Même si j’ai clos ce sujet, je suis pas à l’abris d’en découvrir encore sur les API dédiées aux locataires. Le billet sera donc actualisé en fonction des découvertes. Faites les stocks de boite d’aspirine.
Félicitations à ceux qui sont arrivés au terme de ce billet. Ils méritent le badge “Windows Azure Pack survivor”. cependant, vous êtes encore loin de devenir le maitre du donjon. Il reste beaucoup de choses à voir dans la salle des tortures, …
BenoîtS – Simple and Secure by design but business compliant
