Plan de sécurité Anthos : auditer et surveiller les écarts par rapport aux règles

Ce document explique comment auditer et surveiller vos clusters Anthos afin de déterminer s'il existe un écart par rapport aux bonnes pratiques et aux règles de sécurité que vous leur avez associées. Il décrit comment et pourquoi auditer et surveiller les règles, ainsi que les contrôles Google Cloud à utiliser.

Ce document fait partie d'une série de plans réunissant des conseils normatifs pour travailler avec Anthos.

Présentation

Votre cluster dispose de règles qui aident à protéger l'accès à vos ressources. Vous pouvez renforcer la sécurité en auditant et en surveillant les écarts par rapport à ces règles. L'audit et la surveillance vous fournissent des insights sur l'état actuel de votre cluster, mais n'empêchent aucune action susceptible de contourner vos règles. Pour éviter les modifications, vous devez également prendre des mesures pour l'application des règles.

Même si la surveillance et l'audit se ressemblent, leur objectif diffère légèrement. Une solution de surveillance classique consiste à collecter des métriques et des tableaux de bord permettant d'afficher l'état de vos systèmes et applications. Elle doit également servir à envoyer des alertes en cas d'anomalies. En revanche, l'audit permet de valider l'état de vos systèmes, généralement par rapport à un ensemble de règles que vous avez définies.

Pour l'audit et la surveillance, vous devez tenir compte des exigences suivantes :

  • Quelles sont les commandes d'application que vous avez mises en place et comment les auditer ou les surveiller en cas d'écarts par rapport aux règles.
  • Si vous avez besoin d'une solution de surveillance consolidée ou d'une solution de surveillance distincte.

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

Cette section décrit les contrôles requis pour effectuer les opérations suivantes :

  • Mettre en œuvre un audit qui complète l'application des règles, comme décrit dans le guide associé.

  • Mettre en œuvre une solution de surveillance compatible avec les clusters Anthos GKE, quel que soit l'environnement dans lequel ils sont déployés.

Espaces de noms

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

Les espaces de noms vous permettent de fournir 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.

Anthos Config Management

Appliquer des configurations à vos clusters Anthos

Une bonne pratique lors de la 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.

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 d'appliquer 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 consacrée à Policy Controller dans Anthos Config Management.

Kubernetes Engine Operations

Surveiller des clusters GKE

Kubernetes Engine Operations est conçu pour surveiller les clusters GKE. Il gère les services Cloud Monitoring et Cloud Logging et présente un tableau de bord Kubernetes Engine Operations personnalisé pour les clusters GKE. Kubernetes Engine Operations dispose d'un ensemble de ressources surveillées GKE qui représentent des ressources telles que des clusters, des nœuds, des pods et des conteneurs. Bien que vous puissiez désactiver Kubernetes Engine Operations pour GKE et pour les clusters GKE On-Prem, nous vous recommandons de l'activer pour ces produits.

Analyse de l'état de la sécurité

Identifier les failles

Security Health Analytics vous aide à éviter les incidents en identifiant les éventuelles erreurs de configuration et les cas de non-conformité dans vos ressources Google Cloud. Des mesures correctives appropriées sont également suggérées. Les analyses Security Health Analytics génèrent des types de résultat de faille, qui sont disponibles dans Security Command Center. Les résultats de l'analyse de conteneurs concernent les configurations de conteneurs GKE et appartiennent au type d'analyse CONTAINER_SCANNER.

Intégration de Pub/Sub avec Security Command Center

Vous pouvez recevoir des alertes concernant les résultats de Security Command Center avec l'application de notification. L'application s'abonne à un sujet Pub/Sub de notification et envoie des notifications à une chaîne configurée, comme e-mail ou SMS.

Cloud Asset Inventory

Surveiller les ressources Google Cloud

L'inventaire des éléments cloud vous permet de surveiller les modifications des ressources et des règles auxquelles vous êtes abonné via des notifications en temps réel. Vous pouvez surveiller les modifications des types de ressources et des types de règles compatibles au sein d'une organisation, d'un dossier ou d'un projet, ou d'autres ressources que vous spécifiez. Pour configurer des abonnements, vous devez créer un flux. Les types de ressources compatibles incluent les types de ressources GKE et les types de stratégies Cloud IAM.

Vous pouvez surveiller les ressources sensibles du point de vue de la sécurité, telles que les règles de pare-feu et les modifications apportées aux stratégies IAM. Toute modification apportée à ces ressources envoie immédiatement une notification via Pub/Sub, ce qui vous permet de prendre des mesures rapides si nécessaire.

Les notifications en temps réel se connectent à vos charges de travail existantes. Cette fonctionnalité vous permet de fusionner des actions. Par exemple, vous pouvez créer une fonction Cloud pour annuler une modification de ressource une fois celle-ci détectée.

Créer des alertes à l'aide des journaux d'audit Cloud

Les clusters GKE intègrent la journalisation d'audit Kubernetes avec les journaux d'audit Cloud et Cloud Logging. Kubernetes Engine Operations peut vous permettre de configurer des métriques basées sur vos entrées de journal. Vous pouvez ensuite utiliser des métriques basées sur les journaux pour configurer une règle d'alerte.

Les règles d'alerte spécifient les canaux de notification, qui vous permettent d'indiquer la manière dont vous souhaitez être informé lorsqu'une règle d'alerte est déclenchée. Vous pouvez configurer un gestionnaire de notifications à l'aide de Cloud Run ou de Cloud Functions afin de prendre des mesures en réponse, par exemple pour annuler la modification ou recevoir une notification par e-mail.

Conclusion

Pour intégrer les contrôles, déterminez vos besoins en matière d'audit et de surveillance. Déterminez ensuite le champ d'application des contrôles décrits dans ce guide et l'étape à laquelle ils doivent être configurés, comme indiqué dans les étapes suivantes.

  1. Avant de commencer à configurer vos clusters, consultez la section Modèles de surveillance et de journalisation hybrides et multicloud pour vous aider à déterminer le niveau d'isolation dont vous avez besoin.

  2. Créez vos clusters. Suivez les instructions du guide de renforcement du cluster applicable (GKE ou GKE On-Prem). Lors de la création de votre cluster, assurez-vous de suivre le guide de renforcement 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.

  3. 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.

  4. Installez Policy Controller à l'aide d'Anthos Config Management.

    Suivez les instructions du guide d'application des règles.

  5. Configurez Kubernetes Engine Operations en fonction de vos besoins :

  6. Configurez les règles, notifications et gestionnaires d'alerte Kubernetes Engine.

  7. Configurez les notifications en temps réel à partir de l'inventaire des éléments cloud.

  8. Configurez un processus permettant d'examiner régulièrement les résultats de conteneurs générés à partir des analyses Security Health Analytics.