Configura políticas de auditoría para tus servicios

Una política de auditoría te permite auditar el acceso a los datos para tus servicios en Anthos Service Mesh. La auditoría de tus servicios te ayuda a responder las preguntas “¿Quién hizo qué?", "¿cuándo?" y, tal vez, "¿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. Puedes ver los registros de auditoría en el Explorador de registros de Cloud Logging en la consola de Google Cloud. En esta guía, se explica cómo instalar Anthos Service Mesh en GKE en Google Cloud para que puedas usar una política de auditoría.

Una política de auditoría extiende AuthorizationPolicy mediante la adición de una acción AUDIT. Solo se aplica en el permiso de su política de destino (que puede ser una carga de trabajo, un espacio de nombres o toda la malla). Las políticas se unen con 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.

Esta es una política de auditoría de ejemplo 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 la puerta de enlace de entrada.
El contenido de auditoría no se puede configurar.
Actualmente, los registros de auditoría de Anthos Service Mesh tienen la misma propiedad de confiabilidad 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 para la carga de trabajo, si no se pueden conservar.

Personaliza la instalación de Anthos Service Mesh

Para usar una política de auditoría, personaliza la instalación de Anthos Service Mesh:

Sigue los pasos en Instala Anthos Service Mesh en GKE para usar la secuencia de comandos que proporciona Google a fin de instalar Anthos Service Mesh. Cuando ejecutes la secuencia de comandos, incluye la siguiente opción:

--option audit-authorizationpolicy

Por ejemplo:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH  \
  --enable_all \
  --option audit-authorizationpolicy

Completa la instalación de Anthos Service Mesh para habilitar la inserción automática del proxy de sidecar en tus cargas de trabajo. Para obtener más información, consulta Implementa y vuelve a implementar cargas de trabajo.

Usa el registro de auditoría

En esta sección, se usa la muestra de Bookinfo para demostrar cómo usar el registro de auditoría.

Implementa la aplicación de muestra de Bookinfo en el espacio de nombres predeterminado.
Obtén la dirección IP externa de la puerta de enlace de entrada y envía solicitudes a la aplicación de ejemplo para generar algo de tráfico.
En la consola de Google Cloud, ve al menú de navegación y selecciona Logging > Explorador de registros:

Ir al Explorador de registros.
Selecciona un proyecto de Google Cloud.
Debido a que aún no implementaste una política de auditoría, no habrá registros de auditoría. Ten en cuenta que el registro de auditoría es diferente del registro de acceso. Para ver los registros de acceso stackdriver, ingresa la siguiente consulta en el campo Compilador de consultas y haz clic en Ejecutar consulta:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
```
Para obtener más información sobre el uso del Explorador de registros, consulta Descripción general del Explorador de registros.

Configura la política de auditoría y verifica los registros de auditoría

En esta sección, se proporcionan varias opciones para auditar la aplicación Bookinfo. Después de implementar la política de auditoría, puedes enviar algunas solicitudes y, luego, verificar el registro de auditoría en el Explorador de registros.

Ingresa el siguiente comando para obtener credenciales de autenticación a fin de interactuar con el clúster. En este comando, también se establece el contexto actual de kubectl en el clúster.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION
```
Nota: Para el clúster regional, reemplaza --region por --zone.

Aplica la siguiente política de auditoría para auditar solicitudes GET a la ruta de acceso /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, ingresa la siguiente consulta en el campo Compilador de consultas y haz clic en Ejecutar consulta:
```
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
```
La consulta muestra registros similares a los siguientes:
Aplica la siguiente política para auditar solicitudes al servicio bookinfo-ratings. Las políticas de auditoría son aditivas. Después de aplicar la siguiente política, verás registros de auditoría para las solicitudes de 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, antes de que tenga efecto.
Envía 10 o más solicitudes a Bookinfo para asegurarte de que llegas el servicio de calificaciones y, luego, revisa el registro de auditoría en el Explorador de registros. El registro de auditoría es similar al que se muestra a continuación:

Aplica la siguiente política para auditar todos los servicios en el 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 algunas solicitudes más a Bookinfo y, luego, verifica el registro de auditoría en el Explorador de registros. El registro de auditoría ahora registra todas las solicitudes:
Si deseas restringir la política de auditoría de nuevo a ProductPage y Ratings, puedes borrar la política audit-all:
```
kubectl delete authorizationpolicy audit-all -n default
```

Soluciona problemas

Si no ves ningún registro de auditoría después de habilitar una política de auditoría, puedes verificar lo siguiente:

Asegúrate de que haya tráfico para el período especificado en el Explorador de registros. Si pruebas con Bookinfo, puedes enviar solicitudes ejecutando el siguiente comando varias veces:
```
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
```
Verifica si hay una AuthorizationPolicy en la puerta de enlace de entrada que bloquea las solicitudes al servicio auditado.
Verifica los registros de acceso de stackdriver con el siguiente filtro en el Explorador de registros para verificar si tus solicitudes alcanzaron la aplicación:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
```
Para asegurarte de que Stackdriver esté configurado y que el registro de auditoría esté habilitado, vuelca la configuración del estado de istiod actual. En 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 coincidan con las reglas de la política de auditoría, puedes verificar los registros de depuración del control de acceso según la función (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, luego, verifica los registros del Pod con el comando kubectl logs:
```
kubectl logs POD_NAME -n NAMESPACE -c istio-proxy
```

¿Qué sigue?

Obtén información sobre la seguridad en Anthos Service Mesh