Vendredi dernier s'est tenu le premier atelier de la communauté Cloud Sec de Squad.
L'objectif ? Monter un cluster kubernetes avec des nœuds basés sur des VM hébergées chez 4 clouders : Azure, AWS, GCP et IBM. Cela implique de monter la partie VPN/réseau entre les clouders puis d'installer K8bs.
Nous étions 7 experts répartis dans toutes la France : Lyon, Paris, Nantes, et Aix travaillant en commun via Teams. Nous avons été électionnés pour notre implication sur le sujet du cloud (certification, activité sur le réseau social interne, participation à des évènements...). Mais il y a un twist : chacun a travaillé sur un clouder qu'il ne connaissait pas. En solo ou par équipe de 2, tout le monde s’est attelé à la construction de l'environnement.
Première difficulté : s'y retrouver dans l'interface graphique des clouders
-
Les experts GCP pestent contre les multiples écrans Azure, le groupe de ressource est sa facilité de rangement/organisation ne les conquiert pas.
-
Côté AWS, personne ne s'est fait piéger avec l'affichage limité à la région active (c'est toujours irritant quand j'utilise AWS).
-
Le duo travaillant sur GCP s'en sort relativement bien avec l'interface.
-
IBM propose une interface certes austère mais épurée et intuitive.
Le réseau
Nous partons sur un réseau en étoile avec Azure centralisant les différentes connexions venant des autres fournisseurs. À noter que nous aurions pu installer un client VPN sur les VM directement mais nous choisissons d'utiliser des VPN Gateway qui sont plus représentatives d'un environnement réel. Je découvre, malgré 10 ans d'expérience sur Azure, que la VPN Gateway porte en fait le nom de Virtual Network Gateway. La montée des VPN mène à l'échange de nombreuses IP publiques et provoquera un souci qui nous fera perdre 30min : un VPN va pointer sur l'IP publique d'une VM au lieu de la VPN GW bloquant le fonctionnement. La question de la nécessité ou non de BGP et si oui, de quel côté, s'est également posé. L'ingénieur réseau est toujours nécessaire sur le cloud même si son travail est fortement invisibilisé, il est primordial pour une organisation afin de s'assurer que les données empruntent les chemins désirés.
Création des VM
Phase assez simple, le nombre de configuration/paramètre possible sur Azure décontenance un peu les non habitués. Le primo utilisateur AWS fait connaissance avec la difficulté de se connecter à sa 1ere EC2 Linux : AWS fournit un fichier .pem qui sert de clé mais il faut le transformer en .ppk avec une commande particulière pour qu'il soit utilisable dans Putty afin de permettre la connexion SSH. La page d'aide existe mais ce n'est pas exactement intuitif pour une 1ere fois. GCP et IBM, eux, ne posent pas de difficulté sur cette partie.
Installation de Kubernetes et création du cluster
Nous avons utilisé des distributions Linux similaires mais packagées et surtout durcies par les clouders. L'installation des K8s a été assez pénible chez certains (passage de repo en trusted, droit à donner). Le montage du cluster s'est fait via le package KubAdm. Il est relativement simple à utiliser et permet de joindre des nœuds à un cluster avec une seule commande (certes assez longue). Nous n'avons pas utilisé les solutions AKS, EKS... pour se rendre indépendant du clouder afin de pouvoir théoriquement basculer un pod d'un CSP à l'autre. (en 4h nous ne n’avons pas pu simuler la bascule pour voir notamment l'impact réseau).
Anecdote sur IBM Cloud
J'ai travaillé pour une entreprise cliente de l'offre IBM Cloud privé il y a une dizaine d'années et l'offre n'avait le niveau de qualité attendue en termes de performance/élasticité (elle a d'ailleurs fermé depuis). De ce fait, j'étais resté sur une mauvaise image des produits IBM Cloud mais l'interface et le résultat de IBM Cloud Public testé cet après-midi est très prometteur. À noter la mise à disposition d'un calculateur de son empreinte carbone directement dans l'interface (à voir avec l'origine des données et le mode de calcul utilisé) mais c'est une bonne idée de le mettre à disposition des OPS (toute comme la partie coût), car cela permet de se rendre compte de sa consommation et d'essayer d'y faire attention. Comme quoi il ne faut pas rester sur un apriori négatif et ne pas hésiter à tester !
Mon feedback : un exercice hyper plaisant !
Comme très souvent l'outillage est primordial :
- Les salles teams sont une grande avancée avec la possibilité de scinder sa réunion en plusieurs plus petites car cela permet aux gens de travailler en équipe facilement. Un tableau partagé doit être préparer en amont afin de rentrer les informations à partager (IP, Passphrase, clé...) afin d'éviter un quiproquo.
- S'assurer que les souscriptions des clouders sont prêtes à l'avance afin que les participants puissent se lancer rapidement dans l'action. Pour le 4ème clouder, j'étais parti sur Ali Baba de par leur part de marché importante mais après l'ouverture du compte l'interface ne semblait pas complètement traduite et présentait des éléments en chinois. J'ai donc préféré partir sur IBM comme 4ème fournisseur.
Bien qu'ayant des services similaires, les clouders ont des spécificités. Pour simplifier l'atelier, j'avais géré la partie IAM avant son commencement. Arriver à maitriser plusieurs clouders au niveau architecture/sécurité ne se fait pas en quelques mois.
Préparer et réaliser cet atelier a été un plaisir. Cela permet de résoudre l'un des plus grands défauts de la vie de consultant, c'est l'absence de lien entre collègue qui travaille sur des sujets similaires mais chez des clients différents. Ce type d'exercice permet justement de nous rencontrer, d'échanger ensemble, de progresser, le tout dans une bonne ambiance. Entendre à la fin : « tu pourras m'exporter tes commandes pour que je regarde plus tard » entre 2 consultants qui ne se sont probablement jamais vu, est la plus belle preuve de réussite !
Matthieu GAILLARD-MIDOL
Practice Leader Cloud Sec
