Configurar políticas de auditoría para tus servicios
Este tutorial solo admite la implementación del plano de control en el clúster.
Una política de auditoría te permite auditar el acceso a los datos de tus servicios en Cloud Service Mesh. Auditar tus servicios te ayuda a responder a las preguntas sobre quién hizo qué, cuándo y, posiblemente, por qué. Con una política de auditoría, puedes especificar cuándo se crea un registro de auditoría y el contenido de los registros. En esta guía se explica cómo instalar Cloud Service Mesh para poder usar una política de auditoría.
Como los registros de auditoría se consultan en el Explorador de registros de Cloud Logging de la Google Cloud consola, las políticas de auditoría solo se admiten en las siguientes plataformas:
- GKE en Google Cloud
- Google Distributed Cloud (solo software) para VMware
- Google Distributed Cloud (solo software) para bare metal
Una política de auditoría amplía AuthorizationPolicy añadiendo una acción AUDIT
. Solo tiene efecto en el ámbito de la política de destino (que puede ser una carga de trabajo, un espacio de nombres o toda la malla). Las políticas se aplican ORed
, es decir, se registra una solicitud si alguna política lo indica. Si no se aplica ninguna política de auditoría a una carga de trabajo determinada, no se genera ningún registro de auditoría para esa carga de trabajo.
A continuación, se muestra un ejemplo de política de auditoría para auditar todo el acceso de ESCRITURA a la ruta /user/profile/*
en myapi
:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: ns1
name: anyname
spec:
selector:
matchLabels:
app: myapi
action: AUDIT
rules:
- to:
- operation:
methods: ["POST", "UPDATE", "DELETE"]
paths: ["/user/profile/*"]
Limitaciones
- No hay ningún registro de auditoría en el ingress-gateway.
- El contenido de la auditoría no se puede configurar.
- Actualmente, los registros de auditoría de Cloud Service Mesh tienen la misma propiedad de fiabilidad que los registros de acceso normales. Por ejemplo, si se reinicia un pod de carga de trabajo, se pueden perder algunos registros de auditoría de la carga de trabajo si no se conservan.
Antes de empezar
Sigue los pasos que se indican en Instalar herramientas dependientes y validar el clúster para:- Instalar las herramientas necesarias
- Descargar
asmcli
- Conceder permisos de administrador de clústeres
- Validar el proyecto y el clúster
Preparar la configuración de la pasarela
Cloud Service Mesh te ofrece la opción de desplegar y gestionar gateways como parte de tu malla de servicios. Una pasarela describe un balanceador de carga que opera en el perímetro de la malla y recibe conexiones HTTP o TCP entrantes o salientes. Las pasarelas son proxies de Envoy que te ofrecen un control pormenorizado del tráfico que entra y sale de la malla.
asmcli
no instala istio-ingressgateway
. Te recomendamos que
despliegues y gestiones el plano de control y las pasarelas por separado. Para obtener más información, consulta el artículo sobre cómo instalar y actualizar gateways.
Personalizar la instalación de Cloud Service Mesh
Para usar una política de auditoría, personaliza la instalación de Cloud Service Mesh:
Descargas
Sigue los pasos que se indican en Instalar Cloud Service Mesh. Cuando ejecutes
asmcli install
, incluye la siguiente opción:--option audit-authorizationpolicy
Por ejemplo:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Asegúrate de especificar cualquier otro archivo de superposición que necesites para configurar Cloud Service Mesh.
Completa la instalación de Cloud Service Mesh para habilitar la inyección automática de proxy sidecar en tus cargas de trabajo. Consulta Desplegar y volver a desplegar cargas de trabajo.
Actualizaciones
Sigue los pasos que se indican en el artículo Actualizar Cloud Service Mesh. Cuando ejecutes
asmcli install
, incluye la siguiente opción:--option audit-authorizationpolicy
Por ejemplo:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Asegúrate de especificar cualquier otro archivo de superposición que necesites para configurar Cloud Service Mesh.
Completa la instalación de Cloud Service Mesh para habilitar la inyección automática de proxy sidecar en tus cargas de trabajo. Para obtener más información, consulta Cambiar al nuevo plano de control.
Usar el registro de auditoría
En esta sección se usa el ejemplo Bookinfo para mostrar cómo usar el registro de auditoría.
Despliega la aplicación de ejemplo Bookinfo en el espacio de nombres predeterminado.
Obtén la dirección IP externa de la pasarela de entrada y envía solicitudes a la aplicación de ejemplo para generar tráfico.
En la Google Cloud consola, ve al menú de navegación
y selecciona Registro > Explorador de registros:Selecciona un Google Cloud proyecto.
Como aún no has implementado ninguna política de auditoría, no habrá ningún registro de auditoría. Ten en cuenta que el registro de auditoría es diferente del registro de acceso. Para ver los registros de acceso de
stackdriver
, introduzca la siguiente consulta en el campo Generador de consultas y haga clic en Ejecutar consulta:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Para obtener más información sobre cómo usar el Explorador de registros, consulta el artículo Información general sobre el Explorador de registros.
Configurar la política de auditoría y consultar los registros de auditoría
En esta sección se ofrecen varias opciones para auditar la aplicación Bookinfo. Una vez que hayas implementado la política de auditoría, puedes enviar algunas solicitudes y, a continuación, consultar el registro de auditoría en el explorador de registros.
Introduce el siguiente comando para obtener las credenciales de autenticación para interactuar con el clúster. Este comando también define el contexto actual de
kubectl
en el clúster.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Aplica la siguiente política de auditoría para auditar las solicitudes de
GET
a la ruta/productpage
:kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-productpage" namespace: default spec: action: AUDIT rules: - to: - operation: methods: ["GET"] paths: ["/productpage"] EOF
Envía algunas solicitudes a Bookinfo.
En el Explorador de registros, introduce la siguiente consulta en el campo Generador de consultas y haz clic en Ejecutar consulta:
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
La consulta devuelve registros similares a los siguientes:
Aplica la siguiente política para auditar las solicitudes al servicio
bookinfo-ratings
. Las políticas de auditoría son acumulativas. Después de aplicar la siguiente política, verá registros de auditoría de las solicitudes a ProductPage y Ratings.kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-ratings" namespace: default spec: action: AUDIT rules: - from: - source: principals: ["cluster.local/ns/default/sa/bookinfo-ratings"] to: - operation: methods: ["GET"] EOF
La nueva política de auditoría debe propagarse primero para que se aplique.
Envía 10 o más solicitudes a Bookinfo para asegurarte de que accedes al servicio de valoraciones y, a continuación, consulta el registro de auditoría en Explorador de registros. El registro de auditoría tiene un aspecto similar al siguiente:
Aplica la siguiente política de auditoría a todos los servicios del espacio de nombres predeterminado.
kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
Envía más solicitudes a Bookinfo y, a continuación, consulta el registro de auditoría en Explorador de registros. Ahora, el registro de auditoría registra todas las solicitudes:
Si quieres volver a restringir la política de auditoría a ProductPage y Ratings, puedes eliminar la política
audit-all
:kubectl delete authorizationpolicy audit-all -n default
Solución de problemas
Si no ves ningún registro de auditoría después de habilitar una política de auditoría, puedes comprobar lo siguiente:
Comprueba que haya tráfico en el periodo especificado en Explorador de registros. Si estás haciendo pruebas con Bookinfo, puedes enviar solicitudes ejecutando el siguiente comando varias veces:
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
Comprueba si hay un
AuthorizationPolicy
en la pasarela de entrada que bloquea las solicitudes al servicio auditado.Consulta los
stackdriver
registros de acceso con el siguiente filtro en el Explorador de registros para verificar si tus solicitudes han llegado a la aplicación:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Para asegurarte de que Stackdriver está configurado y de que el registro de auditoría está habilitado, descarga la configuración del estado
istiod
actual. En laconfig_dump
, buscaenable_audit_log
y el nombre de tu política de auditoría.istioctl dashboard envoy POD_NAME.NAMESPACE
Para asegurarte de que tus solicitudes coinciden con las reglas de la política de auditoría, puedes consultar los registros de depuración del control de acceso basado en roles (RBAC). Activa el registro de depuración de RBAC con el siguiente comando:
kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
Envía algunas solicitudes y, a continuación, consulta los registros del pod con el comando
kubectl logs
:kubectl logs POD_NAME -n NAMESPACE -c istio-proxy