Tips Tecnológicos

Lo que necesita saber sobre la política de red de Kubernetes

Con un número cada vez mayor de aplicaciones nativas de la nube que pasan a producción gracias a la adopción de Kubernetes, la seguridad es un punto de control importante que debe tener en cuenta al principio del proceso. Al diseñar una aplicación nativa de la nube, es muy importante incorporar una estrategia de seguridad por adelantado. De lo contrario, surgen problemas de seguridad persistentes que pueden causar retrasos en el proyecto y, en última instancia, costarle estrés y dinero innecesarios.

Durante años, la gente abandonó por fin la seguridad, hasta que su distribución estuvo a punto de entrar en producción. Esta práctica provoca retrasos en los resultados finales porque cada organización tiene estándares de seguridad que cumplir, los cuales son ignorados o no seguidos con muchos riesgos aceptados para lograr los resultados finales.

Comprender Kubernetes NetworkPolicy puede ser abrumador para las personas que recién comienzan a aprender los pormenores de la implementación de Kubernetes. Pero este es uno de los requisitos fundamentales que debe aprender antes de implementar una aplicación en su clúster de Kubernetes. Cuando aprenda Kubernetes y las plantillas de aplicaciones nativas de la nube, cree su eslogan "¡No deje atrás la seguridad!"

Índice

    El concepto de política de red.

    Política de red reemplaza los dispositivos de firewall en el contexto del centro de datos que conoce, como pods para instancias informáticas, complementos de red para enrutadores y conmutadores, y volúmenes para la red de área de almacenamiento (SAN).

    De forma predeterminada, Kubernetes NetworkPolicy permite esto vainas para recibir tráfico desde cualquier lugar. Si no está preocupado por la seguridad de sus pods, entonces podría estar bien. Pero si está ejecutando una carga de trabajo crítica, necesita proteger sus pods. La forma de controlar el flujo de tráfico dentro del clúster (incluido el tráfico entrante y saliente) es a través de NetworkPolicies.

    Para habilitar NetworkPolicy, un complementos de red que admite NetworkPolicy. De lo contrario, las reglas que ha aplicado se vuelven inútiles.

    Hay varios complementos de red. listado en Kubernetes.io:

    • Complemento CNI: únete al Interfaz de red de contenedores (CNI), diseñado para la interoperabilidad.
      • Kubernetes sigue el v0.4.0 publicación de la especificación CNI.
    • Complemento de Kubernetes: base de implementación cbr0 utilizando el bridge Y host-local Complemento CNI.

    Aplicar una política de red

    Para aplicar una política de red, necesita un clúster de Kubernetes en funcionamiento con un complemento de red que admita NetworkPolicy.

    Pero primero debe comprender cómo usar NetworkPolicy en el contexto de Kubernetes. La política de red de Kubernetes permite esto vainas para recibir tráfico desde cualquier lugar. Esto no es ideal. Para proteger los pods, debe comprender los puntos finales que los pods pueden comunicar dentro de la construcción de Kubernetes.

    1. Uso de la comunicación de pod a pod podSelector.
      - namespaceSelector:
          matchLabels:
            project: myproject
    2. Usar comunicación de espacio de nombres a espacio de nombres y comunicación de espacio de nombres a pod namespaceSelector y/o una combinación de podSelector Y namespaceSelector.
      - namespaceSelector:
          matchLabels:
            project: myproject
      - podSelector:
          matchLabels:
            role: frontend
    3. IP bloquea la comunicación para usar pods ipBlock para definir cual IP CIDR los bloques determinan el origen y el destino.
      - ipBlock:
              cidr: 172.17.0.0/16
              except:
              - 172.17.1.0/24

    Tenga en cuenta la diferencia entre los pods, el espacio de nombres y las políticas basadas en IP. Para NetworkPolicy basado en pod y espacio de nombres, utiliza selector para controlar el tráfico, mientras que para NetworkPolicy basado en IP, los controles se definen usando IP blocks (Rangos CIDR).

    En conjunto, una NetworkPolicy debería verse así:

    apiVersion: Redes.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: test-network-policy
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: backend
      policyTypes:
      - Ingress
      - Egress
      ingress:
      - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
            - 192.168.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend
        ports:
        - protocol: TCP
          port: 6379
      egress:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/24
        ports:
        - protocol: TCP
          port: 5978

    Refiriéndose a NetworkPolicy arriba, tenga en cuenta la spec sección. En esta sección, podSelector con etiqueta aplicación = servidor es el objetivo de nuestra NetworkPolicy. En resumen, NetworkPolicy protege la aplicación llamada back-end dentro de un espacio de nombres dado.

    Esta sección también tiene policyTypes definición. Este campo indica si la política especificada se aplica o no al tráfico que ingresa al pod seleccionado, al tráfico que sale de los pods seleccionados o a ambos.

    spec:
      podSelector:
        matchLabels:
          app: backend
      policyTypes:
      - Ingress
      - Egress

    Ahora, mira el ingress Y egress sección. Esta definición determina el control de NetworkPolicy.

    Primero, mira en el ingress from sección.

    NetworkPolicy en este caso permite la conexión del pod desde:

    • ipBlock
      • Permitir 172.17.0.0/16
      • Niega 192.168.1.0 / 24
    • namespaceSelector
      • myproject: permitir todos los pods de este espacio de nombres y con las mismas etiquetas proyecto = mi proyecto.
    • podSelector
      • frontend: permitir pods que coincidan con la etiqueta rol = interfaz
    ingress:
    - from:
      - ipBlock:
          cidr: 172.17.0.0/16
          except:
          - 192.168.1.0/24
      - namespaceSelector:
          matchLabels:
            project: myproject
      - podSelector:
          matchLabels:
            role: frontend

    Ahora, examina el egress to sección. Esto hace que el pod se conecte a:

    • ipBlock
      • 10.0.0.0/24: Se permite la conexión a este CIDR
      • Puertos: Permitir conexión vía TCP y puerto 5978
    egress:
    - to:
      - ipBlock:
          cidr: 10.0.0.0/24
      ports:
      - protocol: TCP
        port: 5978

    Limitaciones de NetworkPolicy

    NetworkPolicy por sí solo no puede proteger completamente sus clústeres de Kubernetes. Los componentes del sistema operativo o las tecnologías de capa 7 se pueden utilizar para superar las limitaciones conocidas. Recuerde que NetworkPolicy solo puede abordar la seguridad para la dirección IP y la capa de puerto: capa 3 o 4 de interconexión de sistemas abiertos (OSI).

    Para cumplir con los requisitos de seguridad que NetworkPolicy no puede manejar, se deben usar otras soluciones de seguridad. Aquí están algunas casos de uso que necesita saber dónde NetworkPolicy necesita ser impulsado por otras tecnologías.

    Resumen

    Comprender Kubernetes NetworkPolicy es importante porque es una forma de cumplir (pero no anular) la función de firewall que normalmente usa en la configuración de un centro de datos, pero para Kubernetes. Piense en esto como el primer nivel de seguridad para su contenedor, sabiendo que NetworkPolicy por sí solo no es una solución de seguridad total.

    NetworkPolicy aplica seguridad al pod y al espacio de nombres mediante selectores y etiquetas. Además, NetworkPolicy también puede aplicar la seguridad a través de rangos de IP.

    Tener una comprensión sólida de NetworkPolicy es una habilidad importante para la adopción segura de la contenedorización en el contexto de Kubernetes.

    Visitas: 7

    Artículos de interés

    Subir