Une histoire de pizza

En tant que fou (vous en conviendrez) il est de mon devoir de raconter, pour divertir, des fables à mes hôtes. Aujourd’hui, je vous raconte l’une d’entre elles que j’affectionne et que je raconte à l’occasion en présentation client. Bienvenue dans l’esprit dérangé et les approximations ubuesques qui me caractérisent.

C’est l’histoire d’un homme qui, fort affamé, se rend dans la boulangerie voisine acheter une mini-pizza à emporter. Charmante et joviale, la commerçante lui offre alors en cadeau des couverts en plastique pour découper son repas. Alors de retour dans son terrier, c’est en si tentant de consommer la pizza que les couverts offerts se brisent. Drame. Désespoir. Colère. La pizza est délicieuse, la boulangère charmante, mais l’homme jura alors qu’il n’y retournerait plus.

La morale de cette histoire est qu’il ne faut pas négliger les outils que vous mettez à disposition des équipes que vous nourrissez de la lumière du Cloud.

Notre métier de consultant est avant tout de permettre aux équipes de consommer la ressource que nous mettons en place, car si les outils que nous leur fournissons sont caduques, il y aura un rejet des outils (les couverts en plastique), du service cloud (la pizza), et du fournisseur de l’outil (la boulangère) quand bien même le consultant D2SI fournissant l’outil est tout à fait charmant et sympa. Quelques exemples ci dessous (toute ressemblance avec des projets client n’est pas du tout fortuite).

Celui qui impose, propose

Consultant AWS, vous en avez assez d’avoir tous ces utilisateurs IAM à gérer, dans différents comptes. Un matin, vous vous êtes chauffé et vous avez mis en place des rôles cross-account pour accéder aux autres comptes AWS, et un seul compte AWS qui contiendra les utilisateurs IAM.

Fort de l’enseignement de la fable de la boulangère, vous avez préparé des scripts et des exemples de configuration à installer par tous les développeurs pour leur permettre de continuer à consommer les ressources des comptes, cette fois-ci avec un rôle cross-account.

Dans la continuité, vous suivrez et serez attentif aux retours sur ces outils, afin de permettre de les améliorer dans le futur, car il n’est pas impossible que vous ayez oublié que le Jenkins des développeurs utilise un compte de service et non un rôle.

Celui qui renforce, permet

Client d’un grand compte sur AWS, vous avez reçu le retour d’un audit de sécurité et on vous a remonté que votre politique à l’égard du MFA n’est pas assez restrictive. En effet, celui-ci n’étant pas obligatoire, beaucoup de personnes ne l’ont pas activé.

Ni une, ni deux, vous ajoutez une policy pour forcer les utilisateurs à mettre un MFA, sans quoi, les ressources ne seront disponibles qu’en lecture. Immédiatement après, plusieurs personnes se plaignent qu’ils ne peuvent plus modifier les ressources programmatiquement, alors que le MFA est actif sur leur utilisateur en console et que « à la main » ça marche.

Ignorant les cas d’utilisation de vos équipes, vous avez oublié que les AccessKey et SecretKey AWS sont par défaut sans MFA. Pour avoir l’authentification triple dessus, il faut explicitement demander un token et générer des accès temporaires, ce qui est un peu long à faire en cli:

aws sts get-session-token --serial-number arn-of-the-mfa-device --token-code code-from-token

Heureusement pour vous, il existe des outils comme aws-mfa qui permettent d’automatiser tout cela. Il ne vous reste plus qu’à expliquer sans attendre à vos utilisateurs comment utiliser cet outil, sans quoi, votre renforcement des policy sur le MFA sera rapidement supprimé sous la pression du management: « mes équipes se plaignent que vous les empêchez de travailler « .

Celui qui orchestre bat la mesure

Il y a du rififi dans vos équipes car en ce moment, un grand projet d’automatisation des déploiements est en route. Architecte de solution, vous avez monté un Jenkins et avez expliqué aux développeurs comment utiliser les branches pour déployer des environnements différents, mais le peu d’expérience de chacun dans l’utilisation de git freine l’adoption de l’automatisation.

La fable de la boulangère nous guide alors dans la solution à cette problématique: s’ils ne savent pas faire, c’est à vous de leur apprendre. Bien que le code ne soit pas votre métier, si vous souhaitez réussir cette aventure cela sera à vous de proposer des journées de workshop ou des formations sur git, les branches et la gestion du code afin de pouvoir rendre plus à l’aise les développeurs sur ce sujet et qu’ils puissent enfin embrasser l’automatisation via les outils que vous avez déployés.

Au four et au moulin

En bref, si vous êtes architecte, ops, devops, ou « le mec de l’IT », prenez vos responsabilités et donnez aux utilisateurs les outils pour consommer votre ressource. Descendez les voir, aidez-les, et si votre chef vous demande pourquoi vous perdez du temps avec ces équipes, invitez-le à manger une pizza à la boulangerie.