Windows Azure Pack–Les APIs publiques des locataires

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).

clip_image001

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.

clip_image002

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, …).

clip_image003

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.

clip_image004

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.

clip_image005

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.

clip_image006

Avec un peu de patience (surtout vi vous avez un débit en download proche du néant), ça fini par arriver.

clip_image007

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.

clip_image008

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).

clip_image009

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.

clip_image010

Le processus d’installation est direct, pas de questions superficielles. Jusqu’à maintenant, c’est de l’Azure-like.

clip_image011

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.

clip_image012

Après redémarrage, on constatera que le module demandé est bien installé.

clip_image013

Au final, voilà la liste des composants installé sur le poste de travail de mon locataire.

clip_image014

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.

clip_image015

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à.

clip_image016

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.

clip_image017

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).

clip_image018

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 :

clip_image019

Ce certificat sera utilisé pour remplacer le certificat existant sur le binding tout en conservant le port par défaut (30006).

clip_image020

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,

clip_image021

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.

clip_image022

Allons l’explorer un peu la configuration de ce namespace avec la commande Get-MgmtSvcFQDN :

clip_image023

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.

clip_image024

Dans la console IIS, on va remplacer le certificat auto-signé tout en conservant le port 30005.

clip_image025

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.

clip_image026

 

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 :

clip_image027

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.

clip_image028

Explorons un peu la configuration de nos deux namespaces du moment (TenantAPI et PublicTenantAPI), on a des choses à voir.

clip_image029

On va commencer par reconfigurer le namespace TenantAPI pour bien vérifier les certificats SSL qui lui sont présentés.

clip_image030

Idem pour le TenantPublicAPI.

clip_image031

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.

clip_image032

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.

clip_image033

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).

clip_image034

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.

clip_image035

Avec Microsoft Azure, on utiliserait la commande Import-AzurePublishSettingsFile pour se connecter à notre tenant. Avec Windows Azure Pack, c’est presque cela : Import-WAPackPublishSettingsFile.

clip_image036

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é.

clip_image037

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.

clip_image038

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

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.