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.

Préparer la mise en réseau ambiante GKE

Autopilot Standard

Cette page explique comment activer la mise en réseau ambiante sur un cluster nouveau ou existant, comment enregistrer des espaces de noms et des charges de travail pour activer la redirection du trafic ambiant, et comment configurer les stratégies d'autorisation et mTLS.

Pour en savoir plus sur l'architecture, les avantages et les fonctionnalités de la mise en réseau ambiante, consultez la présentation de la mise en réseau ambiante.

Prérequis et limitations

Avant de configurer la mise en réseau ambiante, consultez les limitations de fonctionnalités, les exigences de version et les restrictions de portée suivantes :

Version GKE : nécessite la version 1.35.2-gke.1842000 de GKE ou une version ultérieure.
Assistance régionale : les clusters doivent être créés dans une région compatible avec Regional Cloud Service Mesh.
Interopérabilité des charges de travail : les charges de travail enregistrées dans la mise en réseau ambiante ne peuvent pas interagir avec les charges de travail injectées par side-car ni avec gRPC sans proxy en aperçu privé.
Fonctionnalités non compatibles :
- Champ trafficDistribution du service Kubernetes.
- Services sans adresse IP de cluster.
- GKE Sandbox (gVisor).
Avis de sécurité : Si le composant gke-ambient-nriplugin devient indisponible sur un nœud, l'authentification et l'autorisation du trafic entrant peuvent être contournées.

Avant de commencer

Suivez les étapes de configuration préalables suivantes dans Cloud de Confiance by S3NS :

Créer ou sélectionner un projet

Activez les API requises :

gcloud services enable \
    privateca.googleapis.com \
    gkehub.googleapis.com \
    compute.googleapis.com \
    container.googleapis.com \
    trafficdirector.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    telemetry.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com

Configurer l'authentification des identités de charge de travail gérées pour GKE

Activer la mise en réseau ambiante sur un nouveau cluster

Exécutez la commande suivante pour créer un cluster GKE avec la mise en réseau ambiante activée :

Créer un cluster GKE avec le réseau ambiant activé

gcloud beta container clusters create CLUSTER_NAME \
    --machine-type=e2-standard-4 \
    --enable-ambient-networking \
    --enable-dataplane-v2 \
    --enable-fleet \
    --gateway-api=standard \
    --location=CLUSTER_LOCATION \
    --release-channel=rapid \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

Deux DaemonSets s'exécutent désormais dans l'espace de noms gke-managed-ambient.

Activer la mise en réseau ambiante sur un cluster existant

Pour activer le maillage ambiant sur un cluster GKE existant, procédez comme suit :

Vérifiez que votre cluster répond aux exigences suivantes :
- Version 1.35.2-gke.1842000 ou ultérieure.
- GKE Dataplane V2 activé.
- Le type de machine doit être e2-standard-4 ou supérieur.
- Le cluster doit être ajouté à un parc.
- L'API Gateway et Workload Identity doivent être activés sur le cluster.

Activez la mise en réseau ambiante sur un cluster existant :

gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet

Deux DaemonSets s'exécutent désormais dans l'espace de noms gke-managed-ambient.

Pour vérifier, pointez votre CLI vers le cluster :

gcloud beta container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION

Récupérez les DaemonSets dans l'espace de noms gke-managed-ambient :

kubectl get daemonset -n gke-managed-ambient

Le résultat est semblable à :

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
gke-ambient-nriplugin   9         9         9       9            9           4d1h
gke-ambient-proxy       9         9         9       9            9           4d1h

Enregistrer un espace de noms pour le réseau ambiant

Pour déployer un exemple d'application et activer la redirection du trafic ambiant sur son espace de noms, procédez comme suit :

Déployez un exemple d'application :

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: client
  namespace: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: server
  namespace: ambient-test
---
apiVersion: v1
kind: Service
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
  namespace: ambient-test
  labels:
    app: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      serviceAccountName: client
      containers:
      - name: nginx
        image: nginx:1.29.6
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      serviceAccountName: server
      containers:
      - name: nginx
        image: nginx:1.29.6
        readinessProbe:
          httpGet:
            path: /
            port: 80
EOF

Ajoutez un libellé à l'espace de noms ambient-test pour activer la redirection du trafic via le proxy ambient GKE :
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Vérifiez que les pods individuels de l'espace de noms ont été configurés pour la redirection du trafic :

kubectl get pods -n ambient-test -o yaml | grep redirection

Le résultat est semblable à :

ambient.networking.gke.io/redirection: enabled
ambient.networking.gke.io/redirection: enabled

Testez le trafic client-serveur :

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Pour vérifier que le trafic en texte brut transite par gke-ambient-proxy, consultez les journaux d'accès dans l'explorateur de journaux et recherchez gke-ambient-node-proxy-accesslog :

Accéder à l'explorateur de journaux
Vous pouvez également activer la génération de métriques de couche 4 pour les charges de travail de l'espace de noms :
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
Une fois activées, les métriques de charge de travail sont disponibles dans Cloud Monitoring via Surveillance des services réseau.

Activer mTLS pour un service

Après avoir activé la redirection du trafic pour les charges de travail d'un espace de noms, appliquez des règles pour forcer le chiffrement, l'authentification et l'autorisation.

Configurez une règle mTLS permissive sur les charges de travail côté serveur :
```
kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Permissive
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF
```
Cette règle permet aux pods d'accepter à la fois le trafic mTLS et le trafic en texte brut. Notez que le protocole mTLS permissif utilise l'espionnage du trafic pour détecter si le trafic est mTLS ou en texte brut. Cela interrompra le trafic d'application qui utilise son propre protocole TLS ou un protocole "server speaks first" (le serveur parle en premier) tel que MySQL.

Vérifiez que la règle a été acceptée par le responsable du traitement :

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

Le résultat est semblable à :

[...]

    Conditions:
    Last Transition Time:  2026-03-25T17:47:30Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                   From                   Message
----    ------  ----                  ----                   -------
Normal  Sync    108s (x2 over 2m20s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-fqtx-mesh succeeded

La propagation des règles peut prendre jusqu'à trois minutes après l'acceptation du contrôleur. Patientez trois minutes avant de continuer.

Configurez une règle mTLS côté client qui cible le service :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPClientTLSPolicy
metadata:
  name: server-mtls
  namespace: ambient-test
spec:
  targetRefs:
  - group: ""
    kind: Service
    name: server
  subjectAltNames:
  - uri: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/server
EOF

Cette règle configure les clients enregistrés pour qu'ils génèrent du trafic mTLS vers le service de serveur. Vous devrez peut-être patienter au moins deux minutes avant de passer à l'étape suivante.

Vérifiez que la règle a été acceptée par le responsable du traitement :

kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 Status

Le résultat est semblable à :

[...]
Status:
Conditions:
    Last Transition Time:  2024-10-13T01:15:03Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted

Testez le trafic client-serveur :
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
Le trafic des pods enregistrés dans le réseau ambiant vers le service de serveur dans l'espace de noms ambient-test doit désormais utiliser mTLS.
Pour vérifier que les connexions utilisent mTLS, consultez les journaux d'accès dans l'explorateur de journaux et recherchez le nom du journal personnalisé :

Accéder à l'explorateur de journaux

Mettez à jour la règle GCPServerTLSPolicy existante pour remplacer mode par Strict sur le service de serveur afin que les pods de charge de travail n'acceptent plus le trafic en texte brut :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Strict
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF

Vérifiez que les conditions ont été acceptées :

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

Le résultat est semblable à :

Name:         server

<...>

UID:                 e4f2a7a3-69aa-4528-8ea6-6f1bf2142011
Spec:
Mtls Mode:  Strict
Target Refs:
Group:
Kind:   Pod
Selector:
  Match Labels:
    App:  server
Status:
Ancestors:
    Ancestor Ref:
    Group:
    Kind:   Pod
    Name:   app=server
    Conditions:
    Last Transition Time:  2026-03-25T22:33:54Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                  From                   Message
----    ------  ----                 ----                   -------
Normal  Sync    43s (x5 over 4m57s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-2cdi-mesh succeeded

Tout trafic en texte brut vers votre service de serveur sera désormais refusé.

Pour vérifier que le trafic en texte brut est désormais refusé, envoyez du trafic au service de serveur depuis un client qui n'est PAS inscrit au réseau ambiant :

kubectl create namespace noambient-test && \
kubectl run -it -n noambient-test --rm curl --image=nginx -- \
    /bin/curl -fsLSv http://server.ambient-test.svc.cluster.local

Cette connexion doit échouer et renvoyer un message semblable à celui-ci :

* Request completely sent off
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

Définir une règle d'autorisation de couche 4

Pour appliquer l'autorisation basée sur l'identité, les propriétaires de charges de travail spécifient des libellés de pod dans le sélecteur de règles. Les propriétaires d'espaces de noms appliquent des règles à l'ensemble de l'espace de noms sans sélecteurs.

Appliquez la règle suivante pour que seul le client soit autorisé à communiquer avec le serveur :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
        - principalSelector: CLIENT_CERT_URI_SAN
          principal:
            type: Exact
            value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

Cette règle est appliquée au trafic vers les pods de serveur dans l'espace de noms ambient-test. Il garantit que le trafic n'est autorisé qu'à partir de sources avec l'identité SPIFFE spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client.

Vérifiez que l'application des règles est autorisée en envoyant un exemple de requête depuis le compte de service client.

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Vérifiez que l'application des règles n'est pas autorisée en envoyant un exemple de requête depuis le compte de service server.

kubectl exec -it deploy/server -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Le résultat est semblable à :

curl: (52) Empty reply from server
command terminated with exit code 52

Vous pouvez utiliser l'explorateur de journaux pour afficher la journalisation de l'application des autorisations. Dans la console Cloud de Confiance , accédez à la page Explorateur de journaux.

Accéder à l'explorateur de journaux