Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Configura las funciones avanzadas de la política de autorización

La política de autorización de Cloud Service Mesh proporciona malla, espacio de nombres y control de acceso a nivel de la carga de trabajo para las cargas de trabajo en la malla. En esta página, se describen detalles sobre cómo configurar las funciones avanzadas de la política de autorización de Cloud Service Mesh, incluidos el modo de ejecución de prueba y el registro de denegación. En las funciones que se describen en esta página, se supone que estás familiarizado con los conceptos fundamentales de la política de autorización que se describen en la Descripción general de la política de autorización.

Modo de ejecución de prueba

La política de autorización de Cloud Service Mesh es compatible con el modo de ejecución de prueba, que te permite probar una política de autorización con tráfico de producción real sin aplicarla. El modo de ejecución de prueba te permite comprender mejor el efecto de una política de autorización antes de aplicarla. Esto ayuda a reducir el riesgo de romper el tráfico de producción causado por una política de autorización incorrecta.

Usa la anotación "istio.io/dry-run": "true" en la política de autorización para cambiarla al modo de ejecución de prueba.

Ejemplo del modo de ejecución de prueba

En el siguiente ejemplo, deny-path-headers, se muestra una política con la anotación dry-run establecida en "true. La política de autorización rechaza las solicitudes a la ruta headers y permite todas las demás solicitudes.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Cuando aplicas una política de autorización en el modo de ejecución de prueba, Cloud Service Mesh registra el resultado de la aplicación en Cloud Logging, pero no aplica la política. La solicitud siempre está permitida y puedes verificar el Explorador de registros a fin de decidir si la política de autorización funciona o no como se espera.

Detalles de los registros de prueba de validación

Después de aplicar una política de autorización en el modo de ejecución de prueba, puedes ver los resultados de la política en el Explorador de registros.

Ir al Explorador de registros. En el siguiente comando, reemplaza PROJECT_ID por el ID de tu proyecto.
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
En el campo Compilador de consultas, ingresa una consulta para encontrar la política de autorización del modo de ejecución de prueba. En la siguiente consulta, reemplaza NAMESPACE por tu espacio de nombres:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Haga clic en Run query.
Ajusta el intervalo de tiempo según sea necesario.

En la siguiente captura de pantalla, se muestran las etiquetas de ejecución de prueba en el registro de tráfico en el Explorador de registros después de que se aplicó la política deny-path-headers de ejemplo:

imagen

El modo de ejecución de prueba admite las políticas de autorización ALLOW y DENY, además de los resultados de ejecución de prueba de Istio. Cloud Service Mesh almacena los resultados de la ejecución de prueba en Cloud Logging en las siguientes etiquetas:

dry_run_result: El resultado de la ejecución de prueba es “AuthzAllowed” o “AuthzDenied”.
dry_run_policy_name: El espacio de nombres y el nombre de la política de autorización coincidente que toma la decisión de ejecución de prueba.
dry_run_policy_rule: El índice de la regla de política de autorización coincidente que toma la decisión de ejecución de prueba.

En la siguiente tabla, se muestran los detalles que se registran para una política de autorización en modo de ejecución de prueba:

Política de autorización aplicada en el modo de ejecución de prueba	Resultado de la coincidencia	Resultado de la ejecución de prueba	Cloud Logging
Solo la política `DENY`	Sin coincidencias	Permitido	dry_run_result: "AuthzAllowed"
Solo la política `DENY`	Coincidente	rechazada	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Solo la política `ALLOW`	Sin coincidencias	rechazada	dry_run_result: "AuthzDenied"
Solo la política `ALLOW`	Coincidente	Permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Las políticas `ALLOW` y `DENY`	Sin coincidencias	rechazada	dry_run_result: "AuthzDenied"
	Solo la política `DENY` coincidente	rechazada	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Solo la política `ALLOW` coincidente	Permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Coincide con ambas políticas	rechazada	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

Cuando estés seguro del resultado de la ejecución de prueba, puedes inhabilitar el modo de ejecución de prueba mediante uno de los siguientes enfoques:

Quita la anotación de ejecución de prueba por completo; o
Cambia el valor de la anotación de ejecución de prueba a false.

Después de aplicar la política con el modo de ejecución de prueba inhabilitado, Cloud Service Mesh la aplica.

Registro de denegación

La política de autorización rechazará cualquier solicitud que no esté permitida en ella. En el caso de los protocolos HTTP (incluido gRPC), se rechaza la solicitud con el código de estado 403. Para protocolos que no sean HTTP, la conexión se finaliza directamente. El registro de tráfico de Cloud Logging incluye información adicional que es útil para comprender por qué se rechaza el tráfico. Por ejemplo, el registro indica cuántas solicitudes rechazó la política de autorización, lo que puede ayudarte a determinar qué regla provocó el rechazó y que rechazos se generaron de la aplicación de backend.

En el siguiente ejemplo, la anotación dry-run se establece en "false. Cuando aplica la política de autorización DENY, y Cloud Service Mesh la aplica.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Después de aplicar una política de autorización DENY, puedes ver los resultados de la política en el Explorador de registros.

Ir al Explorador de registros. En el siguiente comando, reemplaza PROJECT_ID por el ID de tu proyecto.
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
En el campo Compilador de consultas, ingresa una consulta para encontrar la política de autorización DENY. En la siguiente consulta, reemplaza NAMESPACE por tu espacio de nombres:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Haga clic en Run query.
Ajusta el intervalo de tiempo según sea necesario.

En la siguiente captura de pantalla, se muestra una entrada de registro en el Explorador de registros después de que se aplicó la política de ejemplo deny-path-headers para aplicar la política. Para saber que la política de autorización fue responsable del error 403, consulta las siguientes etiquetas:

imagen

En el registro de tráfico del explorador de registros, se incluyen las siguientes etiquetas para el rechazo de la autorización:

response_details: Se configura como "AuthzDenied" si el rechazo se debe a una política de autorización.
policy_name: Contiene el espacio de nombres y el nombre de la política de DENY de autorización que causa el rechazo. El valor está en el formato de <Namespace>.<Name>, por ejemplo, foo.deny-path-headers representa una política de autorización deny-path-headers en el espacio de nombres foo.
policy_rule: Contiene el índice de la regla dentro de la política de autorización que causa el rechazo, por ejemplo, 0 significa la primera regla dentro de la política.

Próximos pasos

Para obtener una lista de todas las políticas de autorización en la malla de servicios, ejecuta el siguiente comando:

kubectl get authorizationpolicy --all-namespaces

Si hay una política de autorización vigente, puedes borrarla con kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Para obtener más información sobre cómo obtener el registro de tráfico, consulta Registros de acceso.