Configura políticas de red del clúster

ClusterNetworkPolicy te permite definir posturas de seguridad globales de GKE en todo el clúster. Este documento está destinado a los administradores de clústeres que necesitan aplicar barreras de seguridad obligatorias o establecer líneas de base de confianza cero.

Este recurso se basa en una jerarquía de evaluación estricta que opera con una prioridad más alta que los recursos NetworkPolicy estándar con alcance de espacio de nombres. Puedes usar el ClusterNetworkPolicy recurso para implementar acciones explícitas de Deny, Accept o Pass. Estas acciones te permiten configurar políticas globales de permiso o denegación, delegar el control de tráfico a espacios de nombres específicos y restringir el tráfico de salida a bloques CIDR.

Antes de comenzar

Antes de configurar una política de red de clúster, asegúrate de cumplir con los siguientes requisitos:

  1. Asegúrate de que tu clúster de GKE ejecute la versión 1.36.0-gke.4447000 o posterior.
  2. Asegúrate de que tu clúster use GKE Dataplane V2.

Protocolos y puertos compatibles

Las reglas de ClusterNetworkPolicy pueden hacer coincidir el tráfico en función de los protocolos TCP, UDP o SCTP. Puedes especificar puertos de destino de las siguientes maneras:

  • Número de puerto específico: usa la configuración destinationPort.number para segmentar un solo puerto (por ejemplo, 80).
  • Rango de puertos: Usa la configuración destinationPort.range para segmentar un rango de puertos (por ejemplo, 8000 a 9000).
  • Puerto con nombre: Usa la configuración destinationNamedPort para segmentar un nombre simbólico definido en una especificación de Pod.

Jerarquía de evaluación de políticas

A diferencia de las NetworkPolicies estándar y aditivas, una ClusterNetworkPolicy (CNP) se basa en una jerarquía de evaluación estricta en la que gana la primera regla coincidente. El tráfico fluye de forma secuencial a través de una canalización de tres capas:

  • El nivel: Las reglas de administrador se ejecutan primero y se transfieren en cascada a NetworkPolicy, luego, a Baseline.
  • Prioridad de CNP: Dentro de un nivel, las políticas se evalúan en función de su prioridad numérica explícita.
  • Orden de reglas de CNP: Dentro de una sola política, las reglas se procesan de arriba abajo como una lista de control de acceso (LCA).

Diagrama que muestra la jerarquía de evaluación de la política de red de GKE

En el diagrama anterior, se ilustra el flujo de decisiones de la jerarquía de evaluación de CNP:

  1. Nivel de administrador: Primero, el tráfico se evalúa en función de las reglas de ClusterNetworkPolicy en el nivel Admin. Si hay una coincidencia de permiso o denegación, se detiene la evaluación. Si no hay coincidencias o una acción de aprobación, el tráfico pasa al nivel NetworkPolicy.
  2. Nivel de NetworkPolicy: El tráfico se evalúa en función de las políticas estándar del espacio de nombres. Si hay una coincidencia, se permite el tráfico. Si no hay coincidencias, el tráfico pasa al nivel de Baseline.
  3. Nivel de Baseline: El tráfico se evalúa en función de las ClusterNetworkPolicy reglas en el nivel de Baseline. Si hay una coincidencia de permiso o denegación, se detiene la evaluación. Si no hay coincidencias, el tráfico pasa al comportamiento predeterminado.
  4. Comportamiento predeterminado de GKE: Si no coinciden las políticas en ningún nivel, el tráfico se somete a un comportamiento de permiso implícito.

Acciones de veredicto: Permitir, Denegar y Pasar

Cuando coincide un paquete, cada regla activa una de las tres acciones estrictas:

  • Denegar: Bloquea el tráfico de inmediato.
  • Aceptar: Permite el tráfico. Ambas acciones cortocircuitan instantáneamente la canalización, que ignora todas las políticas restantes.
  • Pasar: Transfiere el control al siguiente nivel, lo que permite a los ingenieros de la plataforma delegar decisiones de tráfico específicas a políticas estándar a nivel del espacio de nombres sin renunciar al control administrativo general.

Configura una política de denegación global

Para aislar un espacio de nombres sensible de todo el tráfico interno del clúster, aplica una regla de denegación no anulable. Esta política de denegación predeterminada ayuda a garantizar que cualquier tráfico hacia o desde el espacio de nombres sensible se bloquee a nivel administrativo. Esta política actúa como una línea de base de protección que las reglas a nivel del espacio de nombres no pueden omitir de forma accidental.

  1. Guarda el siguiente manifiesto como global-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-deny-sensitive
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: sensitive-ns
  ingress:
  - action: Deny
    name: deny-all-ingress
    from:
    - namespaces:
        matchLabels: {}
  egress:
  - action: Deny
    name: deny-all-egress
    to:
    - namespaces:
        matchLabels: {}

  2. Aplica el manifiesto al clúster:

    kubectl apply -f global-deny.yaml

Configura una política de permiso global

Una política de permiso global puede ayudar a garantizar que todos los pods puedan comunicarse con el servicio DNS del clúster, independientemente de las políticas de red creadas por el desarrollador.

  1. Guarda el siguiente manifiesto como global-allow-dns.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-kube-dns-admin
spec:
  tier: Admin
  priority: 20
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    protocols:
    - udp:
        destinationPort:
          number: 53
    - tcp:
        destinationPort:
          number: 53

  2. Aplica el manifiesto al clúster:

    kubectl apply -f global-allow-dns.yaml

Delega tráfico a políticas de espacio de nombres

Delega patrones de tráfico específicos a objetos NetworkPolicy estándar con alcance de espacio de nombres.

  1. Guarda el siguiente manifiesto como delegate-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: delegate-to-netpol
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  egress:
  - action: Pass
    name: delegate-web-traffic
    to:
    - namespaces:
        matchLabels:
          app: web-backend
    protocols:
    - tcp:
        destinationPort:
          number: 8080

  2. Aplica el manifiesto al clúster:

    kubectl apply -f delegate-policy.yaml

  3. Para permitir el tráfico delegado dentro del espacio de nombres de destino, guarda el siguiente manifiesto NetworkPolicy estándar como allow-web-backend.yaml :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-backend
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      app: web-backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

  4. Aplica el manifiesto NetworkPolicy estándar a tu clúster:

    kubectl apply -f allow-web-backend.yaml

Configura barreras de seguridad de referencia

Establece una postura de seguridad predeterminada de GKE que los administradores del espacio de nombres puedan anular con políticas de red estándar.

  1. Guarda el siguiente manifiesto de referencia como baseline-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: default-deny-baseline
spec:
  tier: Baseline
  priority: 100
  subject:
    namespaces: {}
  ingress:
  - action: Deny
    name: baseline-deny-all
    from:
    - namespaces: {}

  2. Aplica el manifiesto de referencia a tu clúster:

    kubectl apply -f baseline-deny.yaml

  3. Guarda el siguiente manifiesto de anulación del desarrollador como developer-allow.yaml:

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-access
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

  4. Aplica el manifiesto de anulación a tu clúster:

    kubectl apply -f developer-allow.yaml

Configura políticas con puertos con nombre

Para abstraer los números de puerto de tus políticas de seguridad, haz referencia a los puertos con nombre definidos en las especificaciones de tu pod.

  1. Guarda el siguiente manifiesto de implementación como app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
spec:
  template:
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - name: http-web
          containerPort: 8080

  2. Aplica el manifiesto de implementación a tu clúster:

    kubectl apply -f app-deployment.yaml

  3. Guarda el siguiente manifiesto de política como named-port-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-web-named-port
spec:
  tier: Admin
  priority: 40
  subject:
    namespaces: {}
  egress:
  - action: Accept
    to:
    - namespaces:
        matchLabels:
          app: my-webapp
    protocols:
    - tcp:
        destinationNamedPort: http-web

  4. Aplica el manifiesto de política a tu clúster:

    kubectl apply -f named-port-policy.yaml

Restringe la salida a bloques CIDR

Controla el acceso a recursos externos o intranets corporativas mediante la especificación de bloques CIDR.

  1. Guarda el siguiente manifiesto como cidr-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-egress-to-intranet
spec:
  tier: Admin
  priority: 60
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-intranet
    to:
    - networks:
      - 10.0.0.0/8
      - 192.168.0.0/16

  2. Aplica el manifiesto al clúster:

    kubectl apply -f cidr-policy.yaml

Configura la prioridad

Para controlar el orden de evaluación cuando se aplican varias políticas a los mismos pods, especifica una prioridad. Las prioridades varían de 0 a 1000, en las que los números más bajos indican una mayor prioridad. Un solo objeto ClusterNetworkPolicy puede contener un máximo de 100 reglas de entrada y 100 reglas de salida.

  1. Guarda el siguiente manifiesto como priority-policies.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-beta
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-beta-monitoring
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            team: beta
        podSelector:
          matchLabels:
            app: monitoring
  - action: Deny
    name: deny-all-other-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta
---
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-beta
spec:
  tier: Admin
  priority: 50
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-all-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta

  2. Aplica el manifiesto al clúster:

    kubectl apply -f priority-policies.yaml

Solucionar problemas

Para encontrar métodos para diagnosticar y resolver errores de política, usa los siguientes comandos.

Enumera todas las políticas de red de clústeres en tu clúster:

kubectl get clusternetworkpolicies

Describe una política específica para inspeccionar su estado y nivel de evaluación:

kubectl describe clusternetworkpolicy/<policy-name>

El campo status.conditions en el resultado proporciona información sobre si la política se reconcilió correctamente con la implementación de redes de tu clúster.

Para supervisar los flujos de tráfico y las decisiones de políticas, usa Observabilidad de GKE Dataplane V2.

¿Qué sigue?