K3S – A (long) way to DevSecOps – Épisode 2

Rappel de la saga : A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6, Épisode 7, Épisode 8.

Une question de confiance

La confiance externe

Avant de se poser la question de l’organisation et de la gouvernance la question de la confiance est parfois oubliée ou assimilée telle quelle.

Aujourd’hui il est impossible d’avancer vite et de manière coordonnée sans accorder cette confiance :

• Au matériel utilisé (ces dernières années, le modèle backdoor volontaire et involontaire était fortement utilisé).
• À la couche de virtualisation utilisée (d’autant plus en mode Cloud, quels sont les paramètres de sécurité utilisés pour satisfaire la séparation entre les différents clients). C’est la couche VMWare et/ou OpenStack sur des Public Cloud traditionnels.
• À l’OS utilisé.
• À la distribution de la couche conteneurisation (ici K3S)
• À la robustesse des dépôts des différents éditeurs de la partie infra (OS / Firewall / Equipements réseaux / Virtualisation / Kubernetes / Firmwares et microcodes, ex : Meltdown/Spectre)
• Aux dépôts d’entreprise ou publics dans lesquels sont parfois clonées certains bouts de code.
• Aux dépôts Docker, depuis lesquels sont téléchargés les applicatifs.

On se rend compte ici toute l’importance de SSL aka TLS, et la volonté d’utiliser le protocole dans l’état de l’art pour s’assurer que les échanges effectués entre les différents acteurs sont certifiés et si possible contrôlés (SSL Inspection).

J’aurais donc tendance dans certains des cas à me reposer sur ces fournisseurs et à ne pas m’attarder trop longuement là dessus (surtout pour le besoin personnel de ce projet). On voit donc que l’on peut écarter le risque assez rapidement, et compléter assez facilement tout le chapitre 15 de l’ISO 27002 : Relations avec les fournisseurs.

La confiance interne

La confiance dans l’applicatif et le code

Bien que cette question ne se pose pas sur mon projet perso, en entreprise c’est une autre paire de manches. L’intérêt d’une PKI interne (et d’un IAM – Gestion des Identités) est importante pour instaurer cette confiance par défaut. Cela peut aussi être un problème dans l’idée où on aura peut-être besoin d’optimiser (et de faire du hardening) sur les conteneurs que l’on aura envie de déployer.

Dans certains des cas la mise en place d’une relecture de code peut être une solution. Et la mise en place d’audits automatisés à chaque étape, du développement et du déploiement est une bonne pratique à appliquer.

Ce sera peut-être des étapes que je viendrai ajouter au fur et à mesure des avancées du projet, mais ce n’est clairement pas la priorité pour l’instant.

Chapitre 12.7 de l’ISO 27002 : Gestion des vulnérabilités techniques.

La gestion des droits

La confiance interne ou inter-projets peut se faire en instaurant une gestion des droits sur le cluster Kubernetes. La gestion des namespaces Kubernetes est l’outil idéal pour cette gestion entre plusieurs utilisateurs. Il faudra bien veiller à utiliser différents namespaces pour bien séparer les différentes applications et projets.

Nous survolons ici le chapitre 9 de l’ISO 27002 : Contrôle des accès.

La gestion des secrets

Pour les secrets c’est assez facile de laisser dans le code des logins/mots de passe, et je pense qu’il faut effectivement se poser les bonnes questions avant de commencer à « pusher » du code dans le Git. Kubernetes possède nativement un stockage sécurisé de ces secrets.

Dans une vision traditionnelle du S.I. on peut parler du Bastion. Mais je pense que cette vision reste trop traditionnelle, et les produits sont en train de s’adapter pour devenir des « Vaults », plus adaptés à l’automatisation.

Pour aller plus loin on peut parler du produit Hashicorp Vault. Mais une fois encore c’est plus adapté lorsque c’est l’applicatif qui est designé pour aller puiser les secrets dans le Vault. Nous sommes encore dans une phase transitoire, à l’instar de la gestion du chiffrement qui est rarement bien implémenté par l’applicatif (voir chapitre 10 de l’ISO27002 : Cryptographie).

Une question de compétences

Nous allons aborder aussi une partie très souvent ignorée d’une marche en avant vers l’agilité et le « DevOps ». La compétence c’est finalement la continuité du chapitre précédent, c’est aussi une forme de confiance que l’on porte a soi-même et à ses collègues.

Compétences techniques

Pour moi la compétence technique est très souvent ignorée avant de se lancer dans ce type de projets. L’empilement des couches à fortement aidé à la décorrélation de l’applicatif et de son environnement de fonctionnement. Mais pour ceux qui sont administrateurs de cette grosse machine cela peut devenir problématique. De plus, la sécurité est le membre de l’équipe agile qui arrive en dernier. Il se doit de connaître l’infra et ses intrications. Bref, la route vers le DevSecOps est véritablement longue et semée d’embûches. Il n’y a pas de raccourci pour devenir Hokage.

On touche un petit peu au chapitre 7 de l’ISO 27002 : La gestion RH.

Note : Je ne mets pas ma main à couper sur le déploiement de solutions Cloud magiques et toutes intégrées…

Compétences partagées

Une équipe agile digne de ce nom doit partager les connaissances et chaque membre doit finalement tous contribuer à l’amélioration du produit/service fournit. La communication est donc une des clés pour avancer vers le bon chemin, et l’importance de la sécurité ne doit pas être négligée à chaque étape du projet.

Une question de modèle

Tuer le père

Le DevSecOps est donc un moyen d’enterrer le fameux modèle de l’audit qui révèle des faiblesses, et un an plus tard au cours d’un même audit rien a changé. C’est le modèle marketing par excellence de la sécurité d’entreprise qui a fonctionné et qui fonctionne encore aujourd’hui. On s’aperçoit que finalement nous sommes dans un « fail » permanent.

Exploser les modèles pour les reconstruire : le SRE

Je vais passer très vite sur cette partie, car de nombreux articles en parlent déjà. Et je n’ai pas la prétention d’en parler mieux que les autres. On va juste résumer par ces mots : l’automatisation et le suivi d’indicateurs. On prend juste les outils des DevOps, on porte l’automatisation à son plein potentiel. On relève les indicateurs de monitoring, de sécurité et grâce à l’automatisation ça coute moins cher de corriger et d’apporter des modifications en live. Nous sommes donc par définition dans un processus d’amélioration continue.

Conclusion

Je me rend compte, que je me suis totalement perdu dans la forêt. Et que je n’ai finalement peu expliqué pourquoi le choix de K3S. Mais je pense que ce sont des fondations à aborder pour partir dans un bon état d’esprit. Se poser les bonnes questions et construire en équipe le socle IaC est important. Nous y reviendrons petit à petit par l’exemple.

Note : N’hésitez pas à faire part de vos commentaires sur le site ou Twitter, ça fait toujours plaisir et j’en profiterai pour améliorer les articles.