Plan de sécurité Anthos : appliquer des règles

Ce document explique comment appliquer des règles de sécurité aux clusters Anthos. Vous y découvrirez comment et pourquoi appliquer des règles, ainsi que les contrôles Google Cloud à utiliser pour cette tâche.

Ce document fait partie d'une série de plans de sécurité réunissant des conseils normatifs pour travailler avec Anthos. Pour plus d'informations sur ces plans, consultez la section Plans de sécurité Anthos : questions fréquentes.

Présentation

Vous appliquez des règles à vos clusters afin de garantir le respect de vos garde-fous de sécurité et de vos exigences en termes de conformité. Après avoir spécifié des règles, vous devez vous assurer qu'elles sont appliquées et que les paramètres de vos clusters Anthos respectent leurs configurations.

L'application des règles est une mesure complémentaire à l'audit de votre cluster. L'audit vous permet de connaître le dernier état de votre cluster ainsi que son état actuel, mais n'empêche aucune action susceptible de contourner vos règles. En revanche, l'application des règles est une mesure préventive. Nous vous recommandons d'appliquer des règles au niveau du cluster et de l'espace de noms qui répondent à vos exigences.

Vous devez déterminer comment répondre aux exigences suivantes :

  • Limiter la consommation de ressources
  • Restreindre le trafic réseau au sein du cluster
  • Restreindre les capacités nécessaires à l'exécution d'un pod
  • Définir des règles personnalisées telles que l'application de libellés obligatoires

Comprendre les contrôles de sécurité nécessaires

Cette section décrit les contrôles nécessaires à l'application de règles qui vous permettent de répondre à vos exigences en termes de sécurité et de conformité.

Espaces de noms

Attribuer des libellés à des ressources qui doivent utiliser les mêmes règles

Les espaces de noms vous permettent de définir un champ d'application pour les ressources associées au sein d'un cluster, telles que les pods, les services et les contrôleurs de réplication. Ils vous permettent également de déléguer la responsabilité de l'administration des ressources associées en tant qu'unité. Par conséquent, les espaces de noms font partie intégrante de la plupart des modèles de sécurité.

Les espaces de noms constituent une fonctionnalité importante de l'isolation du plan de contrôle. Cependant, ils ne permettent pas l'isolation des nœuds, des plans de données ou des réseaux.

Une approche courante consiste à créer des espaces de noms pour des applications individuelles. Par exemple, vous pouvez créer l'espace de noms myapp-frontend pour le composant de l'interface utilisateur d'une application.

Quotas de ressources

Contrôler la consommation de ressources

GKE est conçu pour accepter l'exécution de plusieurs applications dans le même cluster et leur gestion par plusieurs équipes. Si aucune équipe n'est chargée de gérer l'utilisation des ressources dans un cluster, il se peut que les applications qui y sont exécutées consomment plus de ressources que nécessaire. Pour éviter que cela ne se produise, un administrateur doit configurer des quotas de ressources afin de limiter la consommation totale des ressources définies dans un espace de noms.

Anthos Config Management

Appliquer des configurations à vos clusters Anthos

Une bonne pratique de gestion des clusters Anthos consiste à utiliser Anthos Config Management, qui synchronise les clusters enregistrés avec les configurations. Une configuration est un fichier YAML ou JSON stocké dans votre dépôt et contenant les mêmes types de détails de configuration que vous pouvez appliquer manuellement à un cluster à l'aide de la commande kubectl apply. Anthos Config Management vous permet de gérer vos règles et vos déploiements d'infrastructure de la même manière qu'avec vos applications : en adoptant une approche de type "policy as code" (règles en tant que code).

Vous utilisez Anthos Config Management conjointement avec un dépôt Git qui sert de source unique de vérité pour vos règles déclarées. Anthos Config Management peut gérer des règles de contrôle d'accès, telles que les règles RBAC, les quotas de ressources, les espaces de noms et les déploiements d'infrastructure au niveau de la plate-forme. Anthos Config Management est déclaratif. Il vérifie en permanence l'état du cluster et applique l'état déclaré dans la configuration afin d'appliquer les règles.

Règles de réseau

Appliquer le flux de trafic réseau dans les clusters

Les règles de réseau appliquent les flux de trafic réseau de couche 4 en se basant sur les règles de pare-feu au niveau du pod. Les règles de réseau sont appliquées à un espace de noms.

Par défaut, l'activation d'une règle de réseau pour un espace de noms ne restreint pas l'accès aux pods d'un cluster. L'application est activée lorsqu'au moins un objet NetworkPolicy sélectionne un pod.

L'adoption du principe du moindre privilège constitue une bonne pratique. Lorsque vous mettez en œuvre des règles de réseau, nous vous recommandons de créer une règle par défaut de type "Tout refuser" dans l'espace de noms, qui s'applique à tous les pods. Cela permet à l'espace de noms de bloquer les accès (autrement dit, d'agir en tant que système de fermeture après défaillance). Pour autoriser les flux de trafic réseau, vous devez vous assurer de configurer explicitement des règles de réseau pour chaque espace de noms.

Le schéma suivant montre comment gérer le flux de trafic entre les espaces de noms en configurant des règles de réseau pour chaque espace de noms.

Gestion du flux de trafic entre les espaces de noms à l'aide de règles de réseau

Dans cet exemple, le trafic est autorisé à circuler de manière bidirectionnelle entre les transactions d'espace de noms et le préfixe d'espace de noms. Toutefois, seul le trafic du préfixe d'espace de noms vers l'application de journalisation est autorisé.

Pour obtenir un exemple de configuration NetworkPolicy pouvant être appliquée à l'aide d'Anthos Config Management, consultez la section "Configuration de l'objet NetworkPolicy" de la page Configurer des objets Kubernetes.

Anthos Policy Controller

Faire respecter les règles

Anthos Policy Controller est un contrôleur d'admission dynamique pour Kubernetes qui applique des règles basées sur l'objet CustomResourceDefinition (CRD), qui sont exécutées par le service OPA (Open Policy Agent).

Les contrôleurs d'admission sont des plug-ins Kubernetes qui interceptent les requêtes adressées au serveur d'API Kubernetes avant la persistance d'un objet, mais après l'authentification et l'autorisation de la requête. Les contrôleurs d'admission peuvent vous servir à limiter l'utilisation d'un cluster.

Pour utiliser Policy Controller, vous déclarez un ensemble de contraintes dans un modèle de contrainte. Une fois le modèle de contrainte déployé dans le cluster, vous pouvez créer des objets CRD de contrainte individuels, qui sont définis par le modèle de contrainte.

Le schéma suivant montre comment Policy Controller utilise le service OPA Contraint Framework pour définir et appliquer des règles.

Le service OPA Contraint Framework reçoit des requêtes et applique des règles d'accès à d'autres ressources.

Le schéma montre les éléments suivants :

  1. Les contraintes sont créées à partir de modèles de contraintes.
  2. Les règles sont activées sur le cluster en appliquant des contraintes.
  3. Une requête est transmise et un examen d'admission est déclenché, ce qui entraîne une décision d'autorisation ou de refus.
  4. Un audit continu évalue tous les objets actifs du cluster par rapport aux règles.

À l'aide de Policy Controller, vous pouvez appliquer des règles personnalisées, telles que l'application de libellés. Policy Controller vous permet de mettre en œuvre la majorité des contraintes applicables à l'aide de PodSecurityPolicies. Toutefois, elles nécessitent généralement moins de coûts opérationnels pour les raisons suivantes :

  • Policy Controller comprend une bibliothèque de modèles par défaut qui inclut des modèles de contrainte. Ainsi, vous n'avez pas besoin d'écrire vos propres règles pour les cas courants, comme c'est le cas lorsque vous utilisez PodSecurityPolicies.
  • Vous n'avez pas besoin de gérer les objets RoleBindings comme c'est le cas lorsque vous utilisez PodSecurityPolicies.
  • Policy Controller est compatible avec le mode de simulation, ce qui vous permet de valider l'effet d'une contrainte avant de l'appliquer.
  • Vous pouvez définir des règles sur les espaces de noms, ce qui vous permet d'augmenter les règles plus restrictives de manière plus progressive. Cette approche est semblable à une stratégie de version Canary, dans laquelle vous gérez l'exposition des règles de déploiement susceptibles d'avoir des effets inattendus. Par exemple, votre déploiement peut révéler que vous avez restreint l'accès à un volume depuis un pod, alors même que celui-ci doit avoir accès au volume.
  • Policy Controller offre un moyen unique d'appliquer des règles, qu'il s'agisse de contraintes personnalisées ou de contraintes PodSecurityPolicies définies dans le dépôt Gatekeeper.

Pour en savoir plus sur l'utilisation de Policy Controller pour l'application des règles que vous définissez, consultez la page Contrôleur de stratégie Anthos Config Management.

Anthos Service Mesh

Gérer les communications sécurisées entre les services

Anthos Service Mesh vous permet de surveiller et de gérer un maillage de services basé sur Istio. Un maillage de services est une couche d'infrastructure qui permet une communication gérée, observable et sécurisée sur vos services.

Anthos Service Mesh simplifie la gestion des communications sécurisées entre les services de différentes manières :

  • Il gère l'authentification et le chiffrement du trafic (protocoles compatibles au sein du cluster à l'aide de la communication mutuelle par couche de transport (mTLS)). Anthos Service Mesh gère le provisionnement et la rotation des clés et des certificats mTLS pour les charges de travail Anthos sans perturber les communications. La rotation régulière des clés mTLS est une bonne pratique de sécurité qui permet de réduire l'exposition en cas d'attaque.
  • Il vous permet de configurer des règles de sécurité réseau basées sur l'identité du service plutôt que sur l'adresse IP du pair. Anthos Service Mesh sert à configurer des règles de contrôle d'accès (pare-feu) basées sur l'identité, qui vous permettent de créer des règles indépendantes de l'emplacement réseau de la charge de travail. Cela simplifie le processus de configuration des communications de service à service.
  • Il vous permet de configurer des règles autorisant l'accès à partir de certains clients.
  • Il gère l'authentification des utilisateurs à l'aide d'Identity-Aware Proxy ou d'un moteur de règles personnalisé. Cela vous permet de contrôler l'accès aux applications déployées sur les clusters Anthos GKE en vérifiant l'identité de l'utilisateur et le contexte de la requête afin de déterminer si un utilisateur doit être autorisé à y accéder.

En plus de gérer les communications sécurisées entre les services, Anthos Service Mesh n'enregistre qu'une seule fois les accès réussis pour chaque fenêtre temporelle configurable, ce qui permet de réduire le bruit dans les journaux d'accès. Les requêtes refusées par une règle de sécurité ou qui génèrent une erreur sont toujours consignées. Les journaux et les métriques d'accès sont disponibles dans la suite d'opérations de Google Cloud.

Pour en savoir plus sur les fonctionnalités de sécurité d'Anthos Service Mesh, consultez la présentation de la sécurité d'Anthos Service Mesh.

Conclusion

Les contrôles décrits précédemment s'appliquent à Anthos GKE et à Anthos GKE On-Prem.

Pour intégrer ces contrôles, définissez les champs d'application décrits dans ce guide et l'étape à laquelle ils doivent être configurés, comme indiqué dans les étapes suivantes.

  1. Créez vos clusters en suivant les instructions du guide de durcissement de cluster applicable (GKE ou Anthos GKE On-Prem). Lorsque vous créez votre cluster, assurez-vous de suivre le guide de durcissement et d'utiliser l'option --enable-network-policy. Les règles de réseau sont obligatoires. Cette étape vous permet de mettre en œuvre ultérieurement des règles de pare-feu qui limitent le trafic qui circule entre les pods d'un cluster.
  2. Définissez les espaces de noms et les libellés requis pour les pods. Cela permet d'obtenir un champ d'application de nom qui vous autorise à utiliser des règles et des comptes de service Kubernetes.
  3. Installez Policy Controller à l'aide d'Anthos Config Management.
  4. Appliquez votre règle de réseau à l'aide d'Anthos Config Management.
  5. Collectez les modèles de contrainte prédéfinis de Policy Controller que vous souhaitez utiliser et mappez-les à vos ressources en définissant des contraintes.
  6. Appliquez le modèle de contrainte et les contraintes à l'aide d'Anthos Config Management.

Vous pouvez renforcer l'application des règles à l'aide d'Anthos Service Mesh en mettant en œuvre des contrôles supplémentaires qui se concentrent au niveau de la couche d'application (couche 7). Pour ce faire, procédez comme suit :

  • Si vous n'avez pas activé l'application des règles Istio lors de la création de votre cluster, activez-la maintenant.
  • Définissez les règles que vous souhaitez appliquer au niveau de la couche d'application. Les règles sont exprimées au format YAML.
  • Appliquez vos règles à l'aide d'Anthos Config Management.