Gateways de salida

 lectura de 6 minutos     prueba de página

Un gateway de salida es un proxy dedicado por el que debe pasar todo el tráfico saliente hacia servicios externos. Proporciona un único punto de salida verificable para el tráfico que abandona la mesh, donde puedes aplicar políticas de autorización, habilitar la observabilidad y originar TLS.

En el modo sidecar, configurar un gateway de salida para un único host requiere coordinar cinco objetos distintos: un ServiceEntry, un Gateway, dos recursos HTTPRoute (uno para dirigir el tráfico de la mesh hacia el gateway y otro para reenviar el tráfico desde el gateway hasta el destino) y un DestinationRule. Cada nuevo host externo repite la mayor parte de ese trabajo.

En el modo ambient, un waypoint proxy actúa de forma natural como gateway de salida. ztunnel enruta automáticamente el tráfico al waypoint de un servicio antes de reenviarlo al destino. Si colocas un ServiceEntry en un namespace inscrito para usar un waypoint, todo el tráfico de la mesh hacia ese host externo pasa por el waypoint automáticamente, sin necesidad de reglas de enrutamiento adicionales.

Antes de empezar

  • Instala Istio con el modo ambient habilitado.

  • Despliega un workload que sirva como origen del tráfico. El ejemplo curl funciona bien:

    Zip
    $ kubectl apply -f @samples/curl/curl.yaml@

  • Etiqueta el namespace del workload para el modo ambient para que ztunnel intercepte su tráfico:

    $ kubectl label namespace default istio.io/dataplane-mode=ambient

Configurar el namespace de salida

Crea un namespace dedicado para los recursos de salida. Aislar las definiciones de servicios externos y sus políticas de los namespaces de las aplicaciones simplifica la administración y reduce el impacto de posibles errores de configuración.

$ kubectl create namespace istio-egress
$ kubectl label namespace istio-egress istio.io/dataplane-mode=ambient

Desplegar el waypoint de salida

Despliega un waypoint proxy en el namespace de salida e inscribe el namespace para que lo use. El flag --enroll-namespace agrega la etiqueta istio.io/use-waypoint al namespace, de modo que todos los servicios definidos allí, incluidos los respaldados por un ServiceEntry, se enrutarán a través del waypoint.

Ten en cuenta que las CRD de la API de Gateway de Kubernetes no vienen instaladas por defecto en la mayoría de los clusteres de Kubernetes, así que asegúrate de que estén instaladas antes de usar la API de Gateway:

$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/standard-install.yaml
$ istioctl waypoint apply --for service --enroll-namespace --namespace istio-egress
✅ waypoint istio-egress/waypoint applied
✅ namespace istio-egress labeled with "istio.io/use-waypoint: waypoint"

Confirma que el waypoint está listo:

$ istioctl waypoint list -n istio-egress
NAME       REVISION  TRAFFIC TYPE  PROGRAMMED
waypoint   default   service       True

Definir un servicio externo

Crea un ServiceEntry en el namespace de salida para representar el host externo. Como el namespace está inscrito para usar el waypoint, ztunnel enruta automáticamente a través del waypoint todo el tráfico de la mesh hacia ese host. El ServiceEntry es visible en todo el clúster por defecto (exportTo: *), por lo que el ztunnel de cada nodo resuelve httpbin.org al waypoint de istio-egress sin ninguna configuración adicional.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: httpbin-org
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
EOF

Verificar que el tráfico pasa por el waypoint de salida

Envía una request desde el pod de curl al host externo y confirma que llega al destino:

$ kubectl exec deploy/curl -- curl -s -o /dev/null -w "%{http_code}" http://httpbin.org/get
200

Para confirmar que el tráfico atravesó el waypoint, revisa las estadísticas de Envoy del waypoint:

$ kubectl exec -n istio-egress deploy/waypoint -c istio-proxy -- pilot-agent request GET stats | grep upstream_rq_total

Un valor distinto de cero en upstream_rq_total (el número de solicitudes que el waypoint reenvió upstream) confirma que el waypoint está actuando como gateway de salida.

Aplicar políticas de acceso

Como el tráfico pasa por el waypoint, puedes adjuntar políticas de autorización de capa 7 directamente al ServiceEntry. La siguiente política permite que cualquier origen realice solicitudes GET únicamente a /get:

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-org
  namespace: istio-egress
spec:
  targetRefs:
  - kind: ServiceEntry
    group: networking.istio.io
    name: httpbin-org
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]
        paths: ["/get"]
EOF

Después de aplicar la política, verifica que las solicitudes permitidas tienen éxito:

$ kubectl exec deploy/curl -- curl -s -o /dev/null -w "%{http_code}" http://httpbin.org/get
200

Confirma que una solicitud no permitida es rechazada:

$ kubectl exec deploy/curl -- curl -s -o /dev/null -w "%{http_code}" -X POST http://httpbin.org/post
403

Originar TLS en el gateway de salida

Los pods de la aplicación pueden enviar HTTP en texto plano al gateway de salida; el gateway lo actualiza a HTTPS antes de reenviarlo al host externo. Esto concentra la gestión de credenciales TLS en el gateway y evita distribuir certificados a cada pod de la aplicación.

Actualiza el ServiceEntry para mapear el puerto de texto plano al puerto TLS y agrega un DestinationRule para originar la conexión TLS:

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: httpbin-org
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
    targetPort: 443
  resolution: DNS
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: httpbin-org-tls
  namespace: istio-egress
spec:
  host: httpbin.org
  trafficPolicy:
    tls:
      mode: SIMPLE
EOF

Verifica que la aplicación sigue recibiendo una respuesta, ahora enviada sobre HTTPS por el gateway:

$ kubectl exec deploy/curl -- curl -s http://httpbin.org/get | head -5

Agregar un servicio externo sin originación de TLS

Para exponer hosts externos adicionales a través del mismo waypoint de salida, crea otro ServiceEntry en el mismo namespace. No se necesita configuración adicional del waypoint porque el namespace ya está inscrito:

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: example-com
  namespace: istio-egress
spec:
  hosts:
  - example.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
EOF

Verifica que el tráfico hacia el nuevo host también se enruta a través del waypoint:

$ kubectl exec deploy/curl -- curl -s -o /dev/null -w "%{http_code}" http://example.com
200

Cada ServiceEntry del namespace se enruta automáticamente a través del waypoint y puede tener su propia AuthorizationPolicy.

Limpieza

Zip
$ kubectl delete namespace istio-egress
$ kubectl delete -f @samples/curl/curl.yaml@
$ kubectl label namespace default istio.io/dataplane-mode-

Ver también

¿Fue útil esta información?
¿Tienes alguna sugerencia para mejorar?

¡Gracias por tus comentarios!