Je vais poursuivre mes billets sur la sécurisation de la supply chain. Dans ce billet, je vous propose de monter un IDP pour pouvoir mettre en place le principe de moindre privilège sur notre futur serveur Gitlab.

La lecture de ce billet du blog d'eleven labs m'a donné l'idée de le décliner sur le développement à base de code d'infrastructure (Ansible, Terraform, Puppet, Pulumi, Crossplane ...). Pourquoi ? Parce que je vois trop souvent mis de côté au nom de l'agilité, de la rapidité et de la simplicité de mise en œuvre tout un ensemble de bonnes pratiques. Dans un premier temps, je vais définir ce qu'est une dette technique, puis énumérer les différents types de dettes et pour en finir certaines causes.

Il y a un an, je vous présentais R2DevOps, un outil de gestion des templates de pipeline CI/CD de Gitlab. Un an après et à l'occasion d'une nouvelle rencontre, j'ai l'occasion de l'ajouter à la stack d'outils de l'usine logicielle. Cela m'a permis de voir que R2Devops a beaucoup évolué !

Hier, je vous ai présenté comment utiliser cosign pour signer et vérifier vos images Docker. Par contre, j'avais désactivé le stockage des preuves de signature dans le serveur de transparence rekor publique. Aujourd'hui, je vous propose de voir comment avoir un serveur Rekor self-hosted. Attention au moment de l'écriture de ce billet cette fonctionnalité est au status Experimental.

Dans le billet précédent, j'avais introduit la notion de sécurisation de la chaine d'approvisionnement logiciel et surtout pourquoi il est important de la mettre en place. Ce billet parle d'une première solution permettant de signer des conteneurs OCI avec Cosign. L'objectif est d'intégrer ces outils dans une CI Gitlab.

Les concepteurs de Wolfi OS, porté par la société Chainguard se sont fixé comme objectif de produire des images de conteneurs qui répondent aux exigences de sécurité. Par exemple les images officielles ne doivent contenir aucune vulnérabilité critique connue.

A l'image d'asdf, aqua est un nouvel outil permettant d'installer de très nombreux outils. Pa exemple, vous travaillez pour un client qui utilise Kubernetes 1.27 et Terraform 1.5.0. Ensuite, on vous met sur un nouveau projet client qui lui utilise Kubernetes 1.25 et Terraform 1.3.6. Si vous ne gérez pas vos versions correctement cela peut vite tourner au drame avec des incompatibilités ou du code non pris en charge au moment de la livraison de celui-ci.

Sponsorisé par Redhat, le projet open source Podman Desktop vient de passer récemment en version stable 1.0. Podman Desktop permet de créer et d'exécuter des conteneurs localement. Sur la version Linux, il est également possible de piloter des ressources dans des clusters Kubernetes distants.

Trivy fait partie de ma liste d'outils que j'utilise couramment sur poste de développement. Pour ceux qui ne connaissent pas Trivy, il s'agit d'un outil d'audit de sécurité tout-en-un pour les conteneurs. La dernière version apporte l'audit CIS des clusters kubernetes.

Pour déployer une application au sein d'un cluster Kubernetes, on peut le faire de manière classique avec des fichiers de configuration YAML ou un gestionnaire de packages comme Helm. Il existe un troisième moyen qui est de créer un opérateur Kubernetes. Voyons dans un premier temps ce qu'est un opérateur Kubernetes.