Es posible que parte de la información de esta página (o toda) no se aplique a Cloud de Confiance de S3NS. Consulta Diferencias con Google Cloud para obtener más información.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Prepara las herramientas de redes ambientales de GKE

Autopilot estándar

En esta página, se muestra cómo habilitar las redes perimetrales en un clúster nuevo o existente, inscribir espacios de nombres y cargas de trabajo para habilitar el redireccionamiento del tráfico perimetral, y configurar políticas de autorización y mTLS.

Para obtener más información sobre la arquitectura, los beneficios y las capacidades de las redes ambientales, consulta la Descripción general de las redes ambientales.

Requisitos previos y limitaciones

Antes de configurar la red ambiental, revisa las siguientes limitaciones de funciones, requisitos de versión y restricciones de alcance:

Versión de GKE: Se requiere la versión 1.35.2-gke.1842000 o posterior de GKE.
Compatibilidad regional: Los clústeres deben crearse en una región compatible con Regional Cloud Service Mesh.
Interoperabilidad de cargas de trabajo: Las cargas de trabajo inscritas en redes ambientales no pueden interoperar con cargas de trabajo insertadas en sidecar o gRPC sin proxy en la versión preliminar privada.
Funciones no admitidas:
- Campo Servicio de Kubernetes trafficDistribution
- Servicios sin interfaz gráfica.
- GKE Sandbox (gVisor).
Aviso de seguridad: Si el componente gke-ambient-nriplugin deja de estar disponible en un nodo, es posible que se omita la aplicación de la autenticación y la autorización del tráfico entrante.

Antes de comenzar

Completa los siguientes pasos de configuración previos en Cloud de Confiance by S3NS:

Crea o selecciona un proyecto.

Habilita las APIs necesarias:

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

Configura la autenticación de Workload Identity administrada para GKE.

Habilita las redes ambientales en un clúster nuevo

Ejecuta el siguiente comando para crear un clúster de GKE nuevo con redes ambientales habilitadas:

Crea un clúster de GKE con redes ambientales habilitadas

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

Ahora se ejecutan dos DaemonSets en el espacio de nombres gke-managed-ambient.

Habilita las redes ambientales en un clúster existente

Sigue estos pasos para habilitar Ambient Mesh en un clúster de GKE existente:

Verifica que tu clúster cumpla con los siguientes requisitos:
- Versión 1.35.2-gke.1842000 o posterior
- GKE Dataplane V2 habilitado
- El tipo de máquina debe ser e2-standard-4 o superior.
- El clúster debe agregarse a una flota.
- El clúster debe tener habilitadas la API de Gateway y Workload Identity.

Habilita las redes ambientales en un clúster existente:

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

Ahora se ejecutan dos DaemonSets en el espacio de nombres gke-managed-ambient.

Para verificarlo, apunta tu CLI al clúster:

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

Obtén los DaemonSets en el espacio de nombres gke-managed-ambient:

kubectl get daemonset -n gke-managed-ambient

El resultado es similar al siguiente:

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

Inscribe un espacio de nombres para la red ambiental

Sigue estos pasos para implementar una aplicación de ejemplo y habilitar el redireccionamiento de tráfico ambiental en su espacio de nombres:

Implementa una aplicación de ejemplo:

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

Etiqueta el espacio de nombres ambient-test para habilitar el redireccionamiento del tráfico a través del proxy de GKE ambient:
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Verifica que los Pods individuales del espacio de nombres se hayan configurado para el redireccionamiento del tráfico:

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

El resultado es similar al siguiente:

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

Prueba el tráfico del cliente al servidor:

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

Para verificar que el tráfico de texto simple fluya a través de gke-ambient-proxy, consulta los registros de acceso en el Explorador de registros y busca gke-ambient-node-proxy-accesslog:

Ve al Explorador de registros
De manera opcional, habilita la generación de métricas de capa 4 para las cargas de trabajo en el espacio de nombres:
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
Una vez habilitadas, las métricas de carga de trabajo estarán disponibles en Cloud Monitoring a través de Network Services Monitoring.

Habilita mTLS para un servicio

Después de habilitar el redireccionamiento del tráfico para las cargas de trabajo en un espacio de nombres, aplica políticas para exigir el uso de encriptación, autenticación y autorización.

Configura una política de mTLS permisiva en las cargas de trabajo del servidor:
```
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
```
Esta política hace que los Pods acepten tráfico de mTLS y texto simple. Ten en cuenta que la mTLS permisiva usa la detección de tráfico para determinar si el tráfico es mTLS o texto sin formato. Esto interrumpirá el tráfico de la aplicación que usa su propio protocolo TLS o un protocolo de "el servidor habla primero", como MySQL.

Verifica que el controlador haya aceptado la política:

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

El resultado es similar al siguiente:

[...]

    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 propagación de la política puede tardar hasta tres minutos después de que el controlador la acepte. Espera tres minutos antes de continuar.

Configura una política de mTLS del cliente que tenga como objetivo el servicio:

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

Esta política configura los clientes inscritos para que generen tráfico de mTLS hacia el servicio del servidor. Es posible que debas esperar al menos dos minutos antes de continuar con el siguiente paso.

Verifica que el controlador haya aceptado la política:

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

El resultado es similar al siguiente:

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

Prueba el tráfico del cliente al servidor:
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
El tráfico de los Pods inscritos en la red de ambiente al servicio del servidor en el espacio de nombres ambient-test ahora debería usar mTLS.
Para verificar que las conexiones usen mTLS, consulta los registros de acceso en el Explorador de registros y busca el nombre del registro personalizado:

Ve al Explorador de registros

Actualiza la política GCPServerTLSPolicy existente para cambiar mode de Permissive a Strict en el servicio del servidor, de modo que los Pods de carga de trabajo ya no acepten tráfico de texto sin formato:

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

Verifica que se haya aceptado la política:

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

El resultado es similar al siguiente:

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

Ahora se rechazará todo el tráfico de texto sin formato a tu servicio de servidor.

Para verificar que ahora se rechaza el tráfico de texto simple, envía tráfico al servicio del servidor desde un cliente que NO esté inscrito en la red ambiental:

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

Esta conexión debería fallar con un mensaje similar al siguiente:

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

Establece la política de autorización de capa 4

Para aplicar la autorización basada en la identidad, los propietarios de las cargas de trabajo especifican etiquetas de Pod en el selector de políticas. Los propietarios del espacio de nombres aplican políticas en todo el espacio de nombres sin selectores.

Aplica la siguiente política para exigir que solo el cliente pueda comunicarse con el servidor:

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

Esta política se aplica al tráfico hacia los Pods del servidor en el espacio de nombres ambient-test. Garantiza que solo se permita el tráfico de fuentes con la identidad de SPIFFE spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client.

Verifica que la aplicación de políticas esté permitida enviando una solicitud de muestra desde la cuenta de servicio del cliente.
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```

Para verificar que la aplicación de políticas no está permitida, envía una solicitud de muestra desde la cuenta de servicio del servidor.

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

El resultado es similar al siguiente:

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

Puedes usar el Explorador de registros para ver el registro de la aplicación de la autorización. En la consola de Cloud de Confiance , ve a la página Explorador de registros.

Ve al Explorador de registros