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.

Cómo enrutar el tráfico de salida ambiental a través de Secure Web Proxy

Autopilot estándar

En esta página, se muestra cómo configurar el enrutamiento de salida para las cargas de trabajo que se ejecutan en la red ambiental de Google Kubernetes Engine (GKE) a una puerta de enlace de Secure Web Proxy (SWP).

Si enrutas el tráfico saliente a través de una puerta de enlace de Secure Web Proxy, puedes aplicar políticas de seguridad de salida centralizadas, como el filtrado de URL, las listas de entidades permitidas de dominios y la inspección de TLS, sin modificar el código de la aplicación. El proxy de nodo de capa 4 intercepta el tráfico saliente fuera del Pod de la aplicación, lo que proporciona aislamiento de seguridad fuera del Pod, incluso si se vulnera un contenedor de carga de trabajo.

Arquitectura y flujo de tráfico

En este modelo de implementación, conservas la propiedad de la infraestructura, incluido el clúster de GKE, la instancia de Secure Web Proxy y cualquier extremo de Private Service Connect (PSC).

El flujo de tráfico de salida funciona de la siguiente manera:

Un Pod de agente de IA o carga de trabajo inicia tráfico saliente hacia un extremo externo o un destino de Internet.
El proxy de nodo local de capa 4 intercepta la solicitud saliente en el nodo.
El proxy de nodo establece un túnel HTTP CONNECT a la puerta de enlace de salida.
Si el Secure Web Proxy reside en una red de VPC diferente, el tráfico atraviesa un adjunto de servicio de PSC.
El Secure Web Proxy finaliza el túnel, aplica las políticas de seguridad de salida configuradas y reenvía las solicitudes autorizadas al destino.

Limitaciones

Antes de configurar el enrutamiento de salida de Secure Web Proxy, revisa las siguientes limitaciones de la versión preliminar:

Políticas a nivel del espacio de nombres: Las políticas de enrutamiento de salida solo se aplican a nivel del espacio de nombres. No se admite la selección granular de Pods con selectores de etiquetas.
El filtrado de nombres de host requiere la inspección de TLS: Las políticas de Secure Web Proxy solo pueden filtrar el tráfico de salida por dirección IP, a menos que se habilite la inspección de TLS.
Workload Identity: Las redes ambientales de GKE admiten Workload Identity estándar. Los grupos de identidades de agentes administrados no son compatibles con esta versión preliminar.
Autenticación: La conexión entre el proxy del nodo de Ambient y el Secure Web Proxy omite la verificación del certificado del servidor. La solicitud CONNECT incluye un token sin límites junto con el certificado de cliente.
Recreación de recursos en las actualizaciones de configuración: Los cambios realizados en una instancia existente de Secure Web Proxy o en la configuración de PSC no se propagan automáticamente. Si actualizas la configuración de Secure Web Proxy o PSC, debes borrar y volver a crear el recurso GCPEgressPolicy y la instancia de Secure Web Proxy para aplicar los cambios.
Ancla de confianza de inspección de TLS: GKE no inserta automáticamente el certificado de la AC privada de Secure Web Proxy en los contenedores de cargas de trabajo. Si usas la inspección de TLS, debes instalar manualmente el certificado de confianza en las imágenes de contenedor.

Requisitos previos

Antes de configurar el enrutamiento de salida, verifica que tengas lo siguiente:

Un clúster de GKE con redes ambientales habilitadas. Para obtener instrucciones, consulta Cómo preparar la red ambiental de GKE.
Una instancia de Secure Web Proxy implementada con un serverTlsPolicy configurado con clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT en tu proyecto deCloud de Confiance by S3NS o en la VPC compartida
Si el proxy web seguro se encuentra en una red de VPC diferente a la de tu clúster de GKE, haz lo siguiente:
- Es un adjunto de servicio de PSC creado para el Secure Web Proxy.
- Un extremo del consumidor de PSC configurado en la red de VPC de tu clúster de GKE

Para completar estos pasos, debes tener los siguientes roles:

Agent Gateway o Network Services: networkservices.agentGateways.* (o roles/networkservices.admin) para configurar recursos de la puerta de enlace de agente
Administración de PSC: compute.networkAttachments.list (o roles/compute.networkAdmin) para administrar conexiones de Private Service Connect
Administración de GKE: roles/container.clusterAdmin para implementar recursos personalizados (GCPBackend, GCPEgressPolicy).

Configura la confianza para la inspección de TLS

Si tu política de Secure Web Proxy usa la inspección de TLS para inspeccionar el tráfico saliente encriptado, el proxy genera certificados firmados por su autoridad certificadora (AC) privada para suplantar destinos externos.

Tu aplicación de carga de trabajo debe confiar en el certificado de la AC privada que presenta el Secure Web Proxy. Debido a que GKE no inserta este certificado automáticamente, debes instalar el certificado de la AC de SWP (ancla de confianza) en el almacén de confianza de tu contenedor.

Para agregar el certificado de la AC a tu imagen de contenedor, incluye las siguientes líneas en tu Dockerfile:

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

Define el extremo de la puerta de enlace

El primer paso para configurar el enrutamiento de salida ambiental es crear un extremo de puerta de enlace, que define el extremo del Secure Web Proxy dentro de tu clúster de GKE y le informa a la red ambiental la ubicación del proxy.

Para especificar el URI de tu Secure Web Proxy o adjunto de servicio de Private Service Connect (PSC), crea un recurso personalizado GCPBackend en tu clúster de GKE:

Guarda el siguiente manifiesto como swp-backend.yaml:

Misma 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
```
Reemplaza lo siguiente:
- ambient-test: Es el espacio de nombres inscrito en las redes ambientales.
- PROJECT_ID: Es el ID del proyecto de Cloud de Confiance by S3NS .
- REGION: Es la región en la que se implementa tu Secure Web Proxy o tu adjunto de servicio de PSC.
- SWP_NAME: Es el nombre de tu Secure Web Proxy.
Entre VPCs
```
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
```
Reemplaza lo siguiente:
- ambient-test: Es el espacio de nombres inscrito en las redes ambientales.
- PROJECT_ID: Es el ID del proyecto de Cloud de Confiance by S3NS .
- REGION: Es la región en la que se implementa tu Secure Web Proxy o tu adjunto de servicio de PSC.
- ATTACHMENT_NAME: Es el nombre de tu vinculación de servicio de PSC si tu Secure Web Proxy se encuentra en una red de VPC diferente.
Aplica el recurso GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Configura el redireccionamiento del tráfico de salida

Crea un recurso personalizado GCPEgressPolicy para enrutar el tráfico saliente del espacio de nombres a la puerta de enlace de Secure Web Proxy. Esto proporciona la señalización necesaria para que el proxy del nodo ambiental establezca un túnel HTTP CONNECT al Secure Web Proxy, lo que es necesario para el enrutamiento de salida.

Guarda el siguiente manifiesto como 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
```
Reemplaza lo siguiente:
- ambient-test: Es el espacio de nombres inscrito en la red ambiental.
- CLUSTER_CONTROL_PLANE_CIDR: Es el rango CIDR para las comunicaciones internas que deben omitir el Secure Web Proxy (como el rango de direcciones del plano de control de GKE o las subredes internas de la VPC).
Aplica el recurso GCPEgressPolicy:
```
kubectl apply -f swp-egress-policy.yaml
```
Después de que se aplica la política, el tráfico saliente de las cargas de trabajo en el espacio de nombres se redirecciona a Secure Web Proxy.

Soluciona problemas

Usa la siguiente guía para diagnosticar y resolver problemas relacionados con el enrutamiento de salida ambiental:

El tráfico no llega al Secure Web Proxy:
- Verifica que el recurso GCPBackend apunte al URI correcto del adjunto de servicio de PSC.
- Verifica que el extremo de PSC se haya establecido y aceptado en la VPC del productor.
- Verifica que excludeCIDRRanges en GCPEgressPolicy no coincida de forma accidental con el tráfico de destino.
Errores de conexión de mTLS:
- Verifica que el Secure Web Proxy esté configurado para aceptar conexiones del proxy de nodo.
Errores de certificado de inspección de TLS:
- Si las solicitudes del cliente fallan con errores de validación de certificados (como x509: certificate signed by unknown authority), verifica que el certificado de la AC del Secure Web Proxy esté instalado correctamente en el almacén de certificados del sistema del contenedor de la carga de trabajo.