Déploiements sécurisés avec Config Management

Ce document explique aux opérateurs de cluster et aux administrateurs de plate-forme comment déployer des modifications en toute sécurité dans plusieurs environnements à l'aide de Config Management. Config Management peut vous aider à éviter les erreurs qui affectent simultanément tous vos environnements.

Config Management vous permet de gérer des clusters uniques, des clusters mutualisés et des configurations multicluster Kubernetes à l'aide de fichiers stockés dans un dépôt Git. Config Management combine trois technologies : Config Sync, Policy Controller et Config Connector. Config Sync surveille les mises à jour de tous les fichiers du dépôt Git et applique automatiquement les modifications à tous les clusters appropriés. Policy Controller gère et applique les stratégies relatives aux objets de vos clusters. Config Connector utilise les ressources personnalisées Google Kubernetes Engine (GKE) pour gérer les ressources cloud.

Les configurations Config Sync peuvent représenter plusieurs éléments, y compris les suivants :

Config Management est particulièrement adapté au déploiement des configurations, des stratégies et des charges de travail nécessaires à l'exécution de la plate-forme que vous créez sur GKE Enterprise (par exemple, les agents de sécurité, les agents de surveillance et les gestionnaires de certificats).

Bien que vous puissiez déployer des applications destinées aux utilisateurs avec Config Management, nous vous déconseillons d'associer leur cycle de vie de publication à celui des charges de travail administratives mentionnées précédemment. Nous vous recommandons plutôt d'utiliser un outil dédié au déploiement d'applications, tel qu'un outil de déploiement continu, afin que les équipes puissent gérer leur calendrier de mise en ligne.

Config Management est un produit puissant capable de gérer de nombreux éléments. Vous avez donc besoin de garde-fous pour éviter les erreurs qui ont un impact majeur. Ce document décrit plusieurs méthodes permettant de créer des garde-fous. La première section aborde les déploiements par étapes, la deuxième section traite des tests et des validations. La troisième section explique comment utiliser Policy Controller pour créer des garde-fous. La quatrième section explique comment surveiller les déploiements Config Management.

Vous pouvez utiliser la plupart des méthodes décrites dans ce document, même si vous utilisez uniquement Config Sync et non le produit Config Management complet. Si vous n'utilisez pas le produit Config Management complet, mais que vous souhaitez tout de même implémenter les méthodes impliquant Policy Controller, vous pouvez le faire à l'aide de Gatekeeper. Les exceptions à cette règle sont les méthodes qui s'appuient sur la page Config Management de la console Google Cloud, telles que la mise à jour de la configuration Config Management dans la console Google Cloud. Vous pouvez également utiliser plusieurs des méthodes décrites dans ce document en même temps. Dans la section suivante, un tableau indique les méthodes compatibles pour une utilisation simultanée.

Implémenter des déploiements par étapes avec Config Management

Dans un environnement multicluster, ce qui est une situation courante pour les utilisateurs de GKE Enterprise, nous vous déconseillons d'appliquer une modification de configuration à l'ensemble des clusters en même temps. Un déploiement par étapes, cluster par cluster, ou même espace de noms par espace de noms, si vous utilisez des espaces de noms comme limite entre les applications, est beaucoup plus sécurisé, car cela réduit le rayon d'action de toute erreur.

Voici plusieurs façons de mettre en œuvre des déploiements par étapes avec Config Management:

  • Utilisez des commits ou des tags Git pour appliquer manuellement les modifications que vous souhaitez aux clusters.
  • Utilisez les branches Git pour appliquer automatiquement les modifications lorsque celles-ci sont fusionnées. Vous pouvez utiliser différentes branches pour différents groupes de clusters.
  • Utilisez les objets ClusterSelector et NamespaceSelector pour appliquer de manière sélective des modifications aux sous-groupes de clusters ou d'espaces de noms.

Toutes les méthodes de déploiement par étapes présentent des avantages et des inconvénients. Le tableau suivant indique les méthodes que vous pouvez utiliser en même temps.

X est-il compatible avec Y ? Commits ou tags Git Branches Git Sélecteurs de clusters Sélecteurs d'espace de noms
Commits ou tags Git Incompatible Compatible Compatible
Branches Git Incompatible Compatible Compatible
Sélecteurs de clusters Compatible Compatible Compatible
Sélecteurs d'espace de noms Compatible Compatible Compatible

L'arbre de décision suivant vous aide à décider quand utiliser l'une des méthodes de déploiement par étapes.

Arbre de décision des méthodes de déploiement

Utiliser des commits ou des tags Git

Par rapport aux autres méthodes de déploiement par étapes, l'utilisation de commits ou de tags Git offre le plus de contrôle et est la plus sûre. Vous pouvez utiliser la page Config Management de la console pour mettre à jour plusieurs clusters en même temps. Utilisez cette méthode si vous souhaitez appliquer les modifications à vos clusters une par une et contrôler exactement quand cela se produit.

Avec cette méthode, vous "épinglez" chaque cluster à une version spécifique (un commit ou un tag) de votre dépôt Config Management. Cette méthode est similaire à l'utilisation du commit Git en tant que tag d'image de conteneur. Pour implémenter cette méthode, spécifiez le commit, le tag ou le hachage dans le champ spec.git.revision de la ressource personnalisée RootSync ou RepoSync.

Si vous gérez vos ressources personnalisées RootSync ou RepoSync avec un outil tel que kustomize, vous pouvez réduire la quantité de travail manuel nécessaire pour déployer les modifications. Avec un tel outil, il vous suffit de modifier le paramètre revision à un seul endroit, puis d'appliquer de manière sélective la nouvelle ressource personnalisée RootSync ou RepoSync à vos clusters, dans l'ordre et au rythme de votre choix.

De plus, si vous utilisez Config Management (et non Config Sync), vous avez accès à la page Config Management dans la console Google Cloud. Cette page vous permet de mettre à jour le paramètre revision dans plusieurs clusters appartenant au même parc en même temps. Si vous disposez d'un système automatisé pour mettre à jour la configuration Config Management, nous vous déconseillons d'utiliser la console pour la modifier.

Par exemple, la définition de RootSync suivante configure Config Management pour qu'il utilise la balise 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: git@example.com:anthos/config-management.git
    revision: 1.2.3
    auth: ssh

Si vous appliquez cette configuration à votre cluster, Config Management utilisera le tag 1.2.3 du dépôt example.com:anthos/config-management.git.

Pour mettre à jour un cluster, remplacez le champ spec.git.revision par la nouvelle valeur du cluster. Cela vous permet de définir quels clusters sont mis à jour et à quel moment. Si vous devez annuler une modification, redéfinissez le champ spec.git.revision sur sa valeur correspondante.

Le schéma suivant illustre le processus de déploiement de cette méthode. Tout d'abord, vous devez valider les modifications dans le dépôt Config Management, puis mettre à jour les définitions RootSync sur tous les clusters:

Processus de déploiement des commits et des tags Git

Nous vous recommandons d'effectuer les actions suivantes :

  • Utilisez des ID de commit Git plutôt que des tags. En raison du fonctionnement de Git, vous avez la garantie qu'ils ne changeront jamais. Par exemple, un git push --force ne peut pas modifier le commit utilisé par Config Management. Cette approche est utile à des fins d'audit et pour savoir quel commit vous utilisez dans les journaux. De plus, contrairement aux tags, il n'y a pas d'étape supplémentaire de validation des ID.
  • Si vous préférez utiliser des tags Git plutôt que des ID de commit Git et que vous utilisez GitLab, protégez les tags pour éviter qu'ils ne soient déplacés ou supprimés. Les autres solutions Git majeures ne disposent pas de cette fonctionnalité.
  • Si vous souhaitez mettre à jour plusieurs clusters en même temps, vous pouvez le faire sur la page de la console Config Management. Pour que vous puissiez mettre à jour plusieurs clusters simultanément, ils doivent faire partie du même parc (et se trouver dans le même projet).

Utiliser des branches Git

Si vous souhaitez que les modifications soient appliquées aux clusters dès leur fusion dans votre dépôt Git, configurez Config Management pour utiliser des branches Git au lieu de commits ou de tags. Avec cette méthode, vous pouvez créer plusieurs branches de longue durée dans votre dépôt Git et configurer Config Management dans différents clusters pour lire sa configuration à partir de différentes branches.

Par exemple, un modèle simple comporte deux branches :

  • Une branche staging pour les clusters qui ne sont pas de production.
  • Une branche master pour les clusters de production.

Pour les clusters hors production, créez l'objet RootSync ou RepoSync avec le champ spec.git.branch défini sur staging. Pour les clusters de production, créez l'objet RootSync ou RepoSync avec le paramètre spec.git.branch défini sur master.

Par exemple, la définition de RootSync suivante configure Config Management pour utiliser la branche master:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  git:
    repo: git@example.com:anthos/config-management.git
    branch: master
    auth: ssh

Le schéma suivant illustre le processus de déploiement de cette méthode :

Processus de déploiement pour les branches Git.

Vous pouvez adapter ce modèle à des besoins spécifiques, en utilisant plus de deux branches ou en utilisant des branches mappées vers d'autres environnements. Si vous devez effectuer un rollback d'une modification, utilisez la commande git revert pour créer un commit sur la même branche qui rétablit les modifications à partir du commit précédent.

Nous vous recommandons d'effectuer les actions suivantes :

  • Lorsque vous travaillez avec plusieurs clusters, utilisez au moins deux branches Git pour distinguer les clusters de production des clusters qui ne sont pas de production.
  • La plupart des solutions Git vous permettent d'utiliser la fonctionnalité des branches protégées pour éviter les suppressions ou les modifications non vérifiées de ces branches. Pour en savoir plus, consultez la documentation sur GitHub, GitLab et Bitbucket.

Utiliser des objets ClusterSelector et NamespaceSelector

Les branches Git sont un bon moyen d'effectuer un déploiement par étapes de modifications sur plusieurs clusters qui auront à terme toutes les mêmes stratégies. Toutefois, si vous souhaitez déployer une modification uniquement sur un sous-ensemble de clusters ou d'espaces de noms, utilisez les objets ClusterSelector et NamespaceSelector. Ces objets ont un objectif similaire : ils ne vous permettent d'appliquer des objets qu'aux clusters ou aux espaces de noms possédant des libellés spécifiques.

Exemple :

  • À l'aide des objets ClusterSelector, vous pouvez appliquer différentes stratégies aux clusters, en fonction du pays dans lequel ils se trouvent, pour différents taux de conformité.
  • En utilisant des objets NamespaceSelector, vous pouvez appliquer différentes stratégies aux espaces de noms utilisés par une équipe interne et par un prestataire externe.

Les objets ClusterSelector et NamespaceSelector vous permettent également de mettre en œuvre des méthodologies de test et de publication avancées, telles que :

  • Les versions Canary de stratégies, où vous déployez une nouvelle stratégie sur un petit sous-ensemble de clusters et d'espaces de noms pendant une longue période pour étudier l'impact de la stratégie.
  • Les tests A/B, dans lesquels vous déployez différentes versions de la même stratégie sur différents clusters afin d'étudier la différence de l'impact des versions de stratégies, puis choisissez la plus performante à déployer partout.

Par exemple, imaginons une organisation avec plusieurs clusters de production. L'équipe chargée de la plate-forme a déjà créé deux catégories de clusters de production, appelées canary-prod et prod, à l'aide des objets Config Management, Cluster et ClusterSelector (consultez Utiliser les objets ClusterSelector).

L'équipe chargée de la plate-forme souhaite déployer une stratégie avec Policy Controller pour appliquer la présence d'un libellé d'équipe sur les espaces de noms afin d'identifier l'équipe à laquelle chaque espace de noms appartient. Elle a déjà déployé une version de cette stratégie en simulation et elle souhaite désormais l'appliquer sur un petit nombre de clusters. À l'aide des objets ClusterSelector, elle crée deux ressources K8sRequiredLabels différentes, qui sont appliquées à différents clusters.

  • La ressource K8sRequiredLabels est appliquée aux clusters de type prod, avec un paramètre enforcementAction défini sur dryrun :

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: prod
Spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

  • La ressource K8sRequiredLabels est appliquée aux clusters de type canary-prod, sans le paramètre enforcementAction, ce qui signifie que la stratégie est effectivement appliquée :

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: canary-prod
spec:
  match:
    kinds:
      - apiGroups: [""]
    kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

L'annotation configmanagement.gke.io/cluster-selector permet à l'équipe d'appliquer la stratégie uniquement dans des clusters de type canary-prod, empêchant ainsi les effets secondaires non désirés sur l'ensemble du parc de production. Pour plus d'informations sur la fonctionnalité de simulation de Policy Controller, consultez la section Créer des contraintes.

Nous vous recommandons d'effectuer les actions suivantes :

  • Utilisez les objets ClusterSelector et NamespaceSelector si vous devez appliquer une modification de configuration à un sous-ensemble de clusters ou d'espaces de noms indéfiniment ou pendant une longue période.
  • Si vous déployez une modification à l'aide de sélecteurs, soyez très prudent. Si vous utilisez des commits Git, toute erreur n'affecte qu'un cluster à la fois, car vous déployez cluster par cluster. Toutefois, si vous utilisez des branches Git, toute erreur peut affecter tous les clusters utilisant cette branche. Si vous utilisez des sélecteurs, l'erreur peut affecter tous les clusters simultanément.

Mettre en œuvre des avis, des tests et des validations

L'un des avantages de Config Management est qu'il gère tout de manière déclarative : les ressources Kubernetes, les ressources cloud et les règles. Cela signifie que les fichiers d'un système de gestion de contrôle des sources représentent les ressources (fichiers Git, dans le cas de Config Management). Cette caractéristique vous permet de mettre en œuvre des workflows de développement que vous utilisez déjà pour le code source d'une application : les avis et les tests automatisés.

Mettre en œuvre des avis

Étant donné que Config Management est basé sur Git, vous pouvez utiliser votre solution Git préférée pour héberger le dépôt Config Management. Votre solution Git dispose probablement d'une fonctionnalité de révision du code, que vous pouvez utiliser pour examiner les modifications apportées au dépôt Config Management.

Les bonnes pratiques pour examiner les modifications apportées au dépôt Config Management sont les mêmes qu'avec une révision de code normale, comme suit:

En raison du caractère sensible du codebase Config Management, nous vous recommandons également, si possible avec votre solution Git, d'effectuer les configurations suivantes:

En utilisant ces différentes fonctionnalités, vous pouvez appliquer des approbations pour chaque demande de modification apportée au codebase Config Management. Par exemple, vous pouvez vérifier que chaque modification est approuvée au moins par un membre de l'équipe chargée de la plate-forme (qui gère le parc de clusters), et par un membre de l'équipe de sécurité (chargé de définir et mettre en œuvre des stratégies de sécurité).

Nous vous recommandons d'effectuer les actions suivantes :

  • Appliquez des examens par des pairs sur le dépôt Config Management et protégez les branches Git utilisées par vos clusters.

Mettre en œuvre des tests automatisés

Une bonne pratique courante lorsque vous travaillez sur un codebase consiste à mettre en œuvre l'intégration continue. Cela signifie que vous configurez les tests automatisés à exécuter lorsqu'une demande de modification est créée ou mise à jour. Les tests automatisés peuvent détecter de nombreuses erreurs avant qu'un utilisateur n'examine la demande de modification. Cela permet de renforcer la boucle de rétroaction pour le développeur. Vous pouvez mettre en œuvre la même idée, en utilisant les mêmes outils, pour le dépôt Config Management.

Par exemple, pour commencer, vous devez exécuter la commande nomos vet automatiquement en cas de nouvelles modifications. Cette commande vérifie que la syntaxe de votre dépôt Config Management est valide. Vous pouvez mettre en œuvre ce test à l'aide de Cloud Build en suivant le tutoriel Valider les configurations. Vous pouvez intégrer Cloud Build aux options suivantes :

Comme vous pouvez le voir dans le tutoriel Valider les configurations, le test est effectué à l'aide d'une image de conteneur. Vous pouvez donc mettre en œuvre le test dans toute solution d'intégration continue qui exécute des conteneurs, et pas uniquement Cloud Build. Plus précisément, vous pouvez le mettre en œuvre avec GitLab CI en suivant cet exemple, qui inclut également des tests pour Policy Controller.

Pour renforcer encore la boucle de rétroaction, vous pouvez demander aux utilisateurs d'exécuter la commande nomos vet en tant que hook de pré-commit Git. Il est possible que certains utilisateurs n'aient pas accès aux clusters Kubernetes gérés par Config Management et ne puissent pas exécuter la validation complète à partir de leur poste de travail. Exécutez la commande nomos vet --clusters "" pour limiter la validation aux vérifications sémantiques et syntaxiques.

Vous pouvez mettre en œuvre tout autre test dont vous pensez avoir besoin ou utile. Si vous utilisez Policy Controller, vous pouvez mettre en œuvre des tests automatisés des modifications suggérées par rapport à ses stratégies, comme indiqué dans la section Tester les modifications par rapport aux stratégies de Policy Controller.

Nous vous recommandons d'effectuer les actions suivantes :

  • Mettre en œuvre des tests dans un pipeline d'intégration continue. Exécutez au moins la commande nomos vet sur toutes les modifications suggérées.

Utiliser Policy Controller

Policy Controller est un contrôleur d'admission dynamique Kubernetes. Lorsque vous installez et configurez Policy Controller, Kubernetes peut rejeter les modifications qui ne sont pas conformes aux règles prédéfinies, appelées "stratégies".

Voici deux exemples de cas d'utilisation de Policy Controller :

  • Exiger la présence de libellés spécifiques sur des objets Kubernetes,
  • Empêcher la création de pods privilégiés.

Une bibliothèque de modèles de stratégie est disponible pour mettre en œuvre les stratégies les plus couramment utilisées, mais vous pouvez écrire votre propre langage avec un langage puissant nommé Rego. À l'aide de Policy Controller, vous pouvez, par exemple, restreindre les noms d'hôte que les utilisateurs peuvent configurer dans une entrée (pour plus d'informations, consultez ce tutoriel).

Tout comme Config Sync, Policy Controller fait partie du produit Config Management. Le contrôleur de stratégie et Config Sync présentent des cas d'utilisation différents, mais complémentaires :

  • Config Sync est un outil de type GitOps qui vous permet de créer n'importe quel objet Kubernetes, éventuellement dans plusieurs clusters en même temps. Comme mentionné dans l'introduction, Config Sync est particulièrement utile pour gérer les stratégies.
  • Policy Controller vous permet de définir des stratégies pour les objets pouvant être créés dans Kubernetes. Vous définissez ces stratégies dans des ressources personnalisées, qui sont des objets Kubernetes eux-mêmes.

Les fonctionnalités précédentes créent une relation bidirectionnelle entre les deux applications. Vous pouvez utiliser Config Sync pour créer des stratégies appliquées par Policy Controller et utiliser ces stratégies pour contrôler exactement les objets que Config Sync (ou tout autre processus) peut créer, comme indiqué ici dans le schéma suivant :

Config Sync et Policy Controller.

Le dépôt Git, Config Sync, Policy Controller, Kubernetes, un système de déploiement continu (CD) et les utilisateurs interagissent les uns avec les autres comme suit :

  • Les utilisateurs interagissent avec le dépôt Git Config Management pour créer, mettre à jour ou supprimer des objets Kubernetes.
  • Config Sync lit sa configuration à partir du dépôt Git de Config Management.
  • Config Sync interagit avec le serveur d'API Kubernetes pour créer des objets, y compris des stratégies pour Policy Controller.
  • Le système CD interagit également avec le serveur d'API Kubernetes pour créer des objets. Il peut créer des contraintes pour Policy Controller. Toutefois, nous vous recommandons d'utiliser Config Management pour ce cas d'utilisation, car il vous offre un endroit centralisé pour gérer et tester les contraintes.
  • Le serveur d'API Kubernetes accepte ou refuse la création d'objets par Config Sync et par le système CD, en fonction de la réponse de Policy Controller.
  • Policy Controller renvoie cette réponse en fonction des stratégies qu'il lit depuis le serveur de l'API Kubernetes.

Le schéma suivant illustre ces interactions :

Interactions entre le dépôt Git, Config Sync, Policy Controller, Kubernetes, un système de déploiement continu et les utilisateurs.

Policy Controller peut éviter les cas de non-respect des stratégies qui échappent aux examinateurs manuels et aux tests automatisés. Vous pouvez donc l'envisager comme la dernière ligne de défense pour vos clusters Kubernetes. Policy Controller devient également plus utile à mesure que le nombre d'examinateurs manuels augmente pour Config Management. En raison du phénomène de la fuite sur les réseaux sociaux, plus vous avez d'examinateurs, plus il est probable qu'ils appliquent les stratégies définies de votre organisation de manière cohérente.

Tester les modifications par rapport aux stratégies Policy Controller

Si vous utilisez Policy Controller, vous pouvez ajouter quelques étapes au pipeline d'intégration continue (consultez la page Mettre en œuvre des tests automatisés) pour tester automatiquement les modifications suggérées par rapport aux stratégies. L'automatisation des tests permet d'obtenir des commentaires plus rapides et plus visibles pour la personne qui suggère la modification. Si vous ne testez pas les modifications par rapport aux règles du pipeline d'intégration continue, vous devez vous appuyer sur le système décrit dans la section Surveiller les déploiements pour être alerté en cas d'erreurs de synchronisation de Config Management. Le fait de tester les modifications par rapport aux stratégies expose clairement à la personne qui suggère la modification des stratégies qu'elle détecte.

Vous pouvez mettre en œuvre ce test dans Cloud Build en suivant le tutoriel Utiliser Policy Controller dans un pipeline CI. Comme indiqué précédemment dans la page Mettre en œuvre des tests automatisés, vous pouvez intégrer Cloud Build à GitHub et Bitbucket. Vous pouvez également mettre en œuvre ce test avec GitLab CI. Consultez ce dépôt pour obtenir un exemple de mise en œuvre.

Nous vous recommandons d'effectuer les actions suivantes :

  • Si vous utilisez Policy Controller, validez les modifications suggérées par rapport à ses stratégies dans votre pipeline d'intégration continue.

Suivre les déploiements

Même si vous mettez en œuvre toutes les mesures couvertes dans ce document, des erreurs peuvent toujours se produire. Voici deux types courants d'erreurs :

  • Erreurs qui ne posent aucun problème à Config Sync lui-même, mais empêchent vos charges de travail de fonctionner correctement, comme une stratégie NetworkPolicy trop restrictive qui empêche les composants de votre charge de travail de communiquer.
  • Erreurs empêchant Config Sync d'appliquer les modifications à un cluster, telles qu'un fichier manifeste Kubernetes non valide ou un objet refusé par un contrôleur d'admission. Les méthodes expliquées précédemment devraient détecter la plupart de ces erreurs.

Détecter les erreurs décrites dans le premier point précédent est presque impossible au niveau de Config Management, car cela nécessite de comprendre l'état de chacune de vos charges de travail. Pour cette raison, il est préférable de détecter ces erreurs par votre système de surveillance existant, qui vous avertit lorsqu'une application présente un dysfonctionnement.

La détection des erreurs décrites dans le deuxième point précédent, qui doit être atténué si vous avez mis en œuvre tous les garde-fous, nécessite une configuration spécifique. Par défaut, Config Management écrit les erreurs dans ses journaux (que vous trouverez par défaut dans Cloud Logging). Les erreurs sont également affichées sur la page de la console Config Management. Ni les journaux, ni la console ne suffisent généralement à détecter les erreurs, car vous ne les utilisez probablement pas toujours. Le moyen le plus simple d'automatiser la détection des erreurs consiste à exécuter la commande nomos status, qui indique si une erreur se produit dans un cluster.

Vous pouvez également configurer une solution plus avancée avec des alertes automatiques pour les erreurs. Config Management expose les métriques au format Prometheus. Pour en savoir plus, consultez la section Surveiller Config Management.

Une fois que vous disposez des métriques Config Management dans votre système de surveillance, créez une alerte pour être averti lorsque la métrique gkeconfig_monitor_errors est supérieure à 0. Pour plus d'informations, consultez la section Gérer les règles d'alerte pour Cloud Monitoring ou les règles d'alerte pour Prometheus.

Résumé des mécanismes pour des déploiements sécurisés avec Config Management

Le tableau suivant récapitule les différents mécanismes décrits précédemment dans ce document. Aucun de ces mécanismes n'est exclusif. Vous pouvez choisir de les utiliser tous ou une partie, à des fins différentes.

Mécanisme Points forts Points faibles Exemple d'utilisation
ID de commit et tags Git Utilisez des ID ou des tags de commit Git spécifiques pour contrôler avec précision les modifications de cluster appliquées. N'utilisez pas d'ID de commit ni de tags Git pour les différences à long terme entre les clusters. Utilisez des sélecteurs de cluster. Tous vos clusters sont configurés pour appliquer le commit Git 12345. Apportez une modification avec un nouveau commit, abcdef, que vous souhaitez tester. Vous devez modifier la configuration d'un seul cluster pour qu'il utilise ce nouveau commit pour valider la modification.
Branches Git Utilisez plusieurs branches Git lorsque vous souhaitez déployer la même modification dans plusieurs environnements, l'un après l'autre. N'utilisez pas plusieurs branches Git pour des différences de longue durée entre les clusters. Les branches seront très diversifiées et seront difficiles à fusionner. Commencez par fusionner la modification dans la branche de préproduction, où elle sera récupérée par les clusters de préproduction.
Fusionnez ensuite la modification dans la branche principale, où elle sera récupérée par les clusters de production.
Sélecteurs de clusters et sélecteurs d'espace de noms Utilisez des sélecteurs pour les différences de longue durée entre les clusters et les espaces de noms. N'utilisez pas de sélecteurs pour un déploiement par étapes dans plusieurs environnements. Si vous souhaitez d'abord tester une modification au cours de la préproduction, puis la déployer en production, utilisez des branches Git distinctes. Si les équipes de développement d'applications ont besoin d'un accès complet aux clusters de développement, mais à un accès en lecture seule aux clusters de production, utilisez l'objet ClusterSelector pour n'appliquer les stratégies RBAC appropriées qu'aux clusters appropriés.
Avis des pairs Utilisez des examens par des pairs pour vous assurer que les équipes concernées approuvent les modifications. Les évaluateurs manuels ne détectent pas toutes les erreurs, en particulier les éléments tels que les erreurs de syntaxe. Votre organisation exige que l'équipe responsable de la sécurité examine les modifications de configuration qui affectent plusieurs systèmes. Demandez à un membre de l'équipe de sécurité d'examiner les modifications.
Tests automatisés dans le pipeline d'intégration continue Servez-vous de tests automatisés pour détecter les erreurs dans les modifications suggérées. Les tests automatisés ne peuvent pas remplacer complètement un examinateur manuel. Utilisez les deux. L'exécution d'une commande nomos vet sur toutes les modifications suggérées permet de confirmer que le dépôt est une configuration Config Management valide.
Policy Controller Appliquez des stratégies à l'échelle de l'organisation et mettez en œuvre des garde-fous directement au niveau du serveur de l'API Kubernetes. Policy Controller ne peut pas être utilisé pour créer, mettre à jour ou supprimer des règles (il s'agit du rôle de Config Management). Policy Controller ne peut appliquer que des stratégies. L'équipe de sécurité utilise Config Management pour créer une contrainte Policy Controller afin d'empêcher les utilisateurs de créer des conteneurs privilégiés, même dans les espaces de noms directement gérés par les équipes applications.
Tester les modifications par rapport aux contraintes de Policy Controller Assurez-vous que Policy Controller ne refuse pas les modifications lorsque Config Management les applique. Le test des modifications par rapport aux contraintes de Policy Controller dans un pipeline d'intégration continue ne remplace pas l'activation de Policy Controller sur les clusters. Chaque espace de noms doit avoir un libellé "team" pour identifier son propriétaire. Un utilisateur souhaite créer un espace de noms et oublie d'ajouter ce libellé dans la suggestion de modification. Le pipeline d'intégration continue détecte l'erreur avant qu'un examen manuel ne vérifie le changement.
Surveiller les erreurs de synchronisation Assurez-vous que Config Management applique réellement les modifications à vos clusters. Les erreurs de synchronisation ne se produisent que si Config Management tente d'appliquer un dépôt non valide ou si le serveur d'API Kubernetes refuse certains objets. Si vous n'avez pas codifié toutes vos contraintes dans les stratégies de Policy Controller, les ressources qui ne les respectent pas ne seront pas détectées. Un utilisateur contourne tous vos tests et examens, puis valide une modification non valide dans le dépôt Config Management. Cette modification ne peut pas être appliquée à vos clusters. Si vous surveillez les erreurs de synchronisation, vous recevrez une alerte en cas d'erreur.

Exemple de stratégie de déploiement

Cette section utilise les concepts présentés dans la suite de cet article pour vous aider à créer une stratégie de déploiement de bout en bout sur tous les clusters de votre organisation. Dans cette stratégie, nous partons du principe que vous disposez d'un parc distinct pour le développement, la préproduction et la production (comme indiqué dans l'exemple Parc 1 : Méthode 1).

Dans ce scénario, vous configurez chaque cluster pour qu'il se synchronise avec le dépôt Git Config Management à l'aide d'un commit Git spécifique. Le déploiement d'une modification dans un parc donné est un processus en quatre étapes :

  1. Mettez à jour un cluster unique (le "Canary") dans le parc pour utiliser d'abord le nouveau commit.
  2. Vérifiez que tout fonctionne comme prévu en exécutant des tests et en surveillant le déploiement.
  3. Mettez à jour le reste des clusters du parc.
  4. Confirmez à nouveau que tout fonctionne comme prévu.

Pour déployer une modification sur l'ensemble de vos clusters, répétez cette procédure pour chaque parc. Vous pouvez appliquer cette méthode de manière technique avec n'importe quel commit Git, depuis n'importe quelle branche. Toutefois, nous vous suggérons d'adopter le processus suivant pour identifier les problèmes tôt dans le processus de vérification :

  1. Lorsqu'un utilisateur ouvre une demande de modification dans le dépôt Git de Config Management, déployez cette modification dans l'un des clusters de développement.
  2. Si la demande de modification est acceptée et fusionnée dans votre branche principale, exécutez le déploiement complet sur tous les parcs comme décrit précédemment.

Bien que certaines modifications puissent ne cibler qu'un parc spécifique, nous vous recommandons de déployer toutes les modifications dans tous les parcs à terme. Cette stratégie élimine le problème de suivi du parc à synchroniser avec le commit dédié. Portez une attention particulière aux modifications qui ciblent uniquement le parc de production, car des tests appropriés n'auraient pas été possibles dans les parcs précédents. Par exemple, cela signifie que vous devez attendre plus longtemps pour que les problèmes surviennent entre le déploiement sur les clusters Canary et le reste des clusters.

Pour résumer, un déploiement de bout en bout ressemble à ceci :

  1. Quelqu'un ouvre une demande de modification.
  2. Des tests et des validations automatisés sont exécutés, et une vérification manuelle est réalisée.
  3. Vous déclenchez une tâche manuellement pour déployer la modification sur le cluster Canary dans le parc de développement. Des tests automatisés de bout en bout s'exécutent dans ce cluster.
  4. Si tout fonctionne correctement, fusionnez la demande de modification sur la branche principale.
  5. La fusion déclenche une tâche automatisée pour déployer le nouveau commit de conseil d'application de la branche principale dans le cluster Canary du parc de développement. Des tests automatisés de bout en bout sont exécutés dans ce cluster (pour détecter les incompatibilités potentielles entre deux demandes de modification qui ont été créées et fusionnées approximativement à la même heure).
  6. Les tâches suivantes sont exécutées l'une après l'autre (vous les déclenchez manuellement ou après une heure prédéfinie pour permettre la création de rapports utilisateur sur des régressions) :
    1. Déployez sur tous les clusters du parc de développement.
    2. Exécutez des tests et des validations sur les clusters du parc de développement.
    3. Déployez sur le cluster Canary du parc de préproduction.
    4. Exécutez des tests et des validations sur le cluster Canary du parc de préproduction.
    5. Déployez sur tous les clusters du parc de préproduction.
    6. Exécutez des tests et des validations sur les clusters du parc de préproduction.
    7. Déployez sur le cluster Canary du parc de production.
    8. Exécutez des tests et des validations sur le cluster Canary du parc de production.
    9. Déployez sur tous les clusters du parc de production.
    10. Exécutez des tests et des validations sur les clusters du parc de production.

Processus de déploiement complet.

Étapes suivantes