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

Esta página se ha traducido con Cloud Translation API.

Configurar funciones avanzadas de la política de autorización

La política de autorización de Cloud Service Mesh proporciona control de acceso a nivel de malla, espacio de nombres y carga de trabajo para tus cargas de trabajo en la malla. En esta página se describen los detalles sobre la configuración de las funciones avanzadas de la política de autorización de Cloud Service Mesh, como el modo de prueba y el registro de denegaciones. Las funciones descritas en esta página presuponen que conoces los conceptos fundamentales de la política de autorización que se describen en el resumen de la política de autorización.

Modo de prueba

La política de autorización de Cloud Service Mesh admite el modo de prueba, que te permite probar una política de autorización con tráfico de producción real sin aplicarla. El modo 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 que se interrumpa el tráfico de producción debido a una política de autorización incorrecta.

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

Ejemplo de modo de prueba

En el siguiente ejemplo, deny-path-headers, se muestra una política con la anotación dry-run definida como "true. La política de autorización deniega 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 modo de prueba, Cloud Service Mesh registra el resultado de la aplicación en Cloud Logging, pero no aplica la política. La solicitud siempre se permite y puedes consultar el Explorador de registros para decidir si la política de autorización funciona correctamente.

Detalles de los registros de prueba de funcionamiento

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

Ve a Explorador de registros. En la siguiente URL, sustituye PROJECT_ID por el ID de tu proyecto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
En el campo Generador de consultas, introduce una consulta para encontrar la política de autorización del modo de prueba. En la siguiente consulta, sustituye NAMESPACE por tu espacio de nombres:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Haz clic en Realizar una consulta.
Ajusta el periodo según sea necesario.

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

imagen

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

dry_run_result el resultado de la 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 prueba de funcionamiento.
dry_run_policy_rule el índice de la regla de la política de autorización que coincide y que toma la decisión de prueba de funcionamiento.

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

Política de autorización aplicada en modo de prueba	Resultado de la coincidencia	Resultado de la prueba	Cloud Logging
Solo política de `DENY`	Sin coincidencias	permitido	dry_run_result: "AuthzAllowed"
Solo política de `DENY`	Coincide	rechazada	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Solo política de `ALLOW`	Sin coincidencias	rechazada	dry_run_result: "AuthzDenied"
Solo política de `ALLOW`	Coincide	permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Política de `ALLOW` y `DENY`	Ninguna de las dos	rechazada	dry_run_result: "AuthzDenied"
	Solo la política `DENY`	rechazada	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Solo la política `ALLOW`	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 prueba, puedes inhabilitar el modo de prueba con uno de los siguientes métodos:

Quitar por completo la anotación de la prueba; o
Cambia el valor de la anotación dry-run a false.

Después de aplicar la política con el modo de prueba deshabilitado, Cloud Service Mesh la aplica.

Registro de denegaciones

La política de autorización deniega una solicitud si no está permitida por la política. En el caso de los protocolos HTTP (incluido gRPC), la solicitud se deniega con el código de estado 403. En el caso de los protocolos que no son HTTP, la conexión se termina directamente. El registro de tráfico de Cloud Logging incluye información adicional que resulta útil para entender por qué se deniega el tráfico. Por ejemplo, el registro indica cuántas solicitudes se deniegan por la política de autorización, lo que puede ayudarte a determinar qué regla de la política ha provocado la denegación en comparación con las denegaciones de la aplicación backend.

En el siguiente ejemplo, la anotación dry-run se ha definido como "false. Cuando apliques la política de autorización DENY, Cloud Service Mesh la aplicará.

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, puede ver los resultados de la política en el explorador de registros.DENY

Ve a Explorador de registros. En la siguiente URL, sustituye PROJECT_ID por el ID de tu proyecto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
En el campo Generador de consultas, introduce una consulta para encontrar la DENY política de autorización. En la siguiente consulta, sustituye NAMESPACE por tu espacio de nombres:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Haz clic en Realizar una consulta.
Ajusta el periodo según sea necesario.

En la siguiente captura de pantalla se muestra una entrada de registro en Explorador de registros después de que se haya aplicado la política de ejemplo deny-path-headers para hacerla cumplir. Puedes saber que la política de autorización ha sido la responsable del error 403 consultando las etiquetas:

imagen

El registro de tráfico de Explorador de registros incluye las siguientes etiquetas para la denegación de autorización:

response_details se asigna el valor "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 autorización DENY que provoca la denegación. El valor tiene el formato <Namespace>.<Name>. Por ejemplo, foo.deny-path-headers significa la 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 provoca la denegación. Por ejemplo, 0 significa la primera regla dentro de la política.

Siguientes pasos

Para ver una lista de todas las políticas de autorización de la malla de servicios, haz lo siguiente:

kubectl get authorizationpolicy --all-namespaces

Si hay una política de autorización vigente, puedes eliminarla 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.