Cómo diseñar e implementar una estrategia efectiva de microsegmentación de contenedores con Kubernetes

Microsegmentación a menudo se considera difícil de implementar a escala. Si su objetivo es crear un segmento, un límite de confianza, alrededor de cada carga de trabajo en toda su estructura de nube, se deben considerar varios factores durante la fase de arquitectura. Los hosts que se implementan como Bare-Metal o VM son entidades conocidas, y su comportamiento es bien conocido tanto desde una perspectiva de redes como de seguridad. Pero cuando incluye entornos de contenedores en la arquitectura general, es probable que introduzca algunas advertencias que normalmente no son significativas en las arquitecturas tradicionales de red y seguridad.

Cuando implemente contenedores en su nube híbrida general, eventualmente surgirán varias preguntas en torno a la seguridad:

• ¿Cómo automatizo la implementación y administración de microsegmentación en todas las cargas de trabajo de contenedores?
• ¿Cómo incluyo la política de segmentación de contenedores y la automatización en las herramientas de seguridad existentes que se utilizan para administrar hosts de hardware y VM?
• ¿Necesitaré administrar dos soluciones de microsegmentación distintas: una para contenedores y otra para todo lo demás?

Los contenedores pueden comportarse de manera extraña, desde una perspectiva de red y seguridad. Por ejemplo, los pods pueden morir repentinamente y luego hacer una copia de seguridad automática, pero con una dirección IP diferente. Por otro lado, los servicios se despliegan frente a los pods, y actúan como un balanceador de carga. Entonces, ¿para cuál de estas entidades debería definir un segmento? Un espacio de nombres puede abarcar estas entidades, entonces, ¿cómo puedo segmentar eso? ¿Y cuántas cargas de trabajo terminaré creando cuando todo esté completamente implementado?

Los contenedores pueden ser un tema difícil de entender por sí mismos y tratar de resolver el “problema” de microsegmentación con contenedores puede complicar fácilmente el asunto aún más.

¿Cómo puede resolver el desafío de la microsegmentación para que pueda introducir contenedores en su entorno existente sin romper la estrategia de seguridad actual o incurrir accidentalmente en algún obstáculo a medida que evoluciona la arquitectura?

Por suerte, esto es un problema solucionable. Déjame explicarte.

Consideraciones al agregar contenedores a una estrategia de microsegmentación existente

Un buen lugar para iniciar la conversación en torno a los contenedores y la microsegmentación es abordando la escala. Al diseñar una estrategia de segmentación para todas sus cargas de trabajo en toda su nube híbrida, el escalado siempre es una advertencia importante. ¿Qué tan grande crecerá el entorno en general?

Por lo general, la respuesta a esta pregunta es sumar todos sus hosts (Bare-Metal y VM) y luego quizás duplicar o triplicar ese número para adaptarse al crecimiento futuro esperado. Este número será un poco difuso ya que algunas aplicaciones se ejecutan en un cluster de hosts o máquinas virtuales; un host no siempre equivale a una carga de trabajo. Pero equiparar una carga de trabajo con un host es un punto de referencia útil para estimar los números de escala. Ese número total final se compara con los límites superiores de cargas de trabajo administradas que un proveedor de microsegmentación específico puede soportar.

Los hosts bare-metal no migran con frecuencia, por lo que son entidades bastante estáticas para definir segmentos. Las VM, por otro lado, pueden ser un poco impredecibles. Por ejemplo, se pueden girar dinámicamente hacia arriba y hacia abajo, migrar a través de segmentos de red y asignar múltiples direcciones IP a lo largo de sus ciclos de vida. Así que el número total de hosts será un poco fluido. Dicho esto, generalmente puede estimar cuántas VM se espera que estén activas en su nube para alcanzar el número total de cargas de trabajo que deben administrarse y segmentarse. A menudo este número final será de cientos o quizás pocos miles.

Por lo tanto, al considerar los límites de escala superior que pueden soportar diferentes proveedores de microsegmentación, estos números máximos a menudo parecerán “suficientemente buenos”. Por ejemplo, si una nube tiene 1,000 cargas de trabajo ejecutándose en la actualidad y este número puede duplicarse o incluso triplicarse en los próximos años, debería haber poca preocupación por alcanzar el límite superior de un proveedor específico de 20,000 cargas de trabajo administradas en el breve plazo. Los grandes números son vistos como una preocupación remota.

Pero, ¿qué sucede cuando añades contenedores a la imagen? Una carga de trabajo en contenedores es una instancia de computación que se comporta de manera diferente a las máquinas virtuales y los hosts bare-metal.

Por ejemplo, Kubernetes llama “nodo” al host subyacente, ya sea VM o bare-metal, que ejecuta contenedores. En cada nodo, se crean uno o más “pods”, y es dentro de cada pod donde se ejecutan las instancias reales de ejecución del contenedor. Kubernetes recomienda implementar un máximo de 110 pods en un nodo determinado.

Por lo tanto, si tiene 100 nodos en su nube ejecutando Kubernetes y cada nodo ejecuta 110 pods, puede terminar con 11,000 posibles instancias de computación que necesitan definirse de alguna manera como segmentos distintos. Si tiene 200 nodos, puede terminar con 22.000 instancias de computación posibles. Eso es necesario repetirlo: solo 200 nodos en su entorno de contenedores pueden dar como resultado 22.000 posibles segmentos de carga de trabajo.

Y esto es solo en su entorno de contenedores. Deberá agregar todas las cargas de trabajo no contenerizadas en toda su nube híbrida para estimar el número esperado de cargas de trabajo administradas y posibles segmentos. La lección aprendida es que el número máximo de cargas de trabajo administradas, que diferentes proveedores de microsegmentación pueden soportar, ya no parece tan inalcanzable.

Una solución para contenedores y no contenedores

Al considerar cómo segmentar un entorno de contenedores, hay varios proveedores que permiten la microsegmentación dentro y entre clústeres en Kubernetes o OpenShift. Sin embargo, la mayoría de estas soluciones se enfocan específicamente en entornos de contenedores y no en cargas de trabajo no contenerizadas en su nube híbrida. Y la realidad es que la mayoría de las redes que tienen cargas de trabajo de contenedores también tienen cargas de trabajo no contenerizadas, bare-metal y VM, todas coexistentes en la misma estructura de nube.

Si elige implementar una solución de segmentación para contenedores y una solución de segmentación diferente para máquinas virtuales y bare-metal, el resultado serán dos conjuntos de herramientas distintos que no automatizan ni correlacionan eventos entre ellos. Este enfoque puede funcionar en escalas pequeñas, pero será difícil de operacionalizar y administrar a medida que crece la implementación. Debe evitar este enfoque en silos para la segmentación de la carga de trabajo. Las cargas de trabajo en contenedores deben administrarse de la misma manera en toda la estructura informática a fin de crear una solución unificada para implementar y administrar todo segmentación de carga de trabajo.

Illumio, por ejemplo, funciona en todas las cargas de trabajo, desde Bare-Metal hasta VM y contenedores. No hay disparidad de características entre las cargas de trabajo en contenedores y las cargas de trabajo no contenerizadas, por lo que obtiene microsegmentación con visualización, automatización y administración de políticas para todas las cargas de trabajo.

¿Espacios de nombres, pods o servicios?

Kubernetes define tres entidades de contenedores principales en las que se puede controlar el tráfico de red de entrada y salida: un pod, un servicio o un espacio de nombres. (Nota: los nodos no se consideran un destino entre estas entidades, y un clúster se define como el límite más amplio alrededor de una colección de nodos). Además, a menudo se implementa un balanceador de carga en el perímetro del cluster, lo que da como resultado cuatro posibles entidades que se pueden segmentar. Al definir su arquitectura de microsegmentación, ¿cuál de estas entidades debe clasificarse como segmento? ¿Algunos de ellos o todos ellos?

Un pod es la entidad más pequeña a la que Kubernetes puede asignar una dirección IP. Las instancias de tiempo de ejecución de Containers se ejecutarán en uno o más pods y, a menudo, estos pods necesitarán comunicarse entre sí. Cada pod se puede definir como un segmento, pero el desafío es que Kubernetes puede girar hacia abajo y luego hacer girar pods, lo que, desde una perspectiva de red, significa que las direcciones IP de destino o de origen pueden desaparecer repentinamente. A los equipos de red y seguridad no les gusta cuando las entidades desaparecen repentinamente en la estructura general, lo que hace que sea difícil lidiar con la convergencia de rutas y las herramientas de seguridad.

Kubernetes puede implementar un servicio, que se implementa frente a un número determinado de pods, actuando casi como un equilibrador de carga para los pods detrás de él. Los servicios son mucho más estables, y aunque Kubernetes puede girar y girar hacia abajo dinámicamente los pods, rara vez lo hará con los servicios. Por lo tanto, se recomienda definir un servicio como un segmento, y no como pods individuales.

Es importante que pregunte a su proveedor de microsegmentación si puede definir un pod o un servicio como segmento, lo que permite dejar la elección a su administrador de seguridad.

Las aplicaciones implementadas en contenedores generalmente se implementarán como un espacio de nombres, y el código se ejecuta esencialmente de manera distribuida dentro de uno o más pods. Un espacio de nombres de contenedores es una abstracción en múltiples pods y servicios.

Illumio, por ejemplo, le permite definir un “perfil” contra un espacio de nombres y, a continuación, definir este perfil como un segmento. El resultado es que Illumio permite que la definición de un segmento sea contra un pod, un servicio o un espacio de nombres. Y, a diferencia de las herramientas de microsegmentación diseñadas específicamente para entornos en contenedores, Illumio también puede definir segmentos contra el host subyacente, los puntos de entrada/salida en el límite del cluster y las cargas de trabajo heredadas circundantes que necesitan acceder a los recursos dentro de los contenedores. Los segmentos no solo existen dentro de los contenedores, sino que existen en toda la estructura de la nube.

Esta es la razón por la que debe asegurarse de que su proveedor de microsegmentación pueda administrar más de 100.000 cargas de trabajo.. Cuantos más entornos de contenedores se implementen en una estructura de nube, más rápido se enfocan estos altos números. Y estos números consisten en cargas de trabajo que, en contenedores, a menudo son efímeras, con cargas de trabajo que cobran vida y desaparecen dinámicamente. Esto significa que su solución de microsegmentación necesita responder a los cambios en tiempo real.

Al usar la instancia Kubelink de Illumio implementada en un clúster de contenedores, puede descubrir dinámicamente las cargas de trabajo que se implementan y se dan de baja, habilite nuestro mapa de dependencia de aplicaciones, y aplicar herramientas para reaccionar en tiempo real a todos y cada uno de los cambios en las cargas de trabajo que se administran. La automatización y la orquestación son dos conceptos importantes en contenedores, e Illumino implementa ambos para operacionalizar la administración de microsegmentación tanto dentro como fuera del entorno de contenedores.

La implementación de contenedores en su nube no debería significar sacrificar la capacidad de definir segmentos alrededor de las cargas de trabajo, independientemente de cómo se implementen. Asegúrese de que su solución de segmentación continúe escalando a los mismos números altos que permiten las cargas de trabajo en contenedores, sin incurrir en ningún obstáculo. Con Illumio Core, su empresa puede alcanzar Cero Confianza alrededor de cada carga de trabajo en toda su estructura en la nube, independientemente de la escala.

¿Quieres más? Lea cómo Illumio Core puede proteger Kubernetes y OpenShift.

Póngase en contacto con nosotros hoy para aprender a asegurar sus contenedores con la Segmentación de Confianza Cero de Illumio.