:Layer 7 authorization policies for waypoint proxies

Funcionamiento de la autorización con proxy waypoint

Sin un proxy waypoint, los ztunnels aplican la autorización únicamente en la capa 4 (puertos, direcciones IP, identidades). Una vez que despliega un proxy waypoint para un servicio:

1. El ztunnel delega todas las decisiones de autorización de ese servicio al proxy waypoint y permite que el tráfico del waypoint pase sin condiciones.

2. Las directivas de autorización que usan selector para coincidir con el pod de la aplicación (dirigidas al ztunnel) se omiten.

3. Las directivas de autorización deben usar selector con la etiqueta istio.io/gateway-name para dirigirse al proxy waypoint.

El proxy waypoint puede entonces aplicar directivas de capa 7 basadas en atributos HTTP como hosts, rutas, métodos y encabezados. Cuando se deniega una solicitud, el waypoint devuelve RBAC: access denied con un estado HTTP 403.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

• Una instancia de ASM que ejecute la versión 1.18

• Un ingress gateway y aplicaciones de ejemplo desplegadas con las funciones básicas verificadas. Para más detalles, consulte los requisitos previos y el Paso 1 en Getting started

Limitaciones

Despliegue de un proxy waypoint

Despliegue un proxy waypoint para el servicio productpage antes de ejecutar los ejemplos.

1. Despliegue el proxy waypoint:

   istioctl x waypoint apply --service-account bookinfo-productpage

2. Compruebe que el pod del proxy waypoint esté en ejecución:

   kubectl get pod --show-labels | grep waypoint

   Salida esperada:

   bookinfo-productpage-istio-waypoint-6c579dd48d-l****   1/1     Running   0          91s    gateway.istio.io/managed=istio.io-mesh-controller,istio.io/gateway-name=bookinfo-productpage,pod-template-hash=6c579dd48d,service.istio.io/canonical-name=bookinfo-productpage-istio-waypoint,service.istio.io/canonical-revision=latest,sidecar.istio.io/inject=false

Ejemplo 1: Las directivas dirigidas a ztunnel no tienen efecto cuando hay un proxy waypoint desplegado

Un error de configuración común es aplicar una directiva de autorización a un ztunnel cuando ya existe un proxy waypoint desplegado para el servicio. Dado que el ztunnel delega en el proxy waypoint, la directiva se omite por completo. Este ejemplo muestra primero el enfoque incorrecto y luego explica cómo corregirlo.

Ejemplo 2: Denegar acceso desde una dirección IP específica

Las directivas de autorización del proxy waypoint no admiten ipBlocks. Utilice remoteIpBlocks para coincidir con la dirección IP original del cliente. Configure el campo remoteIpBlocks para filtrar las solicitudes que pasan por el gateway.

1. Cree un archivo productpage-viewer.yaml que deniegue la dirección IP del pod sleep:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: productpage-viewer
    namespace: default
   spec:
    selector:
      matchLabels:
        istio.io/gateway-name: bookinfo-productpage
    action: DENY
    rules:
    - from:
      - source:
          remoteIpBlocks:
          - "${sleep Pod IP}"

   Reemplace ${sleep Pod IP} con la dirección IP real del pod sleep.

2. Aplique la directiva:

   kubectl apply -f productpage-viewer.yaml

3. Pruebe el acceso desde el pod sleep.

   A través del gateway:

   kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"

   Salida:

   RBAC: access denied%

   Acceso directo:

   kubectl exec deploy/sleep -- curl -s http://productpage:9080/ -I

   Salida:

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Fri, 19 Jul 2024 08:17:08 GMT
   server: istio-envoy

   Se deniega tanto el acceso a través del gateway como el acceso directo desde el pod sleep.

4. Limpieza:

   kubectl delete authorizationpolicy productpage-viewer

Ejemplo 3: Denegar acceso desde un namespace específico

Este ejemplo bloquea todo el tráfico originado en el namespace istio-system. Dado que el ingress gateway se ejecuta en istio-system, las solicitudes enrutadas por el gateway se deniegan, mientras que las solicitudes directas de pod a pod desde otros namespaces siguen funcionando correctamente.

1. Cree un archivo productpage-viewer.yaml:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: productpage-viewer
    namespace: default
   spec:
    selector:
      matchLabels:
        istio.io/gateway-name: bookinfo-productpage
    action: DENY
    rules:
    - from:
      - source:
          namespaces:
          - istio-system

2. Aplique la directiva:

   kubectl apply -f productpage-viewer.yaml

3. Pruebe el acceso.

   A través del gateway desde sleep:

   kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"

   Salida:

   RBAC: access denied%

   A través del gateway desde notsleep:

   kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"

   Salida:

   RBAC: access denied%

   Acceso directo desde sleep:

   kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

   Salida:

   <title>Simple Bookstore App</title>

   Acceso directo desde notsleep:

   kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

   Salida:

   <title>Simple Bookstore App</title>

   El tráfico enrutado por el gateway se deniega porque este se ejecuta en el namespace istio-system. El acceso directo desde pods en otros namespaces (como default) no se ve afectado.

4. Limpieza:

   kubectl delete authorizationpolicy productpage-viewer

Ejemplo 4: Denegar solicitudes por encabezado host

Este ejemplo deniega las solicitudes cuyo encabezado host es test.com en el puerto 9080. Las solicitudes con otros valores de host pasan sin restricciones.

1. Cree un archivo productpage-viewer.yaml:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-viewer
     namespace: default
   spec:
     selector:
       matchLabels:
         istio.io/gateway-name: bookinfo-productpage
     action: DENY
     rules:
     - to:
       - operation:
           hosts: ["test.com"]
           ports: ["9080"]

2. Aplique la directiva:

   kubectl apply -f productpage-viewer.yaml

3. Pruebe el acceso.

   Solicitud con Host: test.com:

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test.com"

   Salida:

   RBAC: access denied%

   Solicitud con Host: test1.com:

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test1.com" -I

   Salida:

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Solo se deniega el host test.com. Los demás valores de host pasan con normalidad.

4. Limpieza:

   kubectl delete authorizationpolicy productpage-viewer

Ejemplo 5: Denegar un método HTTP específico en una ruta específica

Este ejemplo bloquea las solicitudes HEAD hacia la ruta /productpage. Se permiten las solicitudes GET a la misma ruta y las solicitudes HEAD a otras rutas.

1. Cree un archivo productpage-viewer.yaml:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-viewer
     namespace: default
   spec:
     selector:
       matchLabels:
         istio.io/gateway-name: bookinfo-productpage
     action: DENY
     rules:
     - to:
       - operation:
           methods: ["HEAD"]
           paths: ["/productpage"]

2. Aplique la directiva:

   kubectl apply -f productpage-viewer.yaml

3. Pruebe el acceso.

   Solicitud HEAD a /productpage:

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -I

   Salida:

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Tue, 15 Aug 2023 03:59:37 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 0

   Solicitud GET a /productpage:

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -XGET -I

   Salida:

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Solicitud HEAD a /api/v1/products:

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/api/v1/products -I

   Salida:

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Solo se deniegan las solicitudes HEAD a /productpage. La directiva no afecta a otros métodos ni rutas.

4. Limpieza:

   kubectl delete authorizationpolicy productpage-viewer

Pasos siguientes

• Autenticación y autorización de capa 4 -- Configure directivas de autorización aplicadas por ztunnels en la capa 4

• Getting started -- Despliegue las aplicaciones de ejemplo utilizadas en estos casos