Bonnes pratiques pour la gestion des stratégies avec Anthos Config Management et GitLab

Ce document explique comment gérer plusieurs clusters Kubernetes dans un environnement de production à l'aide d'Anthos Config Management et de GitLab. La sécurisation du dépôt Anthos Config Management constitue une étape importante du déploiement. Ce document peut vous être utile dans ce processus, Ce document est utile si vous êtes en train de déployer Anthos Config Management pour une utilisation en production. Il part du principe que vous maîtrisez Kubernetes, Git et GitLab.

Si vous exploitez une plate-forme qui héberge des applications pour votre organisation, il est important de mettre en place des stratégies pour vous permettre de protéger cette plate-forme. Ces stratégies sont des règles visant à protéger la plate-forme ainsi que les applications et les données qu'elle contient. La plate-forme les applique en fonction des configurations qui les décrivent. L'application des stratégies contribue à améliorer la sécurité et la stabilité de la plate-forme.

Anthos Config Management vous permet de gérer des stratégies à grande échelle pour les plates-formes basées sur des distributions Google Kubernetes Engine (GKE), des clusters Anthos GKE, ou sur d'autres distributions Kubernetes. Anthos Config Management vous permet de créer et de gérer des objets Kubernetes sur plusieurs clusters à la fois. Vous pouvez gérer n'importe quel objet Kubernetes avec Anthos Config Management, mais il est particulièrement utile d'appliquer des stratégies, par exemple :

PodSecurityPolicies : empêche les pods d'utiliser l'utilisateur Linux racine.
NetworkPolicies : contrôle le trafic réseau dans vos clusters.
ClusterRoles et ClusterRoleBindings : contrôlent les autorisations au sein d'un cluster.

Comme le montre le schéma suivant, Anthos Config Management est un outil de type GitOps. Il utilise un dépôt Git comme mécanisme de stockage et source fiable.

Architecture de la configuration Kubernetes dans Git

Anthos Config Management vous permet de déployer et de gérer des objets Kubernetes en interagissant avec ce dépôt Git. Obtenir un accès en écriture à la branche principale du dépôt Git d'Anthos Config Management signifie être un administrateur des clusters gérés par Anthos Config Management. Le dépôt Anthos Config Management contient des informations utiles pour un pirate potentiel. Il est donc important de le sécuriser.

Ce document utilise GitLab Source Code Management (SCM) comme service d'hébergement de dépôt Git et présente les bonnes pratiques pour gérer plusieurs clusters Kubernetes à l'aide d'Anthos Config Management et de GitLab.

Anthos Config Management et architecture GitLab

Le schéma suivant illustre l'architecture de déploiement d'Anthos Config Management avec GitLab permettant de gérer trois clusters Kubernetes : un sur GKE, un sur des clusters Anthos sur VMware et le dernier sur l'infrastructure d'un autre fournisseur cloud.

Architecture de déploiement d'Anthos Config Management avec GitLab

Le schéma précédent illustre les étapes suivantes du pipeline :

Pour apporter une modification à la configuration d'un cluster ou de l'ensemble de ces clusters, un utilisateur soumet une modification, appelée demande de fusion (MR, Merge Request), qui doit être validée dans GitLab.
La MR déclenche un pipeline automatisé de GitLab CI/CD, le système de livraison et d'intégration continues incorporé dans GitLab, pour tester et valider la configuration.
La MR est approuvée ou refusée par un administrateur. Une fois approuvée, la modification est fusionnée avec le dépôt Git.
Après approbation, les agents Anthos Config Management exécutés dans chaque cluster lisent cette modification à partir de GitLab et l'appliquent à leur cluster.

Bonnes pratiques d'hébergement de GitLab dans le cadre d'Anthos Config Management

Dans cette section, nous vous recommandons les bonnes pratiques à suivre lorsque vous hébergez et gérez des dépôts Anthos Config Management à l'aide de GitLab SCM. Les bonnes pratiques générales liées à l'hébergement de GitLab, telles que la configuration d'une architecture à disponibilité élevée et des sauvegardes régulières, s'appliquent également, mais elles ne sont pas abordées dans ce document.

Restreindre l'accès administrateur

Toute personne disposant d'un accès racine à la machine virtuelle (ou au cluster Kubernetes) hébergeant GitLab peut contourner les fonctionnalités de sécurité de GitLab et doit donc être considérée comme un administrateur pour Anthos Config Management. Cette hypothèse s'applique également à tous les administrateurs de GitLab et à toute personne disposant d'un accès en écriture à la base de données GitLab. Si vous accordez à un utilisateur des droits d'administrateur GitLab, l'accès racine à la machine virtuelle (ou au cluster Kubernetes) hébergeant GitLab ou l'accès à la base de données GitLab, celui-ci peut également apporter des modifications à Anthos Config Management. Pour en savoir plus, consultez la documentation concernant les autorisations de GitLab.

Si vous utilisez Compute Engine, contrôlez l'accès à l'instance à l'aide d'Identity and Access Management (IAM) et du service OS Login. En particulier, le rôle de connexion administrateur au système d'exploitation Compute accorde un accès racine à l'instance.

Si vous utilisez GKE, utilisez IAM et RBAC pour contrôler qui peut accéder au cluster.

Être attentif aux mises à jour

GitLab propose une release par mois et publie plusieurs releases de correctifs entre chaque. Comme n'importe quel logiciel, GitLab fournit des correctifs de sécurité dans certaines de ces releases. Pour cette raison, vous devez maintenir votre instance GitLab à jour autant que possible. Pour en savoir plus, consultez la page sur la mise à jour de GitLab.

Suivre les bonnes pratiques spécifiques à Google Cloud pour l'hébergement de GitLab sur Google Cloud

Si vous hébergez GitLab sur Google Cloud, il est recommandé de lui dédier un projet cloud. Ce projet cloud doit être placé directement sous votre nœud d'organisation, et non dans un dossier. Ces recommandations peuvent réduire le risque de survenue des erreurs de configuration IAM suivantes :

Si GitLab partage un projet cloud avec d'autres applications, vous risquez d'accorder un accès administrateur à GitLab par inadvertance lorsque vous accordez l'accès aux autres applications.
Si vous placez ce projet cloud dans un dossier, vous risquez d'y accorder l'accès par inadvertance en accordant l'accès au dossier.

Si vous déployez GitLab sur Google Cloud, nous vous recommandons également d'exploiter les services gérés suivants :

Hébergez la base de données de GitLab à l'aide de Cloud SQL pour PostgreSQL. Cloud SQL prend alors en charge la haute disponibilité et les sauvegardes à votre place.
Utilisez Memorystore pour Redis comme serveur GitLab Redis. Memorystore se charge alors de la haute disponibilité à votre place.
Stockez des sauvegardes, des artefacts de compilation et des importations utilisateur à l'aide de Cloud Storage.

Authentification et contrôle des accès pour GitLab

À des fins d'audit ou de débogage, il est important de pouvoir identifier les utilisateurs qui ont modifié des stratégies. Le personnel informatique doit également utiliser ces identités pour gérer diverses ressources.

Utiliser des identités unifiées

Anthos Config Management est conçu pour que vous interagissiez avec lui via un dépôt Git dans lequel vous pouvez créer, mettre à jour et supprimer des ressources. Le dépôt Git vous permet de contrôler les autorisations des utilisateurs et d'effectuer des audits de toutes les activités. La mise en œuvre du contrôle des accès et de l'audit est facilitée si les identités utilisées par vos employés sont les mêmes partout : sur Google Cloud, dans GitLab et dans vos systèmes sur site. Les identités unifiées vous permettent de mettre en place des références croisées pour les autorisations et les journaux d'audit dans différents systèmes.

Dans GitLab, vous pouvez effectuer des audits des événements sur l'ensemble des groupes, des projets et des instances, et interroger les journaux système pour les événements de niveau de service GitLab. Les fonctionnalités d'audit des événements GitLab couvrent les niveaux sous licence d'entreprise.

Si vous n'utilisez pas Google en tant que fournisseur d'identité

Vous pouvez fédérer Google Cloud avec de nombreux IdP courants tels qu'Active Directory, Azure Active Directory ou Okta. Vous pouvez configurer GitLab de sorte qu'il utilise Active Directory ou Okta.

Si vous utilisez Google en tant que fournisseur d'identité

Si vous utilisez Google en tant que fournisseur d'identité, vous pouvez utiliser le fournisseur OmniAuth Google OAuth 2.0 ou le protocole LDAP sécurisé. Toutefois, si vous souhaitez synchroniser des groupes avec GitLab, comme nous vous le recommandons dans la section suivante, vous devez utiliser le protocole LDAP sécurisé. Le protocole LDAP sécurisé est disponible avec Cloud Identity Premium et Google Workspace Enterprise. Pour en savoir plus, consultez la page À propos du service LDAP sécurisé.

Synchroniser des groupes avec GitLab

Quelle que soit la technologie utilisée pour identifier les utilisateurs, il est utile de les regrouper pour configurer leur accès. Les groupes vous permettent de considérer ces utilisateurs d'une manière plus globale lorsque vous accordez des autorisations : "J'accorde l'accès administrateur pour les environnements de production à mon groupe chargé des opérations" plutôt que "J'accorde l'accès administrateur pour les environnements de production à Alice, Bob, Claudia et Dinesh". Si vos processus de ressources humaines sont bien intégrés à vos systèmes informatiques, l'appartenance à un groupe est gérée automatiquement lorsqu'un employé est embauché, quitte l'entreprise ou change de rôle. Si vous utilisez des groupes, cette intégration signifie que vous n'avez généralement pas besoin de mettre à jour vos paramètres de contrôle des accès.

Étant donné qu'Anthos Config Management est un système sensible, il est important de s'appuyer sur des groupes d'utilisateurs pour contrôler l'accès à celui-ci. Dans GitLab, vous pouvez partager un projet avec un groupe d'utilisateurs et spécifier le niveau d'accès accordé à ses membres.

Appliquer l'authentification à deux facteurs

Vous devez utiliser l'authentification à deux facteurs (2FA), également appelée validation en deux étapes, pour améliorer la sécurité de votre organisation. Les identifiants volés et les tentatives d'hameçonnage constituent deux vecteurs d'attaque courants, et la méthode 2FA permet de s'en prémunir. En raison de la nature sensible du dépôt Git d'Anthos Config Management, les comptes des utilisateurs interagissant avec Anthos Config Management doivent être protégés autant que possible, ce qui implique d'activer la méthode 2FA pour ces utilisateurs.

Si vous configurez l'authentification unique (SSO, Single Sign-On) pour GitLab, vous devez appliquer la méthode 2FA avec votre fournisseur SSO. Si vous utilisez Google comme fournisseur SSO, vous pouvez activer la méthode 2FA.

Si vous n'avez pas configuré l'authentification unique pour GitLab, vous pouvez appliquer la méthode 2FA sur GitLab directement.

Utiliser des clés ou des jetons de déploiement pour connecter des agents Anthos Config Management à GitLab

Comme décrit sur la page Installer Anthos Config Management, vous pouvez connecter les agents Anthos Config Management au dépôt à l'aide des méthodes habituelles pour Git : HTTP(s) ou SSH. Si vous utilisez HTTP(s) pour accéder aux dépôts hébergés sur GitLab, n'utilisez pas de compte utilisateur. En effet, cela peut entraîner des problèmes, par exemple concernant l'attribution de licences et la configuration d'Anthos Config Management par les utilisateurs avec leurs propres comptes. Les clés de déploiement et les jetons de déploiement de GitLab constituent une meilleure alternative. Une clé de déploiement est une clé SSH qui n'est associée à aucun utilisateur particulier, mais dont les systèmes automatisés peuvent se servir pour effectuer des opérations Git, ce qui est le type d'accès sécurisé dont Anthos Config Management a besoin. Un jeton de déploiement a la même utilisation qu'une clé de déploiement, mais vous pouvez l'utiliser pour vous authentifier via HTTP(s) au lieu de SSH.

Les clés et les jetons de déploiement uniques vous permettent de contrôler et de révoquer l'accès des agents Anthos Config Management au dépôt Git par cluster. Évitez d'utiliser des clés de déploiement globales <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="opBB/mAJqPUFZffWWDKJfMvOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwlKMkBQSfMxp5fl+Mc9AjFx4o6T+DhcfK0B6wN+3j0FU=" track-metadata-position="body" track-name="externalLink" track-type="solution"> pour Anthos Config Management et des jetons de déploiement de groupe <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="EVE38A1n4riTbiBLnLIE18vOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwnjars0LTR/vDhAa2T615gjvG0B0C/P1DzOlB98jatvw=" track-metadata-position="body" track-name="externalLink" track-type="solution">. Vous pouvez les utiliser à d'autres fins que pour Anthos Config Management, ce qui entraîne des effets secondaires inattendus si leur configuration est modifiée.</atarget="external"></atarget="external">

Gérer les autorisations d'approbation de demandes de fusion

Par défaut, GitLab utilise des rôles pour accorder des autorisations sur les projets GitLab. Par exemple, un utilisateur doté du rôle de développeur peut ouvrir une demande de fusion, et un utilisateur doté du rôle de responsable peut approuver la demande. Au départ, ce système d'autorisation peut bien fonctionner pour Anthos Config Management, mais vous risquez de rencontrer des problèmes au fil de l'évolution de votre utilisation de Kubernetes et d'Anthos Config Management. Les responsables du dépôt Anthos Config Management risquent d'être dépassés par le nombre de demandes de fusion qu'ils doivent traiter et approuver.

Vous pouvez exploiter les fonctionnalités avancées de GitLab pour résoudre ce problème :

Vous pouvez faire appel à des propriétaires de code pour déléguer des autorisations d'approbation au niveau d'un fichier ou d'un répertoire. Cette fonctionnalité est utile, car Anthos Config Management utilise une structure de répertoires pour décrire les clusters et les espaces de noms. En utilisant les propriétaires de code, vous pouvez déléguer des autorisations d'approbation sur un espace de noms spécifique pour tous vos clusters, par exemple.
Vous pouvez utiliser les approbations de demandes de fusion pour demander à des utilisateurs appartenant à différentes équipes d'approuver une demande avant sa fusion. Par exemple, vous pouvez demander à deux approbateurs, un membre de l'équipe chargé des opérations et un membre de l'équipe chargée de la sécurité, d'approuver une demande de fusion.

Le schéma suivant illustre la division technique d'une organisation et montre comment la délégation des approbations peut fonctionner dans un environnement de production.

Exemple d'architecture de la hiérarchie d'une organisation

Le schéma précédent présente un directeur de la technologie (CTO, Chief Technical Officer) ainsi que les différentes équipes qu'il dirige : une équipe chargée de la sécurité, une équipe chargée des plates-formes et plusieurs équipes dédiées aux applications.

Le dépôt Git d'Anthos Config Management pour cette organisation présente la structure suivante. Seuls les répertoires sont affichés, sans les fichiers :

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

Pour en savoir plus sur chaque répertoire, consultez la page Utiliser le dépôt Anthos Config Management.

Grâce à cette structure, l'organisation peut utiliser les fonctionnalités GitLab précédemment mentionnées pour mettre en œuvre le processus suivant :

Toute modification apportée à la racine du dépôt ou au répertoire system doit être approuvée par le CTO.
Toute modification apportée au répertoire clusterregistry doit être approuvée par un membre de l'équipe chargée des plates-formes.
Toute modification apportée au répertoire cluster doit être approuvée par un membre de l'équipe chargée des plates-formes et par un membre de l'équipe chargée de la sécurité.
Toute modification apportée au répertoire namespaces doit être approuvée par un membre de l'équipe chargée des plates-formes.
Toute modification apportée aux sous-répertoires du répertoire namespaces doit être approuvée par les équipes suivantes :
- Le sous-répertoire cicd représente un espace de noms dédié aux outils d'intégration et de livraison continues (CI/CD). Toute modification doit être approuvée par un membre de l'équipe chargée des plates-formes.
- Le sous-répertoire audit représente un espace de noms dédié aux outils d'audit. Toute modification doit être approuvée par un membre de l'équipe chargée de la sécurité.
- Le sous-répertoire applications contient toutes les ressources créées pour chaque espace de noms d'application. Toute modification doit être approuvée par un membre de l'équipe chargée des plates-formes et par un membre de l'équipe chargée de la sécurité.
- Les sous-répertoires team-a et team-b représentent les espaces de noms dédiés à l'équipe A et à l'équipe B. Toute modification doit être approuvée par le responsable de cette équipe.

La mise en œuvre de ce processus est plus simple si les groupes de votre fournisseur d'identité sont synchronisés avec GitLab. Vous pouvez demander plusieurs approbations de différents groupes pour une demande de fusion. Pour en savoir plus, consultez les sections Synchroniser des groupes avec GitLab et Modifier des approbations.

Désactiver les exécuteurs partagés

Vous pouvez utiliser GitLab CI pour tester automatiquement vos stratégies Anthos Config Management avant de les déployer. GitLab CI utilise des exécuteurs pour exécuter les tâches de votre choix. Ces exécuteurs peuvent être partagés avec la totalité de l'instance GitLab, auquel cas ils sont gérés par la même équipe que celle de cette instance, ou dédiés à des groupes GitLab ou à des projets GitLab.

En raison de la nature sensible du dépôt Anthos Config Management, vous devez éviter d'utiliser des exécuteurs partagés pour tester le code Anthos Config Management. Utilisez plutôt des exécuteurs dédiés aux projets Anthos Config Management et gérés par les utilisateurs autorisés à approuver les demandes de fusion.

Récapitulatif des recommandations

Cette section récapitule les recommandations mentionnées dans les sections précédentes. Si vous utilisez GitLab pour héberger le dépôt Git d'Anthos Config Management, nous vous recommandons de procéder comme suit :

Déterminez les utilisateurs qui disposent d'un accès administrateur à GitLab, car ils bénéficient également d'un accès administrateur à Anthos Config Management.
Mettez à jour GitLab régulièrement et à chaque nouvelle publication d'un correctif de sécurité.
Dédiez un projet cloud à GitLab sous votre nœud d'organisation si vous hébergez GitLab sur Google Cloud.
Configurez tous vos systèmes, y compris GitLab, de sorte qu'ils utilisent le même fournisseur d'identité.
Si possible, synchronisez vos groupes d'utilisateurs existants avec GitLab à l'aide de la fonctionnalité Synchronisation de groupe LDAP, une fonctionnalité sous licence de GitLab Enterprise.
Appliquez l'authentification à deux facteurs pour les utilisateurs qui interagissent avec Anthos Config Management afin de renforcer la protection contre les problèmes liés aux identifiants volés et obtenus par hameçonnage.
Lorsque vous configurez des agents Anthos Config Management, procédez comme suit :
- Configurez les agents Anthos Config Management de sorte qu'ils utilisent SSH et des clés de déploiement, ou HTTPS et des jetons de déploiement, pour se connecter à GitLab.
- Évitez d'utiliser le protocole HTTP non chiffré.
- Créez une clé ou un jeton de déploiement unique pour chaque cluster Kubernetes de votre dépôt Anthos Config Management.
- Configurez les clés et les jetons de déploiement directement dans le dépôt Anthos Config Management, et évitez d'utiliser des clés de déploiement globales et des jetons de déploiement de groupe pour Anthos Config Management.
Faites attention aux retards d'approbation des demandes de fusion dans le dépôt Anthos Config Management. Si vous constatez une augmentation déraisonnable de ces retards, utilisez des propriétaires de code ou les approbations de demande de fusion avancées pour déléguer les autorisations d'approbation à d'autres utilisateurs de votre organisation.
Désactivez les exécuteurs partagés pour votre projet Anthos Config Management et n'utilisez que des exécuteurs dédiés à ce projet.

Étapes suivantes

Découvrez Anthos Policy Controller.
Découvrez comment valider des applications par rapport aux règles de l'entreprise dans un pipeline CI.