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 Cloud 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. En esta guía, se explica cómo instalar Cloud Service Mesh para que puedas usar una política de auditoría.

Debido a que ves los registros de auditoría en el explorador de registros de Cloud Logging en la consola de Google Cloud, las políticas de auditoría solo se admiten en las siguientes plataformas:

  • GKE en Google Cloud
  • Google Distributed Cloud
  • Google Distributed Cloud

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 Cloud 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.

Antes de comenzar

Sigue los pasos que se indican en Instala herramientas dependientes y valida el clúster para hacer lo siguiente:

Prepara la configuración de la puerta de enlace

Cloud Service Mesh te brinda la opción de implementar y administrar puertas de enlace como parte de tu malla de servicios. Una puerta de enlace describe un balanceador de cargas que opera en el perímetro de la malla que recibe conexiones HTTP/TCP entrantes o salientes. Las puertas de enlace son proxies de Envoy que te brindan un control detallado sobre el tráfico que entra y sale de la malla.

asmcli no instala istio-ingressgateway. Te recomendamos que implementes y administres el plano de control y las puertas de enlace por separado. Para obtener más información, consulta Instala y actualiza puertas de enlace.

Personaliza la instalación de Anthos Service Mesh

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

Instalaciones

  1. Sigue los pasos en Instala 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.

  2. Completa la instalación de Cloud Service Mesh para habilitar la inserción automática del proxy de sidecar en tus cargas de trabajo. Consulta Implementa y vuelve a implementar las cargas de trabajo.

Actualizaciones

  1. Sigue los pasos en Actualiza 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.

  2. Completa la instalación de Cloud 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 Cambia al plano de control nuevo.

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.

  1. Implementa la aplicación de muestra de Bookinfo en el espacio de nombres predeterminado.

  2. 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.

  3. En la consola de Google Cloud, ve al menú de navegación y selecciona Logging > Explorador de registros:

    Ir al Explorador de registros.

  4. Selecciona un proyecto de Google Cloud.

  5. 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.

  1. 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
    
  2. 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
    
  3. Envía algunas solicitudes a Bookinfo.

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

    image

  5. 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.

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

    image

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

    image

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

  1. 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
    
  2. Verifica si hay una AuthorizationPolicy en la puerta de enlace de entrada que bloquea las solicitudes al servicio auditado.

  3. 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"
    

    image

  4. 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
    

    image imagen image

  5. 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'
    
  6. 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?