Migrar políticas

 lectura de 9 minutos     prueba de página

En modo ambient, la gestión de tráfico L7 la manejan los proxies waypoint en lugar de los proxies sidecar. Esto cambia cómo se expresan y aplican las políticas:

  • El soporte de VirtualService con waypoints es Alpha. Aunque puede funcionar en casos limitados, se recomienda fuertemente migrar a HTTPRoute. Mezclar VirtualService y HTTPRoute para el mismo workload no está soportado y lleva a comportamiento indefinido.
  • Las políticas de tráfico de DestinationRule (configuración del connection pool, detección de anomalías, TLS) son soportadas por los waypoints y no requieren cambios. Sin embargo, HTTPRoute usa Services de Kubernetes como backendRefs para el enrutamiento en lugar de subsets de DestinationRule, por lo que la división de tráfico basada en versiones en HTTPRoute requiere Services separados por versión.
  • Los recursos AuthorizationPolicy que usan reglas L7 (métodos HTTP, paths o headers), o que usan action: CUSTOM o action: AUDIT, deben usar targetRefs (en lugar del selector de workload) para adjuntar la política a los recursos soportados; para más información consulta la documentación de AuthorizationPolicy.
  • Los recursos RequestAuthentication y WasmPlugin requieren un waypoint proxy y deben apuntarse usando targetRefs para apuntar al waypoint.
  • Los recursos EnvoyFilter no están soportados en los waypoints. Si tienes recursos EnvoyFilter que configuran el comportamiento del proxy sidecar, serán ignorados silenciosamente después de la migración y deben manejarse antes de continuar:
    • Si el filtro agrega funcionalidad personalizada de Envoy, evalúa si un WasmPlugin puede proporcionar un comportamiento equivalente en el waypoint.
    • Si el filtro ya no es necesario, elimínalo.
    • Si no hay una alternativa compatible con ambient, esto es un bloqueador de migración. No continúes hasta que se resuelva la dependencia.

Auditar tus políticas existentes

Comienza listando todos los recursos L7 en tu clúster:

$ kubectl get virtualservice,destinationrule -A

Identifica los recursos AuthorizationPolicy que requerirán un waypoint (reglas L7 o acciones CUSTOM/AUDIT):

$ kubectl get authorizationpolicy -A --no-headers | while read ns name rest; do
    if kubectl get authorizationpolicy "$name" -n "$ns" -o yaml | grep -qE "(methods:|paths:|headers:|action: CUSTOM|action: AUDIT)"; then
      echo "$ns/$name"
    fi
  done

Identifica los recursos DestinationRule con subsets (estos requieren Services específicos por versión en modo ambient):

$ kubectl get destinationrule -A --no-headers | while read ns name rest; do
    if kubectl get destinationrule "$name" -n "$ns" -o yaml | grep -q "subsets:"; then
      echo "$ns/$name"
    fi
  done

Migrar VirtualService a HTTPRoute

HTTPRoute es la API de enrutamiento L7 estable y soportada para el modo ambient.

Ejemplo: Enrutamiento basado en headers

El siguiente VirtualService enruta las solicitudes con end-user: jason a la versión 2 de reviews, y todas las demás solicitudes a la versión 1 usando subsets:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Dado que HTTPRoute no soporta subsets de DestinationRule, primero debes crear Services específicos por versión:

apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
  namespace: bookinfo
spec:
  selector:
    app: reviews
    version: v1
  ports:
  - port: 9080
    name: http
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
  namespace: bookinfo
spec:
  selector:
    app: reviews
    version: v2
  ports:
  - port: 9080
    name: http

Luego reemplaza el VirtualService con un HTTPRoute que se adjunte directamente al Service reviews (usando kind: Service como parentRef). Este es el modelo de adjunción correcto para el modo ambient — el waypoint usa el Service como ancla de enrutamiento:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
  namespace: bookinfo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews
    port: 9080
  rules:
  - matches:
    - headers:
      - name: end-user
        value: jason
    backendRefs:
    - name: reviews-v2
      port: 9080
  - backendRefs:
    - name: reviews-v1
      port: 9080

Para una referencia completa sobre las capacidades de HTTPRoute, consulta la documentación de gestión de tráfico.

Migrar AuthorizationPolicy para reglas L7

En modo sidecar, los recursos AuthorizationPolicy usan un selector para apuntar directamente a los pods. En modo ambient, las políticas de autorización L7 deben ser aplicadas por un waypoint proxy y por tanto deben usar targetRefs para apuntar al Service padre del waypoint o al propio recurso Gateway.

Políticas L4 (no requieren cambios)

Los recursos L4 de AuthorizationPolicy que solo coinciden con principales de origen, namespaces o rangos de IP funcionan en modo ambient sin modificaciones. Los aplica ztunnel.

# Esta política L4 no requiere cambios para el modo ambient
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/bookinfo/sa/productpage"]

Políticas L7

Las políticas que coincidan con métodos HTTP, paths o headers, o que usen action: CUSTOM o action: AUDIT, deben apuntar a un waypoint proxy. Reemplaza selector con targetRefs apuntando al Service que el waypoint protege, o directamente al recurso Gateway del waypoint:

# Antes: estilo sidecar (basado en selector)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]
# Después: estilo ambient (targetRefs al Service)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: reviews
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

Alternativamente, puedes apuntar directamente al recurso Gateway del waypoint. Esto aplica la política a todo el tráfico procesado por el waypoint, independientemente del Service de destino:

# Después: estilo ambient (targetRefs al Gateway del waypoint)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  targetRefs:
  - kind: Gateway
    group: gateway.networking.k8s.io
    name: waypoint
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

Apuntar a un Service es la opción más precisa y se recomienda cuando la política debe aplicarse a un único servicio. Apuntar al Gateway es útil cuando la política debe aplicarse a todos los servicios del namespace.

Prevenir el bypass del waypoint

Cuando se usa un waypoint, asegúrate de que los workloads no puedan alcanzarse omitiendo el waypoint. Usa una política DENY con selector de workload aplicada por ztunnel (en el pod de destino). Dado que esta política solo verifica el principal de origen (un atributo L4), ztunnel puede aplicarla correctamente.

Decidir cuándo aplicar la prevención de bypass

Durante una migración incremental, algunos workloads de origen aún pueden estar en modo sidecar. Los workloads en modo sidecar omiten el waypoint y se conectan directamente a ztunnel en el destino, por lo que ztunnel ve la identidad del sidecar como principal de origen, no la identidad del waypoint. Una política DENY estricta solo para el waypoint rechazará su tráfico.

Elige una de las siguientes opciones antes de aplicar la política:

Opción 1: Retrasar la prevención de bypass hasta que todos los orígenes se hayan migrado. No apliques la política DENY hasta que cada workload que llame a este servicio haya pasado al modo ambient. Este es el enfoque más sencillo cuando controlas todos los llamadores.

Opción 2: Permitir tráfico tanto del waypoint como de los principales del sidecar. Aplica la política inmediatamente, pero agrega las cuentas de servicio de los workloads sidecar restantes a la lista de excepción notPrincipals junto con el waypoint. Elimina cada principal del sidecar de la lista a medida que se migra. Una vez que todos los llamadores estén en modo ambient, solo necesita quedar el principal del waypoint.

Aplicar la política de prevención de bypass

Busca la cuenta de servicio que usa tu waypoint:

$ kubectl get pod -n <namespace> -l gateway.istio.io/managed=istio.io-mesh-controller \
    -o jsonpath='{.items[0].spec.serviceAccountName}'

Para la Opción 1, aplica la política solo después de que todos los llamadores se hayan migrado:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-waypoint-bypass
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals:
        - "cluster.local/ns/bookinfo/sa/waypoint"

Para la Opción 2, incluye los principales del sidecar en la lista de excepciones durante la migración:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-waypoint-bypass
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals:
        - "cluster.local/ns/bookinfo/sa/waypoint"
        - "cluster.local/ns/bookinfo/sa/productpage"

Próximos pasos

Continúa con Habilitar el modo ambient para etiquetar namespaces, activar waypoints y eliminar la inyección de sidecar.

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

¡Gracias por tus comentarios!