Utilizar el almacenamiento de registros de políticas de red

En esta página se explica cómo usar el registro de políticas de red en Google Kubernetes Engine (GKE). Las políticas de red de Kubernetes especifican el tráfico de red que pueden enviar y recibir los pods. El registro de políticas de red te permite registrar cuándo se permite o se deniega una conexión mediante una política de red. El registro de políticas de red puede ayudarte a solucionar problemas con las políticas de red.

Información general

Con el almacenamiento de registros de políticas de red, puedes hacer lo siguiente:

• Comprueba que las políticas de tu red funcionan correctamente.
• Descubre qué pods de tu clúster se comunican con Internet.
• Descubrir qué espacios de nombres se comunican entre sí.
• Reconocer un ataque de denegación de servicio.

Los registros de políticas de red se suben a Cloud Logging para almacenarlos, buscarlos, analizarlos y enviar alertas sobre ellos si Cloud Logging está habilitado. Cloud Logging está habilitado de forma predeterminada en los clústeres nuevos. Para obtener más información, consulta el artículo sobre cómo configurar el almacenamiento de registros y la monitorización de GKE.

Requisitos

• El registro de políticas de red solo está disponible en los clústeres que usan GKE Dataplane V2.
• Para registrar las políticas de red, se necesita la CLI de Google Cloud 303.0.0 o una versión posterior.
• El registro de políticas de red no se admite en grupos de nodos de Windows Server.

Precios

• No se aplican cargos por la generación de registros de políticas de red.

• Los registros también se pueden enrutar a Pub/Sub, Cloud Storage o BigQuery. Se pueden aplicar cargos por el uso de Pub/Sub, Cloud Storage o BigQuery. Para obtener más información, consulta el artículo Información general sobre el enrutamiento y el almacenamiento.

Configurar el registro de políticas de red

Para configurar los ajustes de registro de la política de red, edita el objeto NetworkLogging de tu clúster. GKE crea automáticamente un objeto NetworkLogging llamado default en los nuevos clústeres de Dataplane V2. Solo puede haber un objeto NetworkLogging por clúster y no se le puede cambiar el nombre.

Puede configurar el registro de las conexiones permitidas y el de las conexiones denegadas por separado. También puede habilitar el registro de forma selectiva para algunas políticas de red. A continuación, se muestra un ejemplo de la especificación NetworkLogging, con ajustes especificados para registrar todas las conexiones permitidas y denegadas:

kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: false
    deny:
      log: true
      delegate: false

Usa kubectl para editar la configuración:

kubectl edit networklogging default

Especificación NetworkLogging

La especificación del objeto NetworkLogging está en formato YAML. Este formato se describe en la siguiente tabla:

Acceder a los registros de políticas de red

Los registros de políticas de red se suben automáticamente a Cloud Logging. Puedes acceder a los registros a través del Explorador de registros o con la CLI de Google Cloud. También puedes enrutar los registros a un receptor.

gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
    resource.labels.location="CLUSTER_LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    logName="projects/PROJECT_NAME/logs/policy-action"'

Puedes añadir más condiciones para filtrar los resultados. Por ejemplo:

• Mostrar los registros de un periodo determinado:

  timestamp>="2020-06-22T06:30:51.128Z"
  timestamp<="2020-06-23T06:30:51.128Z"
  

• Mostrar los registros de las conexiones denegadas:

  jsonPayload.disposition="deny"
  

• Mostrar los registros de un despliegue llamado "redis":

  jsonPayload.dest.pod_name=~"redis"
  jsonPayload.dest.pod_namespace="default"
  

• Mostrar los registros de las conexiones externas al clúster:

  jsonPayload.dest.instance != ""
  

• Muestra los registros que coincidan con una determinada política de red. En este caso, "allow-frontend-to-db":

  jsonPayload.policies.name="allow-frontend-to-db"
  jsonPayload.policies.namespace="default"
  

Si usas un clúster estándar, también puedes encontrar los registros de la política de red generados en cada nodo del clúster localmente en /var/log/network/policy_action.log*. Se crea un nuevo archivo de registro numerado cuando el archivo de registro actual alcanza los 10 MB. Se almacenan hasta cinco archivos de registro anteriores.

Formato de registro de políticas de red

Los registros de los registros de la política de red están en formato JSON. Este formato se describe en la siguiente tabla:

Definición de conexión

En el caso de los protocolos orientados a la conexión, como TCP, se crea un registro por cada conexión permitida o denegada. En el caso de los protocolos como UDP e ICMP, que no están orientados a la conexión, los paquetes se agrupan en conexiones basadas en ventanas de tiempo.

Registros de políticas de conexiones denegadas

Los registros de conexiones denegadas no incluyen el campo policies porque la API de la política de red de Kubernetes no tiene políticas de denegación explícitas. Se deniega una conexión si un pod está cubierto por una o varias políticas de red, pero ninguna de ellas permite la conexión. Esto significa que ninguna política es responsable individualmente de una conexión bloqueada.

Agregación de registros de conexiones denegadas

Es habitual que un cliente vuelva a intentar una conexión que se ha denegado. Para evitar que se registren demasiados datos, las conexiones denegadas repetidas en un periodo de cinco segundos se agregan en un solo mensaje de registro mediante el campo count.

Las conexiones denegadas posteriores se agregan a un mensaje de registro anterior si el src_ip, dest_ip, dest_port, protocol, y el direction de la conexión coinciden con la primera conexión denegada. Ten en cuenta que el src_port de las conexiones posteriores no tiene por qué coincidir, ya que las conexiones reintentadas pueden proceder de un puerto diferente. El mensaje de registro agregado incluye el src_prt de la primera conexión denegada al principio del periodo de agregación.

Ejemplo de registros

La siguiente política de red de ejemplo llamada allow-green aplicada a test-service permite las conexiones a test-service desde un pod llamado client-green. De forma implícita, esta política deniega todo el tráfico de entrada a test-service, incluido el del pod client-red.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-green
    namespace: default
    annotations:
      policy.network.gke.io/enable-logging: "true"
  spec:
    podSelector:
      matchLabels:
        app: test-service
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: client-green
    policyTypes:
    - Ingress

En este diagrama se muestra el efecto de la política de allow-green en dos conexiones a test-service. La política allow-green permite la conexión desde client-green. Como no hay ninguna política que permita la conexión desde client-red, se deniega la conexión.

El registro de la conexión permitida de client-green tiene este aspecto:

{
   "connection":{
      "src_ip":"10.84.0.252",
      "dest_ip":"10.84.0.165",
      "src_port":52648,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "policies":[
      {
         "name":"allow-green",
         "namespace":"default"
      }
   ],
   "src":{
      "pod_name":"client-green-7b78d7c957-68mv4",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-green-7b78d7c957",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-16T03:10:37.993712906Z"
}

El registro de la conexión denegada de client-red tiene este aspecto:

{
   "connection":{
      "src_ip":"10.84.0.180",
      "dest_ip":"10.84.0.165",
      "src_port":39610,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"deny",
   "src":{
      "pod_name":"client-red-5689846f5b-b5ccx",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-red-5689846f5b",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":3,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-15T22:38:32.189649531Z"
}

Ten en cuenta que el registro de conexiones denegadas no incluye el campo policies. Esto se describe en la sección anterior, Registros de políticas de conexiones denegadas.

El registro de conexiones denegadas incluye un campo count para agregar conexiones denegadas.

Solucionar problemas con los registros de políticas de red

1. Comprueba si hay eventos de error en el objeto NetworkLogging:

   kubectl describe networklogging default
   

   Si la configuración de registro no es válida, no se aplicará y se notificará un error en la sección de eventos:

   Name:         default
   Namespace:
   Labels:       addonmanager.kubernetes.io/mode=EnsureExists
   Annotations:  API Version:  networking.gke.io/v1alpha1
   Kind:         NetworkLogging
   Metadata:
     Creation Timestamp:  2020-06-20T05:54:08Z
     Generation:          8
     Resource Version:    187864
     Self Link:           /apis/networking.gke.io/v1alpha1/networkloggings/default
     UID:                 0f1ddd6e-4193-4295-9172-baa6a52aa6e6
   Spec:
     Cluster:
       Allow:
         Delegate:  true
         Log:       false
       Deny:
         Delegate:  false
         Log:       false
   Events:
     Type     Reason                 Age                From                                                               Message
     ----     ------                 ----               ----                                                               -------
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-0t09  cluster allow log action is invalid: delegate cannot be true when log is false
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-80fx  cluster allow log action is invalid: delegate cannot be true when log is false
   

2. Para limitar la utilización de CPU dedicada al registro, un nodo puede registrar hasta 500 conexiones por segundo antes de empezar a descartar registros. Las políticas de red del nodo se siguen aplicando. Para ver si hay registros de políticas descartados, comprueba si se incrementa algún contador de errores:

   kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_logging
   

   Sustituye ANETD_POD_NAME por el nombre de un Pod de anetd. Comprueba cada nodo. anetd es el controlador de red de Dataplane V2.

Los registros sin nombre aparecen en los pods con políticas de denegación predeterminadas

Las comprobaciones de vivacidad, preparación e inicio requieren que el pod acepte las conexiones de entrada que realizan las comprobaciones desde kubelet. Para asegurarte de que estas comprobaciones funcionen correctamente, GKE permite automáticamente el tráfico de comprobación al pod seleccionado tal como se haya configurado para el pod, independientemente de las políticas de red que se hayan aplicado al pod. No puedes cambiar este comportamiento.

Los registros de las conexiones de sondeo son similares a los siguientes:

{
   "connection":{
      "src_ip":"10.88.1.1",
      "dest_ip":"10.88.1.4",
      "src_port":35848,
      "dest_port":15021,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "src":{
      "instance":"10.88.1.1"
   },
   "dest":{
      "pod_name":"testpod-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"testpod-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "policies": [
     {
       "name":""
     }
    ],
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2021-04-01T12:42:32.1898720941Z"
}

El registro tiene las siguientes características:

• El valor de policies.name está vacío porque no hay ninguna política de red asociada que permita la conexión.
• El valor de connection.src_ip no corresponde a ningún pod ni nodo.

Siguientes pasos

• Consulta cómo ver y analizar registros con Cloud Logging.
• Implementa métodos habituales para restringir el tráfico mediante políticas de red.