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á dirigido a los administradores de clústeres que necesitan aplicar medidas de seguridad obligatorias o establecer valores de referencia de confianza cero.

Este recurso se basa en una jerarquía de evaluación estricta que opera con una precedencia más alta que los recursos NetworkPolicy estándar con alcance de espacio de nombres. Puedes usar el recurso ClusterNetworkPolicy 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 del 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 del 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 admitidos

Las reglas de ClusterNetworkPolicy pueden coincidir con el tráfico según los protocolos TCP, UDP o SCTP. Puedes especificar los puertos de destino de las siguientes maneras:

  • Número de puerto específico: Usa el parámetro de configuración destinationPort.number para orientar un solo puerto (por ejemplo, 80).
  • Intervalo de puertos: Usa el parámetro de configuración destinationPort.range para segmentar por un intervalo de puertos (por ejemplo, del 8000 al 9000).
  • Puerto con nombre: Usa el parámetro de configuración destinationNamedPort para segmentar por 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 que coincide. 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 aplican en cascada a NetworkPolicy y, luego, a Baseline.
  • Prioridad de CNP: Dentro de un nivel, las políticas se evalúan según su prioridad numérica explícita.
  • Orden de las reglas de CNP: Dentro de una misma política, las reglas se procesan de arriba hacia abajo, como una lista de control de acceso (LCA).

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

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

  1. Nivel de administrador: Primero, el tráfico se evalúa según las reglas de ClusterNetworkPolicy en el nivel de Admin. Si hay una coincidencia de permiso o denegación, la evaluación se detiene. Si no hay coincidencia 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 Básico.
  3. Nivel de referencia: El tráfico se evalúa según las reglas de ClusterNetworkPolicy en el nivel de referencia. Si hay una coincidencia de Permitir o Rechazar, la evaluación se detiene. Si no hay coincidencias, el tráfico continúa con el comportamiento predeterminado.
  4. Comportamiento predeterminado de GKE: Si no coincide ninguna política 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 con un paquete, cada regla activa una de tres acciones estrictas:

  • Rechazar: Bloquea el tráfico de inmediato.
  • Aceptar: Permite el tráfico. Ambas acciones interrumpen instantáneamente la canalización, que ignora todas las políticas restantes.
  • Pass: Transfiere el control al siguiente nivel, lo que permite que los ingenieros de plataforma deleguen decisiones de tráfico específicas a políticas estándar a nivel de 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 rechazo predeterminado ayuda a garantizar que todo el tráfico hacia o desde el espacio de nombres sensible se bloquee a nivel administrativo. Esta política actúa como una referencia protectora que las reglas a nivel del espacio de nombres no pueden omitir accidentalmente.

  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 permisos global

Una política de permiso global puede ayudar a garantizar que todos los Pods puedan acceder al servicio de DNS del clúster, independientemente de las políticas de red creadas por los desarrolladores.

  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 el tráfico a las 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 de espacios 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 para desarrolladores 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 Deployment al 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 la 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 especificando 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 de precedencia

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, y los números más bajos indican una precedencia más alta. 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 que te permitan diagnosticar y resolver errores de políticas, usa los siguientes comandos.

Enumera todas las políticas de red del clúster:

kubectl get clusternetworkpolicies

Para describir una política específica y, así, inspeccionar su estado y nivel de evaluación, haz lo siguiente:

kubectl describe clusternetworkpolicy/<policy-name>

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

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

¿Qué sigue?