Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Acheminer le trafic de sortie ambiant via Secure Web Proxy

Autopilot Standard

Cette page vous explique comment configurer le routage de sortie pour les charges de travail exécutées sur la mise en réseau ambiant Google Kubernetes Engine (GKE) vers une passerelle Secure Web Proxy (SWP).

En acheminant le trafic sortant via une passerelle Secure Web Proxy, vous pouvez appliquer des règles de sécurité de sortie centralisées (comme le filtrage d'URL, les listes d'autorisation de domaines et l'inspection TLS) sans modifier le code de votre application. Le proxy de nœud de couche 4 intercepte le trafic sortant en dehors du pod d'application, ce qui permet d'isoler la sécurité hors du pod même si un conteneur de charge de travail est compromis.

Architecture et flux de trafic

Dans ce modèle de déploiement, vous restez propriétaire de l'infrastructure, y compris du cluster GKE, de l'instance Secure Web Proxy et de tous les points de terminaison Private Service Connect (PSC) (pour les déploiements inter-VPC).

Le flux de trafic de sortie fonctionne comme suit :

Un pod de charge de travail lance le trafic sortant vers un point de terminaison externe ou une destination Internet.
Le proxy de nœud ambiant de couche 4 local intercepte la requête sortante sur le nœud.
Le proxy de nœud établit un tunnel HTTP CONNECT vers la passerelle de sortie.
Si le Secure Web Proxy réside dans le même réseau VPC, le trafic se connecte directement à la passerelle. Si le proxy Web sécurisé réside dans un autre réseau VPC, le trafic passe par un rattachement de service PSC.
Le Secure Web Proxy met fin au tunnel, applique les règles de sécurité de sortie configurées et transfère les requêtes autorisées vers la destination.

Limites

Avant de configurer le routage de sortie de Secure Web Proxy, consultez les limites suivantes en version preview :

Règles à l'échelle de l'espace de noms : les règles de routage de sortie ne s'appliquent qu'au niveau de l'espace de noms. La sélection de pods de manière précise à l'aide de sélecteurs d'étiquettes n'est pas possible.
Le filtrage des noms d'hôte nécessite une inspection TLS : les règles de Secure Web Proxy ne peuvent filtrer le trafic de sortie que par adresse IP, sauf si l'inspection TLS est activée.
Workload Identity : la mise en réseau ambiante GKE est compatible avec Workload Identity standard. Les pools d'identités d'agent gérés ne sont pas compatibles avec cette version preview.
Authentification : la connexion entre le proxy de nœud ambiant et Secure Web Proxy ignore la validation du certificat du serveur. La requête CONNECT inclut un jeton non limité ainsi que le certificat client.
Recréation de ressources lors des mises à jour de configuration : les modifications apportées à une instance Secure Web Proxy ou à une configuration PSC existante ne sont pas automatiquement propagées. Si vous mettez à jour votre configuration Secure Web Proxy ou PSC, vous devez supprimer et recréer la ressource GCPEgressPolicy et l'instance Secure Web Proxy pour appliquer les modifications.
Ancre de confiance pour l'inspection TLS : GKE n'injecte pas automatiquement le certificat CA privé Secure Web Proxy dans les conteneurs de charge de travail. Si vous utilisez l'inspection TLS, vous devez installer manuellement le certificat de confiance dans vos images de conteneurs.

Prérequis

Avant de configurer le routage de sortie, vérifiez que vous disposez des éléments suivants :

Un cluster GKE avec la mise en réseau ambiante activée. Pour obtenir des instructions, consultez Préparer la mise en réseau ambiante GKE.
Une instance Secure Web Proxy déployée avec un serverTlsPolicy configuré avec clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT dans votreGoogle Cloud projet ou VPC partagé.
Si le proxy Web sécurisé se trouve dans un réseau VPC différent de celui de votre cluster GKE :
- Un rattachement de service PSC créé pour Secure Web Proxy.
- Un point de terminaison client PSC configuré dans le réseau VPC de votre cluster GKE.

Pour effectuer ces étapes, vous devez disposer des rôles suivants :

Secure Web Proxy/Network Services : networkservices.gateways.* (ou roles/networkservices.admin) pour configurer les ressources de passerelle Secure Web Proxy.
Gestion PSC (déploiements inter-VPC uniquement) : compute.networkAttachments.list (ou roles/compute.networkAdmin) pour gérer les connexions Private Service Connect.
Gestion GKE : roles/container.clusterAdmin pour déployer des ressources personnalisées (GCPBackend, GCPEgressPolicy).

Configurer la confiance pour l'inspection TLS

Si votre règle Secure Web Proxy utilise l'inspection TLS pour inspecter le trafic sortant chiffré, le proxy génère des certificats signés par son autorité de certification (CA) privée pour emprunter l'identité des destinations externes.

Votre application de charge de travail doit faire confiance au certificat CA privé présenté par Secure Web Proxy. Comme GKE n'injecte pas ce certificat automatiquement, vous devez installer le certificat CA SWP (ancre de confiance) dans le magasin de confiance de votre conteneur.

Pour ajouter le certificat CA à votre image de conteneur, incluez les lignes suivantes dans votre Dockerfile :

COPY swp-ca-cert.pem /usr/local/share/ca-certificates/swp-ca-cert.crt
RUN update-ca-certificates

Définir le point de terminaison de la passerelle

La première étape de la configuration du routage de sortie ambiant consiste à créer un point de terminaison de passerelle, qui définit le point de terminaison Secure Web Proxy dans votre cluster GKE et informe la mise en réseau ambiante de l'emplacement du proxy.

Pour spécifier l'URI de votre rattachement de service Secure Web Proxy ou Private Service Connect (PSC), créez une ressource personnalisée GCPBackend dans votre cluster GKE :

Même VPC

Enregistrez le manifeste suivant sous le nom swp-backend.yaml :
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME
```
Remplacez les éléments suivants :
- ambient-test : espace de noms enregistré dans la mise en réseau ambiante.
- PROJECT_ID : ID de votre projet Google Cloud .
- REGION : région où votre Secure Web Proxy est déployé.
- SWP_NAME : nom de votre proxy Web sécurisé.
Appliquez la ressource GCPBackend :
```
kubectl apply -f swp-backend.yaml
```

Inter-VPC

Enregistrez le manifeste suivant sous le nom swp-backend.yaml :
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //compute.googleapis.com/projects/PROJECT_ID/regions/REGION/serviceAttachments/ATTACHMENT_NAME
```
Remplacez les éléments suivants :
- ambient-test : espace de noms enregistré dans la mise en réseau ambiante.
- PROJECT_ID : ID de votre projet Google Cloud .
- REGION : région dans laquelle votre rattachement de service PSC est déployé.
- ATTACHMENT_NAME : nom de votre rattachement de service PSC, si votre Secure Web Proxy se trouve dans un autre réseau VPC.
Appliquez la ressource GCPBackend :
```
kubectl apply -f swp-backend.yaml
```

Configurer la redirection du trafic de sortie

Créez une ressource personnalisée GCPEgressPolicy pour acheminer le trafic sortant de l'espace de noms vers la passerelle Secure Web Proxy. Cela fournit la signalisation nécessaire pour que le proxy de nœud ambiant établisse un tunnel HTTP CONNECT vers le proxy Web sécurisé, ce qui est nécessaire pour le routage de sortie.

Enregistrez le manifeste suivant sous le nom swp-egress-policy.yaml :
```
apiVersion: networking.gke.io/v1
kind: GCPEgressPolicy
metadata:
  name: swp-egress-policy
  namespace: ambient-test
spec:
  to:
    excludeCIDRRanges:
    - "CLUSTER_CONTROL_PLANE_CIDR"
  proxyRef:
    group: networking.gke.io
    kind: GCPBackend
    name: swp-backend
```
Remplacez les éléments suivants :
- ambient-test : espace de noms enregistré dans la mise en réseau ambiante.
- CLUSTER_CONTROL_PLANE_CIDR : plage CIDR pour les communications internes qui doivent contourner Secure Web Proxy (par exemple, la plage d'adresses du plan de contrôle GKE ou les sous-réseaux VPC internes).
Appliquez la ressource GCPEgressPolicy :
```
kubectl apply -f swp-egress-policy.yaml
```
Une fois la règle appliquée, le trafic sortant des charges de travail de l'espace de noms est redirigé vers le Secure Web Proxy.

Dépannage

Utilisez les instructions suivantes pour diagnostiquer et résoudre les problèmes de routage de sortie ambiant :

Le trafic n'atteint pas le Secure Web Proxy :
- Pour les déploiements sur un même VPC, vérifiez que la ressource GCPBackend pointe vers l'URI de passerelle Secure Web Proxy approprié.
- Pour les déploiements inter-VPC :
- Vérifiez que la ressource GCPBackend pointe vers l'URI de rattachement de service PSC approprié.
- Vérifiez que le point de terminaison PSC est établi et accepté dans le VPC du producteur.
- Vérifiez que excludeCIDRRanges dans GCPEgressPolicy ne correspond pas par inadvertance à votre trafic de destination.
Échecs de connexion mTLS :
- Vérifiez que Secure Web Proxy est configuré pour accepter les connexions du proxy de nœud.
Erreurs de certificat d'inspection TLS :
- Si les requêtes client échouent avec des erreurs de validation de certificat (telles que x509: certificate signed by unknown authority), vérifiez que le certificat CA Secure Web Proxy est correctement installé dans le magasin de certificats système du conteneur de charge de travail.