Fonctionnalités de sécurité de Connect

Ce document décrit les mesures de sécurité intégrées à Connect.

Une plate-forme hybride et multicloud efficace qui offre gestion centralisée, observabilité et accès aux services à travers différents environnements. GKE Enterprise offre une expérience uniforme et complète de ces fonctionnalités, quel que soit le fournisseur Kubernetes que vous utilisez. Connect est un agent léger qui offre les avantages suivants à économies d'échelle et à travers différents fournisseurs :

  • Gestion multicluster et visibilité des clusters
  • Déploiement de services applicatifs et gestion du cycle de vie

Ce document traite les points suivants :

  • Comment la conception de Connect place la sécurité au premier plan
  • Les bonnes pratiques pour le déploiement de l'agent Connect
  • Comment améliorer la stratégie de sécurité de votre déploiement Kubernetes

Architecture de Connect

Connect permet aux utilisateurs finaux et aux services Google Cloud d'accéder aux serveurs d'API Kubernetes qui ne se trouvent pas sur l'Internet public. L'agent Connect s'exécute dans le cluster Kubernetes (un agent par cluster) et se connecte à un proxy Connect. Les services Google Cloud devant interagir avec le cluster Kubernetes se connectent au proxy, qui transmet les requêtes à l'agent. L'agent les transfère à son tour au serveur d'API Kubernetes, comme illustré dans le schéma suivant.

Architecture de l'accès des utilisateurs aux serveurs d'API Kubernetes qui ne sont pas connectés à Internet (cliquez pour agrandir)
Architecture de l'accès des utilisateurs aux serveurs d'API Kubernetes qui ne sont pas connectés à Internet (cliquez pour agrandir)

Lorsque l'agent est déployé, il établit une connexion TLS 1.2+ persistante avec Google Cloud pour attendre les requêtes. Lorsqu'ils sont activés par les administrateurs, les services Google Cloud peuvent générer des requêtes pour vos clusters Kubernetes. Ces requêtes peuvent également provenir d'une interaction directe de l'utilisateur avec la console Google Cloud, Connect Gateway ou d'autres services Google.

Le service Google Cloud envoie la requête au proxy. Le proxy transmet ensuite la requête à l'agent déployé responsable du cluster, et enfin l'agent transfère la requête au serveur d'API Kubernetes. Le serveur d'API Kubernetes applique les règles d'authentification, d'autorisation et d'enregistrement d'audit Kubernetes, puis renvoie une réponse. La réponse est transmise par le biais de l'agent et du proxy au service Google Cloud. À chaque étape du processus, les composants effectuent l'authentification et l'autorisation par connexion et par requête.

Le serveur d'API Kubernetes applique les mêmes règles d'authentification, d'autorisation et d'enregistrement des audits à toutes les requêtes, y compris celles via Connect. Ce processus vous garantit de toujours contrôler l'accès à votre cluster.

Connect et défense en profondeur

La défense en profondeur est inhérente à tout ce que fait Google Cloud dans le cadre de son infrastructure et de ses pratiques de sécurité. Nous appliquons une approche multidimensionnelle à tous les aspects de la sécurité de notre organisation et de nos clients afin de protéger les données importantes, les informations et les utilisateurs. C'est ce même principe qui a guidé la création de Connect.

En plus de la stratégie et de la conception de défense en profondeur propres à Google, vous devez évaluer le contenu fourni ici en tenant compte de votre stratégie et de vos normes de sécurité. Cette section présente des mesures supplémentaires que vous pouvez prendre en complément des bonnes pratiques de renforcement de Kubernetes.

Sécurité composant à composant

Chaque composant d'une requête Connect authentifie ses pairs et ne partage les données qu'avec des pairs authentifiés et autorisés pour ces données, comme illustré dans le schéma suivant.

Architecture de l'authentification des composants Connect (cliquez pour agrandir)
Architecture de l'authentification des composants Connect (cliquez pour agrandir)

Chaque composant d'une requête Connect utilise les éléments suivants pour s'authentifier mutuellement :

Chaque composant d'une requête Connect utilise les éléments suivants pour s'autoriser mutuellement :

  • Identity and Access Management (IAM)
  • Listes d'autorisation

Chaque connexion entre le cluster Kubernetes et Google Cloud est chiffrée, et au moins un pair de chaque connexion utilise une authentification basée sur des certificats. Ce processus permet de s'assurer que tous les identifiants de jeton sont chiffrés pendant leur acheminement et qu'ils sont reçus uniquement par des pairs authentifiés et autorisés.

Authentification des utilisateurs sur Google Cloud

Lorsque vous utilisez la console Google Cloud, les utilisateurs passent par le flux de connexion Google standard. Google Cloud fournit un certificat TLS que le navigateur de l'utilisateur authentifie. L'utilisateur se connecte à un compte Google Cloud ou Google Workspace pour s'authentifier sur Google Cloud.

L'accès à un projet via la console Google Cloud ou d'autres API est contrôlé par les autorisations IAM.

Authentification de service à service Google Cloud

Google Cloud utilise ALTS pour l'authentification de service à service interne. ALTS permet aux services Google Cloud, tels que le proxy, de créer une connexion authentifiée dont l'intégrité est protégée.

Les services Google Cloud doivent être autorisés en interne à utiliser un proxy pour se connecter à une instance Connect distante, car le proxy utilise une liste blanche d'identités de service pour limiter l'accès.

Authentification Google Cloud

L'agent utilise TLS pour authentifier et chiffrer chaque connexion. L'agent authentifie les certificats TLS Google Cloud à l'aide d'un ensemble de certificats intégrés au fichier binaire, afin d'éviter toute confiance involontaire aux certificats ajoutés au conteneur de l'agent. L'agent n'exécute des appels d'API que sur les points de terminaison correctement authentifiés. Ce processus permet de garantir que les certificats de compte de service et les requêtes de l'API Kubernetes sont envoyés par Google Cloud, et que les réponses ne sont envoyées qu'à Google Cloud.

Pour obtenir la liste des domaines avec lesquels l'agent communique pendant une opération normale, consultez la section Vérifier la connectivité réseau.

Vous pouvez configurer l'agent pour vous connecter à Google Cloud via un proxy HTTP. Dans cette configuration, l'agent utilise HTTP/1.1 CONNECT sur le proxy HTTP et établit une connexion TLS avec Google Cloud. Le proxy HTTP ne voit que le trafic chiffré entre l'agent et Google Cloud. L'intégrité de bout en bout et la sécurité de la connexion entre l'agent et Google Cloud ne sont pas affectées.

Authentification de l'agent

L'agent s'authentifie auprès de Google Cloud en utilisant un compte de service Google Cloud que vous créez. Lorsque l'administrateur du cluster déploie l'agent, il fournit une clé privée pour ce compte de service et assume la responsabilité de la confidentialité de la clé. Lorsque l'agent se connecte à Google Cloud, il s'authentifie auprès de ce compte de service et demande à recevoir des requêtes pour son projet configuré.

Google Cloud authentifie les identifiants du compte de service et vérifie également que le compte de service Google Cloud dispose de l'autorisation IAM gkehub.endpoints.connect dans le projet. Cette autorisation est généralement accordée via le rôle gkehub.connect. Sans cette autorisation, la requête de l'agent est refusée et il ne peut pas recevoir de requêtes provenant de Google Cloud.

Serveur d'API Kubernetes

L'agent utilise la bibliothèque cliente Kubernetes pour créer une connexion TLS avec le serveur d'API Kubernetes. L'environnement d'exécution Kubernetes fournit au conteneur de l'agent une autorité de certification TLS (certificat CA) utilisée par l'agent pour authentifier le serveur d'API.

Le serveur d'API authentifie chaque requête séparément, comme décrit dans la section suivante.

Sécurité de la requête

Chaque demande envoyée depuis Google Cloud via Connect inclut des identifiants qui indiquent l'expéditeur de la requête : le service Google Cloud qui a généré la requête et, le cas échéant, l'utilisateur final de la requête. Ces identifiants permettent au serveur d'API Kubernetes de fournir des contrôles d'autorisation et d'audit pour chaque requête.

Authentification de service à agent

Chaque requête envoyée à l'agent inclut un jeton à courte durée identifiant le service Google Cloud qui a envoyé la requête, comme illustré dans le schéma suivant.

Architecture des requêtes avec un jeton permettant d'identifier les services Google Cloud (cliquez pour agrandir)
Architecture des requêtes avec un jeton permettant d'identifier les services Google Cloud (cliquez pour agrandir)

Le jeton est signé par un compte de service Google Cloud associé exclusivement au service Google Cloud. L'agent récupère les clés publiques du compte de service pour valider le jeton. Ce jeton n'est pas transféré au serveur d'API.

L'agent valide les certificats Google Cloud à l'aide des racines CA intégrées au fichier binaire. Ce processus permet de s'assurer qu'il reçoit des requêtes authentiques et non modifiées de Google Cloud.

Authentification de l'utilisateur final

Les services Google Cloud qui accèdent aux clusters pour le compte d'un utilisateur requièrent les identifiants de l'utilisateur pour s'authentifier auprès du serveur d'API, comme illustré dans le schéma suivant.

Architecture des services Google Cloud qui authentifient les identifiants d'un utilisateur (cliquez pour agrandir)
Architecture des services Google Cloud qui authentifient les identifiants d'un utilisateur (cliquez pour agrandir)

Cette règle permet de garantir que le même ensemble d'autorisations est appliqué à l'utilisateur lorsqu'il accède via Connect. Certains services Google Cloud s'authentifient auprès du serveur d'API pour le compte d'un utilisateur. Par exemple, un utilisateur peut accéder à la console Google Cloud pour afficher les charges de travail dans les clusters enregistrés par un parc. Lorsqu'un utilisateur accède à ces services, il fournit des identifiants reconnus par le serveur d'API Kubernetes : l'un des jetons compatibles avec le serveur d'API Kubernetes.

La console Google Cloud stocke ces identifiants dans le profil d'un utilisateur. Ces identifiants sont chiffrés au repos, ne sont accessibles qu'avec les identifiants Google Cloud ou Google Workspace de l'utilisateur et ne sont utilisés que pour les connexions via Connect. Il est impossible de télécharger à nouveau ces identifiants. Les identifiants sont supprimés lorsque l'utilisateur se déconnecte du cluster, lorsque l'enregistrement du cluster est supprimé dans Google Cloud, lorsque le projet est supprimé ou lorsque le compte utilisateur est supprimé. Pour plus d'informations, consultez la section Suppression des données sur Google Cloud.

Lorsqu'un utilisateur interagit avec la console Google Cloud, il génère des requêtes pour le serveur d'API Kubernetes. Le service envoie les identifiants de l'utilisateur avec la requête via Connect. L'agent présente ensuite la requête et les identifiants au serveur d'API Kubernetes.

Le serveur d'API Kubernetes authentifie les identifiants de l'utilisateur, procède à l'autorisation sur l'identité de l'utilisateur, génère un événement d'audit pour l'action (s'il est configuré) et renvoie le résultat. Étant donné que les identifiants fournis par l'utilisateur sont utilisés pour authentifier la requête, le serveur d'API Kubernetes applique les mêmes règles d'autorisation et d'audit pour les requêtes Connect que pour les autres requêtes.

Authentification du service à Kubernetes

Les services Google Cloud qui accèdent au serveur d'API Kubernetes en dehors du contexte d'un utilisateur utilisent l'emprunt d'identité Kubernetes pour s'authentifier auprès du serveur d'API Kubernetes. Cette méthode permet au serveur d'API Kubernetes de fournir des vérifications d'autorisation par service et des journaux d'audit, comme illustré dans le schéma suivant.

Architecture des contrôles d'autorisation par service (cliquez pour agrandir)
Architecture des contrôles d'autorisation par service (cliquez pour agrandir)

Les services Google Cloud peuvent utiliser Connect en dehors du contexte de l'utilisateur. Par exemple, un service d'entrée multicluster peut synchroniser automatiquement les ressources d'entrée entre les clusters. Ces services ne disposent pas d'identifiants que le serveur d'API Kubernetes peut authentifier: la plupart des serveurs d'API ne sont pas configurés pour authentifier les identifiants du service Google Cloud. Toutefois, un serveur d'API peut déléguer des droits d'authentification limités à un autre service via l'emprunt d'identité. L'agent peut authentifier les services Google Cloud qui envoient des requêtes via Connect. Ensemble, ces requêtes permettent à l'agent de s'authentifier en tant que comptes de service Google Cloud.

Lorsqu'un service Google Cloud envoie une requête en son nom (et non dans le contexte de l'utilisateur), l'agent ajoute ses propres identifiants Kubernetes et en-têtes d'emprunt d'identité Kubernetes qui identifient le service Google Cloud, à la requête. Les en-têtes d'emprunt d'identité revendiquent le nom d'utilisateur du compte de service Google Cloud authentifié par l'agent.

Le serveur d'API Kubernetes authentifie les identifiants de l'agent et vérifie également que celui-ci peut emprunter l'identité du compte de service Google Cloud. La possibilité d'emprunter l'identité est généralement régulée par des règles de contrôle d'accès basé sur les rôles (RBAC) et peut être limitée à des identités spécifiques, telles que les comptes de service Google Cloud.

Si l'agent est autorisé à emprunter l'identité demandée, le serveur d'API effectue ensuite des contrôles d'autorisation pour le compte de service Google Cloud et diffuse la requête. Le journal d'audit de la requête inclut à la fois l'identité de l'agent et le compte de service Google Cloud emprunté.

Sécurité au sein du cluster

Au final, l'agent envoie les requêtes API Kubernetes au serveur d'API Kubernetes, comme illustré dans le schéma suivant.

Architecture des requêtes API Kubernetes envoyées au serveur d'API Kubernetes (cliquez pour agrandir)
Architecture des requêtes API Kubernetes envoyées au serveur d'API Kubernetes (cliquez pour agrandir)

Le serveur d'API Kubernetes authentifie, autorise et consigne dans des journaux ces requêtes, comme il le fait pour toutes les autres requêtes qu'il traite.

En tant que proxy pour ces requêtes, l'agent a accès aux données sensibles, telles que les identifiants, les requêtes et les réponses. Kubernetes et l'écosystème Kubernetes fournissent un ensemble d'outils pour empêcher d'autres acteurs d'obtenir cet accès et pour s'assurer que l'agent n'accède qu'à ce qui est nécessaire.

Authentification Kubernetes

Le serveur d'API Kubernetes authentifie l'expéditeur de chaque requête entrante pour déterminer les autorisations à appliquer lors de la phase d'autorisation. Comme décrit précédemment, la requête inclut les identifiants d'un utilisateur ou inclut les identifiants Kubernetes et les en-têtes d'emprunt d'identité de l'agent.

Les administrateurs de cluster gardent le contrôle des mécanismes d'authentification reconnus par le serveur d'API Kubernetes. Les administrateurs peuvent révoquer les identifiants de l'utilisateur et révoquer ou réduire le privilège des identifiants de l'agent.

Autorisation Kubernetes

Le serveur d'API Kubernetes vérifie que l'identité authentifiée est autorisée à effectuer l'action demandée sur la ressource demandée.

L'administrateur du cluster peut utiliser n'importe quel mécanisme d'autorisation Kubernetes pour configurer des règles d'autorisation. Connect n'effectue aucun contrôle des autorisations pour le compte du cluster.

Sécurité de l'agent

L'agent a accès à ses propres identifiants (Kubernetes et Google Cloud), ainsi qu'aux identifiants, requêtes et réponses qui les utilisent. Par conséquent, l'agent occupe une position de confiance dans un cluster connecté.

L'agent est conçu selon les principes de sécurité fondamentaux suivants :

  • L'agent est écrit en Go, ce qui permet de gérer la mémoire récupérée et évite de nombreuses opérations de sauvegarde non sécurisées.
  • L'agent est déployé dans une image de conteneur distroless. L'image de l'agent n'inclut pas d'interface système, de code libc ni d'autre code qui soit étranger au chemin d'exécution de l'agent.
  • L'image de l'agent est créée par l'infrastructure de conception partagée de Google à partir du code archivé. Seul ce système de compilation peut déployer des images d'agent dans Container Registry. Les développeurs Google Cloud ne peuvent pas déployer de nouvelles images par eux-mêmes. Ce processus permet de s'assurer que toutes les modifications apportées à la source de l'agent remontent à un auteur et à un réviseur pour non-répudiation.

L'agent s'exécute comme déploiement standard dans un cluster Kubernetes qui se déploie au moment où vous enregistrez votre cluster. Par conséquent, l'agent a accès à toutes les options et meilleures pratiques disponibles pour la surveillance et la sécurisation des déploiements, ReplicaSets et pods.

Ces mécanismes sont conçus pour rendre difficile la compromission du conteneur d'agents. Toutefois, un accès privilégié au nœud de l'agent peut compromettre l'environnement de l'agent. Il est donc important que les administrateurs respectent les consignes de sécurité standards de Kubernetes afin de protéger l'infrastructure du cluster.

Sécurité des données avec VPC Service Controls

VPC Service Controls offre un niveau de sécurité supplémentaire pour les services Google Cloud, indépendamment de la gestion de l'authentification et des accès (IAM). Tandis que les stratégies IAM permettent un contrôle d'accès précis basé sur l'identité, VPC Service Controls offre une sécurité périmétrique basée sur le contexte plus étendue, et permet de contrôler la sortie des données au-delà du périmètre. Par exemple, vous pouvez indiquer que seuls certains projets peuvent accéder à vos données BigQuery. Pour en savoir plus sur la manière dont VPC Service Controls protège vos données, consultez la page Présentation de VPC Service Controls.

Pour renforcer la sécurité des données, vous pouvez utiliser VPC Service Controls avec Connect, après vous être assuré que les services nécessaires à l'utilisation de Connect sont accessibles depuis le périmètre de service spécifié. Pour en savoir plus, consultez les conditions préalables de Connect.