Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

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 du trafic sortant pour les charges de travail exécutées sur le réseau ambient 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 des 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é en dehors 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).

Le flux de trafic de sortie fonctionne comme suit :

Un pod de charge de travail ou d'agent d'IA 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 proxy Web sécurisé réside dans un autre réseau VPC, le trafic transite 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 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 s'appliquent uniquement au niveau de l'espace de noms. La sélection précise des pods à l'aide de sélecteurs d'étiquettes n'est pas prise en charge.
Le filtrage des noms d'hôtes nécessite l'inspection TLS : les règles du Secure Web Proxy ne peuvent filtrer le trafic sortant que par adresse IP, sauf si l'inspection TLS est activée.
Workload Identity : la mise en réseau ambiante de GKE est compatible avec Workload Identity standard. Les pools d'identités d'agent géré ne sont pas compatibles avec cet aperçu.
Authentification : la connexion entre le proxy de nœud ambiant et le Secure Web Proxy ignore la validation du certificat de serveur. La requête CONNECT inclut un jeton illimité en plus du certificat client.
Recréation des ressources lors des mises à jour de configuration : les modifications apportées à une instance Secure Web Proxy ou à une configuration PSC existantes ne sont pas propagées automatiquement. Si vous mettez à jour votre configuration de Secure Web Proxy ou de 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ée du 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 conteneur.

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 votre projetCloud de Confiance by S3NS ou votre VPC partagé.
Si le Secure Web Proxy se trouve dans un réseau VPC différent de votre cluster GKE :
- Rattachement de service PSC créé pour Secure Web Proxy.
- Un point de terminaison consommateur PSC configuré dans le réseau VPC de votre cluster GKE.

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

Agent Gateway / Services réseau : networkservices.agentGateways.* (ou roles/networkservices.admin) pour configurer les ressources de l'Agent Gateway.
Gestion PSC : 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 de 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 usurper l'identité des destinations externes.

Votre application de charge de travail doit faire confiance au certificat d'autorité de certification privée présenté par le proxy Web sécurisé. Étant donné que GKE n'injecte pas automatiquement ce certificat, vous devez installer le certificat CA SWP (ancrage 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 fichier 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. Celui-ci 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 :

Enregistrez le manifeste suivant sous le nom swp-backend.yaml :

Même VPC
```
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 le réseau ambiant.
- PROJECT_ID : ID de votre projet Cloud de Confiance by S3NS .
- REGION : région dans laquelle votre Secure Web Proxy ou votre rattachement de service PSC est déployé.
- SWP_NAME : nom de votre proxy Web sécurisé.
Cross-VPC
```
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 le réseau ambiant.
- PROJECT_ID : ID de votre projet Cloud de Confiance by S3NS .
- REGION : région dans laquelle votre Secure Web Proxy ou 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 au proxy de nœud ambiant pour établir un tunnel HTTP CONNECT vers le Secure Web Proxy, ce qui est nécessaire au 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 le réseau ambiant.
- CLUSTER_CONTROL_PLANE_CIDR : plage CIDR pour les communications internes qui doivent contourner le 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 liés au routage de sortie ambiant :

Le trafic n'atteint pas le Secure Web Proxy :
- Vérifiez que la ressource GCPBackend pointe vers le bon URI de rattachement de service PSC.
- 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 involontairement à 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 liées aux certificats 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.