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. Esta página se describe cómo configurar la política de autorización de Cloud Service Mesh avanzada 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 admite 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 modo de ejecución de prueba, Cloud Service Mesh registra resultado de la aplicación de políticas Cloud Logging, pero no aplicar 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:
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.
La malla de servicios de Cloud almacena los resultados de la ejecución de prueba en Cloud Logging en las siguientes ubicaciones:
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" |
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" |
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 aplica la política.
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, reemplazaNAMESPACE
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:
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óndeny-path-headers
en el espacio de nombresfoo
. - 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 Accede a registros en Cloud Logging.