Use Layer 4 authorization policies - - Centro de documentación de Alibaba Cloud

El modelo de configuración de autenticación y autorización en el modo Ambient Mesh difiere del modo Sidecar original debido a la separación entre la capa 4 y la capa 7. Este tema describe cómo utilizar las directivas de autorización de capa 4 en instancias de Service Mesh (ASM) v1.18.

Requisitos previos

Se ha desplegado una puerta de enlace de entrada y las aplicaciones relacionadas, y se han verificado las funciones básicas. Para obtener más información, consulte Requisitos previos y Paso 1 en Getting started.

Límites

Los siguientes límites aplican a las directivas de autorización en ztunnels:
- El campo action no puede establecerse en CUSTOM, lo que indica que los ztunnels no admiten servicios de autorización personalizados.
- Los campos requestPrincipals y remoteIpBlocks no son compatibles dentro del campo source.
- En el campo operation solo se admite el campo ports.
Si no hay ningún proxy waypoint desplegado, los ztunnels aplican las directivas de autorización. En este caso, es necesario vincular dichas directivas a las cargas de trabajo especificadas.
Un ztunnel funciona como proxy de capa 4. Si configura una directiva de autorización con reglas de capa 7 en un ztunnel, únicamente surtirán efecto las reglas de capa 4.

Ejemplo 1: Permitir que solo la puerta de enlace y la aplicación sleep accedan al servicio productpage

Este ejemplo verifica si los ztunnels ejecutan correctamente la autorización basada en principals. Para obtener más información, consulte Getting started.

Una vez finalizada la prueba, ejecute el siguiente comando para eliminar la directiva de autorización:

kubectl delete authorizationpolicy productpage-viewer

Ejemplo 2: Prohibir el acceso al puerto 9080 del servicio productpage

Este ejemplo verifica principalmente si los ztunnels ejecutan correctamente la autorización según los puertos de destino.

Utilice el siguiente contenido para crear un archivo productpage-viewer.yaml:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - to:
   - operation:
       ports:
       - "9080"

Use kubectl para conectarse a la instancia de ASM con base en la información del archivo kubeconfig y, a continuación, ejecute el siguiente comando para crear la directiva de autorización:
```
kubectl apply -f productpage-viewer.yaml
```
Compruebe si la directiva de autorización surte efecto.
1. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Salida esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Salida esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Salida esperada:
```
command terminated with exit code 56
```
4. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Salida esperada:
```
command terminated with exit code 56
```
  La salida indica que ningún pod puede acceder al puerto 9080 del servicio productpage.
  
  En las dos primeras pruebas, las respuestas a las solicitudes de acceso al servicio productpage a través de la puerta de enlace reportan el error upstream connect error or disconnect/reset before headers. reset reason: connection termination%. Este error proviene de la puerta de enlace de entrada. Si dicha puerta no logra acceder al servicio productpage (porque este no permite el acceso a su puerto 9080), se genera un error HTTP 503.
  
  Las respuestas de las últimas dos pruebas muestran command terminated with exit code 56, mensaje devuelto por el comando curl. El comando curl intenta establecer una conexión directa con el servicio productpage, pero falla en el intento. Por ello no se reporta ningún error HTTP, a diferencia de lo que ocurre al acceder directamente mediante la puerta de enlace.
Ejecute el siguiente comando para eliminar la directiva de autorización:
```
kubectl delete authorizationpolicy productpage-viewer
```

Ejemplo 3: Prohibir que la dirección IP del pod sleep acceda al servicio productpage

Este ejemplo verifica principalmente si los ztunnels ejecutan correctamente la autorización según las direcciones IP de origen.

Ejecute el siguiente comando para consultar la dirección IP del pod sleep:

kubectl get pod -o wide | grep sleep

Salida esperada:

notsleep-5fb85fb789-z****         1/1     Running   0          48m   10.0.67.92   cn-hangzhou.10.0.67.41   <none>           <none>
sleep-bc9998558-z****             1/1     Running   0          48m   10.0.67.91   cn-hangzhou.10.0.67.42   <none>           <none>

La salida esperada indica que la dirección IP del pod sleep en el entorno de prueba actual es 10.0.67.91. La dirección IP real del pod puede variar en cada entorno.

Utilice el siguiente contenido para crear un archivo productpage-viewer.yaml que prohíba a las solicitudes provenientes de la dirección IP del pod sleep acceder al servicio productpage.

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

Use kubectl para conectarse a la instancia de ASM con base en la información del archivo kubeconfig y, a continuación, ejecute el siguiente comando para crear la directiva de autorización:
```
kubectl apply -f productpage-viewer.yaml
```
Compruebe si la directiva de autorización surte efecto.
1. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Salida esperada:
```
<title>Simple Bookstore App</title>
```
2. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Salida esperada:
```
<title>Simple Bookstore App</title>
```
3. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Salida esperada:
```
command terminated with exit code 56
```
4. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Salida esperada:
```
<title>Simple Bookstore App</title>
```
  La salida indica que, al desplegar únicamente ztunnels sin un proxy waypoint, no es posible impedir que el pod sleep acceda al servicio productpage a través de la puerta de enlace. Esto se debe a que el campo remoteIpBlocks de la directiva de autorización depende del encabezado X-Forwarded-For de la solicitud, mientras que el ztunnel opera como proxy de capa 4.
Ejecute el siguiente comando para eliminar la directiva de autorización:
```
kubectl delete authorizationpolicy productpage-viewer
```

Ejemplo 4: Prohibir que los pods del namespace istio-system accedan al servicio productpage

Este ejemplo verifica principalmente si los ztunnels ejecutan correctamente la autorización según los namespaces de origen. Un namespace de origen es aquel desde el cual un pod inicia una solicitud.

Utilice el siguiente contenido para crear un archivo productpage-viewer.yaml que prohíba a los pods del namespace istio-system acceder al servicio productpage:

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

Use kubectl para conectarse a la instancia de ASM con base en la información del archivo kubeconfig y, a continuación, ejecute el siguiente comando para crear la directiva de autorización:
```
kubectl apply -f productpage-viewer.yaml
```
Compruebe si la directiva de autorización surte efecto.
1. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Salida esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Salida esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Salida esperada:
```
<title>Simple Bookstore App</title>
```
4. Ejecute el siguiente comando para realizar una prueba de acceso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Salida esperada:
```
<title>Simple Bookstore App</title>
```
  La puerta de enlace de entrada está desplegada en el namespace istio-system. La salida indica que, tras crear la directiva de autorización, las aplicaciones sleep y notsleep no pueden acceder al servicio productpage a través de la puerta de enlace, aunque sí logran acceder directamente al servicio.
Ejecute el siguiente comando para eliminar la directiva de autorización:
```
kubectl delete authorizationpolicy productpage-viewer
```