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 votre fournisseur Kubernetes. 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 sont 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 qui doivent interagir avec le cluster Kubernetes se connectent au proxy, qui transfère les requêtes à l'agent. L'agent les transfère à son tour vers le serveur d'API Kubernetes, comme illustré dans le schéma suivant.
Lorsque l'agent est déployé, il établit une connexion TLS 1.2+ permanente 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, la passerelle Connect ou d'autres services Google.
Le service Google Cloud envoie la requête au proxy. Le proxy transfère ensuite la requête à l'agent de déploiement responsable d'un cluster, puis 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 des audits 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 les requêtes 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.
Chaque composant d'une requête Connect utilise les éléments suivants pour s'authentifier mutuellement :
- TLS (Transport Layer Security)
- Application Layer Transport Security (ALTS)
- OAuth
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 d'autorisation 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 s'assurer que les certificats des comptes de service et les requêtes de l'API Kubernetes sont envoyés par Google Cloud, et que les réponses sont envoyées uniquement à 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.
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.
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 des clusters connectés à Fleet. Lorsqu'un utilisateur accède à ces services, il fournit des identifiants reconnus par le serveur d'API Kubernetes : l'un des jetons compatibles.
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, autorise l'identité de l'utilisateur, génère un événement d'audit pour l'action si elle est configurée, puis 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.
Authentification du service à Kubernetes
Les services Google Cloud qui accèdent au serveur d'API Kubernetes en dehors du contexte d'un utilisateur se servent de 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.
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 l'agent peut se faire passer pour le 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
L'agent envoie finalement des requêtes d'API Kubernetes au serveur d'API Kubernetes, comme illustré dans le schéma suivant.
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 afin de déterminer les autorisations à appliquer lors de l'étape 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é.
Si vous souhaitez utiliser VPC Service Controls, vous devez activer les API suivantes :
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
Vous devez également configurer la connectivité privée pour accéder aux API concernées. Découvrez comment effectuer cette opération dans la section Configurer une connectivité privée.