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 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:

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:

Ir al 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
```
Nota: En el caso de los clústeres regionales, sustituye --region por --zone.

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 la config_dump, busca enable_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
```

Siguientes pasos

Información sobre la seguridad en Cloud Service Mesh