Si votre (par exemple, une autorisation mal configurée en raison d'une faute de frappe), , où la plupart des événements de sécurité sont analysés ou trouvés. modèle de déploiement GitOps présente des problèmes de sécurité cela sera propagé jusqu'à ce qu'il soit découvert lors de l'exécution 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 ? . Il suit les modifications apportées aux fichiers (généralement des fichiers texte tels que le code source) . C'est le_ de facto _standard dans les systèmes de contrôle de version de nos jours. est un système de contrôle de version distribué open source Git permettant et favorisant un modèle de travail collaboratif 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, des informations beaucoup plus détaillées sur le mécanisme de demande d'extraction de git. voici 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 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. ceci Qu'est-ce que GitOps ? Pour le dire simplement, afin que vous puissiez tirer parti du modèle de déploiement git (demandes d'extraction, restaurations, approbations, etc.) sur votre logiciel. GitOps est juste une méthodologie qui utilise un référentiel git comme source unique de vérité pour vos actifs logiciels Il existe des livres ( , or ), des et d'articles de nous , mais laissez-nous élaborer sur l'objectif de en jetant un coup d'œil sur la façon dont les choses ont évolué dans les dernières années. The Path to GitOps GitOps and Kubernetes GitOps Cloud-native Continuous Deployment livres blancs plus blog que ne pouvons en compter GitOps 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 , et en paraphrasant , un système GitOps est basé sur les principes suivants : 2017 par Weaveworks OpenGitOps : il définit « quoi ». Déclaratif : d'où « git ». Versionné et immuable : un agent observe l'état souhaité et les changements qui se produisent dans le code. Tiré automatiquement : quelqu'un a-t-il mentionné Kubernetes ? Réconciliés en permanence L' (ou agents) s'exécutant sur votre cluster qui observe les objets Kubernetes s'exécutant dessus (définis par un ) . S'il ne correspond pas, il l'application en appliquant les manifestes trouvés dans le référentiel. essence de la méthodologie GitOps est essentiellement un contrôleur Kubernetes ou des contrôleurs CustomResource comparant l'état actuel à l'état spécifié dans le Git repo corrige 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 ou , tous deux de la CNCF. Flux ArgoCD incubateurs de projets 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' 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 , ou , entre autres. infrastructure en tant que code terraform crossplane pulumi Les avantages sont énormes. Vous pouvez gérer votre infrastructure comme s'il s'agissait de code ( 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. c'est Il existe des tonnes d'informations sur ce sujet, mais la est un bon point de départ. ressource suivante 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 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. 2021 GitOps aide à réduire les modifications manuelles en celles qui ont l'état souhaité dans le référentiel Git, mais . corrigeant 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 et le 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 (et en appliquant un peu de créativité). modèle de contrôleur modèle déclaratif les principes GitOps peuvent être appliqués sans Kubernetes 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 « ». De la résolution du problème lorsqu'il est trop tard à sa résolution avant qu'il ne se produise. Shift Security Left 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 : . 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. Éviter/Refuser les modifications manuelles (en évitant la dérive) . 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. Modifications d'annulation 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. Une réponse rapide. À 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 . Traçabilité. d'audit gratuit 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). Reprise après sinistre. 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". Contrôle d'accès. 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 ou des 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 : actions pipelines La définition de l'application , 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 ) qui peuvent être exécutés contre les modifications que vous avez effectuées afin d'éviter les surprises plus tard. Peluchage. est code megalinter Vous pouvez même automatiser la pour exécuter votre application avec les modifications et exécuter des tests sur celle-ci. Essai. création d'un cluster Kubernetes temporaire . En vérifiant les que vous utilisez pour les vulnérabilités avant qu'elles ne soient déployées dans votre environnement. Scan de vulnérabilité images de conteneur En tirant parti de l' , vous pouvez même appliquer des politiques à vos manifestes pour vérifier les problèmes potentiels ou les politiques personnalisées Politique en tant que code. OPA Dernières pensées La et . méthodologie GitOps apporte quelques améliorations au modèle de déploiement des avantages de sécurité à la table sans avoir à ajouter un autre outil 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. Il améliore la posture de sécurité en ajoutant une couche "décalage à gauche" directement au code source Également publié . ici

Flow

Chain

Google

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

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

Trop long; Pour lire

Companies Mentioned

Coins Mentioned

minWi

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

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

Trop long; Pour lire

Companies Mentioned

Coins Mentioned

minWi

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES