Vous avez l'habitude de voir chez nous des articles de blog qui parlent des différents services AWS et de comment vous pouvez les combiner pour construire et déployer vos propres solutions 'as code' sécurisées et hautement disponibles.

Admettons que l'on a écrit plusieurs templates qui définissent plusieurs infrastructures et plusieurs applications. Quelque part, nous avons créé un catalogue qui contient plusieurs services, qui sont prêts à être déployés. Dès que ce catalogue commence à devenir conséquent ou dès qu'il s'agit d'une grande entreprise, des nouvelles problématiques font leur apparition :

• Comment être sûr que toutes les équipes IT de l'organisation vont pouvoir trouver tous les produits qui ont été mis au catalogue ?
• Comment s'assurer que les règles maison ont été suivies et qu'une façon standardisée de faire est en place pour tous les produits du catalogue ?
• Comment séparer, de façon sure et simple, qui doit avoir accès à quels produits du catalogue ?
• Comment s'assurer que les bonnes balises (tags) sont en place pour la bonne gestion des coûts et la refacturation interne ?
• Comment arriver à gérer les différentes versions disponibles pour chaque produit et mettre à disposition des nouvelles versions sans impacter des applications en production qui fonctionnent sur des versions précédentes ?
• Comment confier à des équipes IT qui n'ont pas d'expertise particulière AWS la tâche de déployer tous ces produits sans leur permettre d'interagir directement avec les services AWS ?

Vous pouvez évidemment développer votre propre solution pour gérer tout ça (à vous les APIs AWS !) mais on vous présente aujourd'hui un service qui passe souvent sous le radar, bien pratique dans ce genre de scénario, et avec un nom (pour changer) qui décrit parfaitement sa fonction : AWS Service Catalog !

Service Catalog

Service Catalog nous permet de déclarer plusieurs produits. Chaque produit se décline en plusieurs versions, chaque version pointe vers un template CloudFormation qu'on aura stocké sur S3. Nous allons ensuite classer ces produits dans différents portfolios qui vont nous permettre d'attribuer des droits et d'enforcer des tags. Et c'est presque tout ! Voici un schéma qui résume tout ça ...

En pratique

C'est le moment de faire un atelier rapide pour voir comment faire, en pratique, tout ce que je viens d'expliquer. On va préparer un produit très simple qui va juste créer un bucket S3 en version 1.0, qu'on va ensuite améliorer en v1.1. On va voir, côté opérations, comment la personne responsable, avec des droits très restreints, va pouvoir provisionner notre produit puis le mettre à jour plus tard avec notre nouvelle version.

Voici le template CloudFormation qui permet de créer un bucket S3 tout simple, en première version : s3-bucket-v10.yml

Et voici le template CloudFormation qui sert à deployer notre catalogue avec notre produit : service-catalog-1.yml

Pensez à changer les identifiants des rôles (ou users) pour les adapter à votre environnement !

On n'a plus qu'à mettre tout ça en place !

Commençons par télécharger mes templates sur notre bucket S3 existant :

aws s3 sync . s3://nom-de-mon-bucket/service-catalog/

Je synchronise ici mon dossier actuel où se trouvent les templates avec le bucket S3 de mon choix sous un dossier service-catalog.

On lance ensuite nos ressources Service Catalog :

aws cloudformation deploy --stack-name service-catalog --template-file service-catalog-1.yml --parameter-overrides CloudFormationBucket=nom-de-mon-bucket

Une fois notre stack en CREATE_COMPLETE, nous allons pouvoir nous connecter à la console Service Catalog et voir notre produit dans la section "Products".

Oui, vous pouvez personnaliser l'apparence du portail avec le logo et les couleurs de votre organisation ! Je vous laisse découvrir tout seuls comment faire cette partie, on va aller droit au but...

On clique sur "Launch product" et on va tout d'abord devoir le nommer et choisir la version qu'on veut provisionner. C'est facile, on n'a qu'une seule version pour le moment !

Dans notre template CloudFormation bucket-s3-v10.yml, on a défini un paramètre où on va établir le nom du bucket à créer. Ce sera le paramètre récupéré par Service Catalog pour l'afficher dans son interface.

Avant de finir, nous devrons indiquer les tags (on a mis un seul avec une valeur obligatoire, mais on peut créer plusieurs choix) et les notifications SNS en option.

Une fois le produit lancé, Service Catalog va démarrer la stack CloudFormation qui va créer notre nouveau bucket S3.

Version 1.1

En fait... un simple bucket S3 c'est pas très intéressant, non ? On va lui rajouter plusieurs choses...

• le chiffrage au repos par défaut
• une lifecycle policy pour que les anciennes versions de nos objets soient archivées sur Glacier
• et le versioning

Voici donc notre template en version 1.1 : s3-bucket-v11.yml

On va mettre à jour notre template Service Catalog pour prendre en compte cette nouvelle version : service-catalog-2.yml

Comme tout à l'heure, on envoie tout sur s3 et on déploie :

aws s3 sync . s3://blog-awss-igor/service-catalog/
aws cloudformation deploy --stack-name service-catalog --template-file service-catalog-2.yml

On va maintenant migrer le bucket qu'on a provisionné avec Service Catalog en version 1.1 ! Pour cela, on va dans la section Provisioned products où on va trouver le produit provisionné tout à l'heure. On clique sur Update et on va ensuite choisir la version 1.1.

Dans la page suivante notre nom de bucket est là, on n'y touche pas. On fini le processus et notre bucket est mis à jour !

Un peu plus de sécurité

Avec ce qu'on a présenté, on a répondu à presque toutes les questions qui ouvraient ce billet de blog, à l'exception de la suivante :

Comment confier à des équipes IT qui n'ont pas d'expertise particulière AWS la tâche de déployer tous ces produits sans leur permettre d'interagir directement avec les services AWS ?

Ici nous avons juste autorisé notre user ou rôle à accéder aux produits dans Service Catalog, mais les actions CloudFormation sont lancées avec les droits propres au user ou au rôle. Autrement dit, si une personne avec des droits très restreints essaie de provisionner notre produit, ça ne marchera sans doute pas. La solution, c'est de fonctionner avec deux rôles : l'un pour les personnes qui vont faire le provisioning (très restreint, avec juste la possibilité d'utiliser Service Catalog) et un second rôle que seul Service Catalog pourra assumer, avec tous les droits nécessaires. Le schéma suivant résume la situation :

Pour mettre tout ça en place, nous allons créer deux rôles, ProvisioningRole et ServiceCatalogRole, dans la troisième et dernière version de notre template : service-catalog-3.yml

aws s3 sync . s3://blog-awss-igor/service-catalog/
aws cloudformation deploy --stack-name service-catalog --template-file service-catalog-3.yml

Cette pratique permet d'imposer une façon standardisée de déployer les produits du catalog, mais permet également de donner un accès très indirect à AWS aux personnes qui ne s'y connaissent pas forcément et à qui on ne donnerait pas un accès à tous les services. On vous conseille de prendre le temps de bien comprendre cette étape pour mettre en places ces restrictions. Si vous avez besoin d'aide sur la mise en oeuvre et la sécurisation de ce genre de scénario, contactez Alter Way ! Nous serons en mesure de vous accompagner et de vous guider sur les bonnes pratiques.

Nettoyage final

Fin de l'exercise... pour enlever les ressources qu'on vient de créer, pensez à enlever (Terminate) chaque produit provisionné dans Service Catalog, puis à supprimer la stack service-catalog.