Comment appliquer la sécurité à la source à l'aide de GitOps

Si votre modèle de déploiement GitOps présente des problèmes de sécurité (par exemple, une autorisation mal configurée en raison d'une faute de frappe), cela sera propagé jusqu'à ce qu'il soit découvert lors de l'exécution , où la plupart des événements de sécurité sont analysés ou trouvés.

Et si vous pouviez résoudre les problèmes de sécurité potentiels de votre infrastructure à la source ?

Commençons par les bases.

Qu'est-ce que Git ?

Git est un système de contrôle de version distribué open source . Il suit les modifications apportées aux fichiers (généralement des fichiers texte tels que le code source) permettant et favorisant un modèle de travail collaboratif . C'est le_ de facto _standard dans les systèmes de contrôle de version de nos jours.

Vous pouvez avoir votre propre référentiel git localement sur votre ordinateur portable, l'héberger sur votre propre serveur ou utiliser un fournisseur tel que GitLab ou GitHub.

Il existe différents « flux » sur la façon de gérer un référentiel (git-flow, github-flow, etc.), mais un exemple de base sur la façon dont git est utilisé ressemble à ceci : les modifications dans les fichiers sont « validées » par les utilisateurs par "forker" le référentiel et effectuer les modifications appropriées dans une "branche".

Ensuite, l'utilisateur crée une demande (soit "demande d'extraction", "demande de fusion" ou simplement "envoi d'un correctif") pour inclure ces modifications dans le référentiel.

Après cela, une discussion a généralement lieu entre le « propriétaire » et l'utilisateur qui crée la demande, et si tout se passe bien, la modification est acceptée et ajoutée au référentiel.

REMARQUE : Si vous souhaitez en savoir plus, voici des informations beaucoup plus détaillées sur le mécanisme de demande d'extraction de git.

Pour voir un exemple concret, parcourez simplement votre référentiel GitLab ou GitHub open source préféré et parcourez l'onglet Pull Request (ou Merge Request) (ou regardez ceci pour un plaisir). Vous pouvez voir les modifications proposées, les commentaires, les étiquettes, qui a proposé les modifications, les outils exécutant des validations par rapport aux modifications proposées, les notifications envoyées aux personnes qui surveillent le référentiel, etc.

Qu'est-ce que GitOps ?

Pour le dire simplement, GitOps est juste une méthodologie qui utilise un référentiel git comme source unique de vérité pour vos actifs logiciels afin que vous puissiez tirer parti du modèle de déploiement git (demandes d'extraction, restaurations, approbations, etc.) sur votre logiciel.

Il existe des livres ( The Path to GitOps , GitOps and Kubernetes or GitOps Cloud-native Continuous Deployment ), des livres blancs et plus d'articles de blog que nous ne pouvons en compter , mais laissez-nous élaborer sur l'objectif de GitOps en jetant un coup d'œil sur la façon dont les choses ont évolué dans les dernières années.

Avant le cloud, ajouter un nouveau serveur pour héberger votre application prenait des semaines. Vous deviez demander des autorisations, l'acheter et effectuer de nombreuses tâches manuelles. Ensuite, la virtualisation a rendu les choses beaucoup plus faciles. Vous demandez une machine virtuelle avec quelques spécifications et après quelques minutes, vous y avez accès.

Ensuite, le nuage. Demander des serveurs, du réseau, du stockage et même des bases de données, des files d'attente de messagerie, des conteneurs, des éléments d'apprentissage automatique, sans serveur… n'est qu'un appel API ! Vous le demandez et quelques secondes plus tard, vous l'obtenez, comme ça. Vous n'avez qu'à payer pour ce que vous utilisez. Cela signifie également que l'infrastructure peut être gérée comme du code effectuant des appels d'API… et où stockez-vous votre code ? Dans un référentiel git (ou tout autre système de version de contenu).

Le terme GitOps a été inventé en 2017 par Weaveworks , et en paraphrasant OpenGitOps , un système GitOps est basé sur les principes suivants :

• Déclaratif : il définit « quoi ».
• Versionné et immuable : d'où « git ».
• Tiré automatiquement : un agent observe l'état souhaité et les changements qui se produisent dans le code.
• Réconciliés en permanence : quelqu'un a-t-il mentionné Kubernetes ?

L' essence de la méthodologie GitOps est essentiellement un contrôleur Kubernetes ou des contrôleurs (ou agents) s'exécutant sur votre cluster qui observe les objets Kubernetes s'exécutant dessus (définis par un CustomResource ) comparant l'état actuel à l'état spécifié dans le Git repo . S'il ne correspond pas, il corrige l'application en appliquant les manifestes trouvés dans le référentiel.

REMARQUE : Il existe des approches légèrement différentes de GitOps, par exemple, pousser ou tirer, comment gérer la gestion de la configuration, etc. Ce sont des sujets avancés, mais pour l'instant, restons-en aux bases.

Le schéma suivant montre un système GitOps simplifié :

• Un changement de code est soumis au référentiel Git par l'utilisateur.
• Ensuite, un processus est déclenché sur le référentiel pour incorporer ces modifications dans l'application elle-même, notamment en exécutant des outils d'automatisation sur ce nouveau code pour le valider.
• Une fois que tout est en place, l'agent GitOps s'exécutant dans le cluster Kubernetes, qui observe le référentiel, effectue la réconciliation entre l'état souhaité (le code dans le référentiel) et l'état actuel (les objets s'exécutant sur le cluster Kubernetes lui-même).

Être basé sur Git signifie sans friction pour les développeurs. Ils n'ont pas besoin de se soucier d'un nouvel outil avec lequel interagir, mais appliquent plutôt les mêmes pratiques que celles utilisées pour gérer le code dans le référentiel Git.

En parlant d'outils GitOps, il en existe déjà quelques-uns, dont des outils open source comme Flux ou ArgoCD , tous deux incubateurs de projets de la CNCF.

Pour avoir une idée de ce à quoi ressemble une définition d'application via GitOps, voici un exemple d'application simple (stockée dans un référentiel GitHub) gérée par Flux ou ArgoCD.

Avec flux :

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

Avec ArgoCD :

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

Les deux référencent le référentiel Git où les manifestes d'application sont stockés (Déploiements), les NameSpaces et quelques détails supplémentaires.

GitOps contre IaC

L' infrastructure en tant que code est une méthodologie consistant à traiter les éléments constitutifs de votre infrastructure en tant que code à l'aide de différentes techniques et outils. Cela signifie qu'au lieu de créer manuellement votre infrastructure telle que les machines virtuelles, les conteneurs, les réseaux ou le stockage via l'interface Web de votre fournisseur d'infrastructure préféré, vous les définissez en tant que code, puis ceux-ci sont créés/mis à jour/gérés par les outils que vous choisissez, tels que comme terraform , crossplane ou pulumi , entre autres.

Les avantages sont énormes. Vous pouvez gérer votre infrastructure comme s'il s'agissait de code ( c'est du code maintenant) et tirer parti de vos meilleures pratiques de développement (automatisation, tests, traçabilité, contrôle de version, etc.) pour vos actifs d'infrastructure. En fait, il y a une tendance à utiliser "Infrastructure as Software" comme terme à la place, car c'est bien plus qu'un simple code.

Il existe des tonnes d'informations sur ce sujet, mais la ressource suivante est un bon point de départ.

Comme vous l'avez probablement compris, GitOps utilise Infrastructure as Code comme modèle déclaratif pour définir l'infrastructure. En fait, IaC est l'une des pierres angulaires de GitOps ! Mais c'est beaucoup plus car IaC n'impose pas le reste des principes GitOps.

GitOps contre DevOps

Il existe de nombreuses définitions du terme "DevOps". Cela dépend à qui vous demandez, mais pour le dire simplement, "DevOps est la combinaison de pratiques et d'outils pour créer et fournir des logiciels réduisant les frictions et à une vitesse élevée".

Les méthodologies DevOps peuvent tirer parti de GitOps car GitOps fournit un cadre qui correspond aux pratiques DevOps, mais ce n'est pas strictement nécessaire.

Qu'en est-il des NoOps ?

NoOps a été inventé par Forrester en 2021 et il s'agit d'une approche radicale de la gestion des opérations où l'environnement informatique est abstrait et automatisé au point qu'il n'est pas nécessaire de le gérer manuellement.

GitOps aide à réduire les modifications manuelles en corrigeant celles qui ont l'état souhaité dans le référentiel Git, mais l'application d'un véritable NoOps à l'ensemble de l'environnement informatique est un objectif ambitieux plutôt qu'un véritable objectif à ce jour .

GitOps est-il réservé à Kubernetes ?

Non. Kubernetes, le modèle de contrôleur et le modèle déclaratif pour définir les objets Kubernetes correspondent parfaitement à une méthodologie GitOps, mais cela ne signifie pas que les méthodologies GitOps ne peuvent pas être appliquées sans Kubernetes. Il y a quelques défis si vous utilisez GitOps en dehors de Kubernetes, comme la gestion de l'idempotence, la suppression/création des actifs, la gestion des secrets, etc. Mais les principes GitOps peuvent être appliqués sans Kubernetes (et en appliquant un peu de créativité).

GitOps et sécurité

Parlons maintenant des aspects de sécurité. La plupart des outils de sécurité détectent les vulnérabilités et les problèmes potentiels au moment de l'exécution (trop tard). Afin de les corriger, soit un processus manuel réactif doit être effectué (par exemple, modifier directement un paramètre dans votre objet k8s avec kubectl edit) ou idéalement, le correctif se produira à la source et se propagera tout au long de votre chaîne d'approvisionnement. C'est ce qu'on appelle « Shift Security Left ». De la résolution du problème lorsqu'il est trop tard à sa résolution avant qu'il ne se produise.

Cela ne signifie pas que tous les problèmes de sécurité peuvent être résolus à la source, mais l'ajout d'une couche de sécurité directement à la source peut éviter certains problèmes.

En premier lieu, les recommandations générales de sécurité s'appliquent.

• Réduire la surface d'attaque
• Crypter les secrets (en utilisant des secrets externes ou des secrets scellés)
• Segmentation du réseau
• RBAC
• Maintenir le logiciel à jour
• Appliquer le moindre privilège
• Surveiller et mesurer
• …

Voyons quelques scénarios où la méthodologie GitOps peut améliorer votre sécurité en général :

• Éviter/Refuser les modifications manuelles (en évitant la dérive) . Le référentiel Git est la source de vérité. Si vous essayez de modifier la définition de l'application, l'outil GitOps annulera ces modifications en appliquant la version stockée dans le référentiel Git.

• Modifications d'annulation . Imaginez que vous avez introduit un problème de sécurité potentiel dans un commit spécifique en modifiant un paramètre dans le déploiement de votre application. En tirant parti des fonctionnalités de Git, vous pouvez annuler la modification si nécessaire directement à la source et l'outil GitOps redéploiera votre application sans interaction de l'utilisateur.

• Une réponse rapide. Si vous constatez que vous utilisez une image de conteneur vulnérable dans votre application (par exemple, MariaDB), il vous suffit de créer un PR pour mettre à jour la balise dans le fichier de déploiement et l'outil GitOps utilisera la nouvelle balise dans un nouveau déploiement.

• Traçabilité. À l'aide des fonctionnalités de Git, vous pouvez facilement vérifier quand un fichier a été modifié, les modifications elles-mêmes et l'utilisateur qui a promu les modifications. Vous disposez d'un journal d'audit gratuit .

• Reprise après sinistre. Encore une fois, le référentiel Git est la source de vérité. Si vous avez besoin de redéployer votre application parce que quelque chose s'est passé, la définition est là (bien sûr, vous devez avoir un plan de reprise après sinistre pour d'autres éléments tels que les données elles-mêmes).
• Contrôle d'accès. Vous pouvez appliquer différentes autorisations à différents utilisateurs sur vos référentiels Git et même des politiques telles que "ne fusionner un changement qu'après deux avis positifs".

Ces avantages sont suffisamment bons pour justifier l'utilisation des méthodologies GitOps pour améliorer votre posture de sécurité et ils sont sortis de la boîte, mais GitOps est une combinaison de quelques autres choses. Nous pouvons faire beaucoup plus. GitHub, GitLab et d'autres fournisseurs de référentiels Git vous permettent d'exécuter des actions ou des pipelines en fonction des modifications que vous effectuez dans votre référentiel Git, y compris par une demande d'extraction, de sorte que les possibilités sont infinies. Quelques exemples :

• Peluchage. La définition de l'application est code , que se passe-t-il si la définition est vérifiée pour une mauvaise syntaxe, des paramètres manquants, etc. ? Il existe des outils (tels que le megalinter ) qui peuvent être exécutés contre les modifications que vous avez effectuées afin d'éviter les surprises plus tard.

• Essai. Vous pouvez même automatiser la création d'un cluster Kubernetes temporaire pour exécuter votre application avec les modifications et exécuter des tests sur celle-ci.

• Scan de vulnérabilité . En vérifiant les images de conteneur que vous utilisez pour les vulnérabilités avant qu'elles ne soient déployées dans votre environnement.

• Politique en tant que code. En tirant parti de l' OPA , vous pouvez même appliquer des politiques à vos manifestes pour vérifier les problèmes potentiels ou les politiques personnalisées

Dernières pensées

La méthodologie GitOps apporte quelques améliorations au modèle de déploiement et des avantages de sécurité à la table sans avoir à ajouter un autre outil .

Il améliore la posture de sécurité en ajoutant une couche "décalage à gauche" directement au code source et grâce à la flexibilité du modèle de demande d'extraction, vous pouvez facilement ajouter des contrôles de sécurité supplémentaires sans affecter ni modifier le temps d'exécution.

Également publié ici .