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

La 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 todo su tejido en la nube, se deben considerar varios factores durante la fase de arquitectura. Los hosts que se implementan como máquinas virtuales o sin sistema operativo son entidades familiares y su comportamiento es bien conocido desde una perspectiva de red y seguridad. Pero cuando se incluyen entornos de contenedores en la arquitectura general, es probable que se introduzcan 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 sobre la seguridad:

• ¿Cómo automatizo la implementación y la administración de la 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 usan para gestionar hosts sin sistema operativo y de máquinas virtuales?
• ¿Tendré que gestionar dos soluciones de microsegmentación distintas: una para los contenedores y otra para todo lo demás?

Los contenedores pueden comportar de manera extraña, desde una perspectiva de red y seguridad. Por ejemplo, las cápsulas pueden morir repentinamente y luego volver a voltear automáticamente, pero con una dirección IP diferente. Por otro lado, los servicios se implementan frente a los pods y actúan como un equilibrador de carga. Entonces, ¿para cuál de estas entidades debo definir un segmento? Un espacio de nombres puede abarcar estas entidades, entonces, ¿cómo lo segmento? ¿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í solos y tratar de resolver el "problema" de la microsegmentación con contenedores puede complicar aún más el asunto.

¿Cómo puede resolver el desafío de la microsegmentación para poder 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?

Afortunadamente, este es un problema solucionable. Déjame explicarte.

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

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

Por lo general, la respuesta a esta pregunta es sumar todos los hosts (sin sistema operativo y máquinas virtuales) y luego quizás duplicar o triplicar ese número para adaptar al crecimiento futuro esperado. Este número será un poco confuso ya que algunas aplicaciones se ejecutan en un clúster 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 escalado. Ese número total final se compara con los límites superiores de las cargas de trabajo gestionadas que puede admitir un proveedor de microsegmentación específico.

Los hosts sin sistema operativo no migran con frecuencia, por lo que son entidades bastante estáticas para definir segmentos. Las máquinas virtuales, por otro lado, pueden ser un poco impredecibles. Por ejemplo, se pueden voltear y reducir dinámicamente, migrar a través de segmentos de red y asignar varias direcciones IP a lo largo de sus ciclos de vida. Por lo tanto, el número total de anfitriones será un poco fluido. Dicho esto, normalmente puede estimar cuántas máquinas virtuales se espera que estén activas en su nube para alcanzar el número total de cargas de trabajo que deben gestionar y segmentar. A menudo, este número final estará en cientos o quizás en miles.  

Por lo tanto, al considerar los límites de escala superior que pueden admitir los diferentes proveedores de microsegmentación, estos números máximos a menudo parecerán "lo suficientemente buenos". Por ejemplo, si una nube tiene 1,000 cargas de trabajo ejecutar hoy y este número puede duplicar o incluso triplicar 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 gestionadas en el corto plazo. Los grandes números se consideran una preocupación remota.

Pero, ¿qué sucede cuando agregas contenedores a la imagen? Una carga de trabajo en contenedores es una instancia informática que se comporta de forma diferente a las máquinas virtuales y los hosts sin sistema operativo.

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 tiempo de ejecución del contenedor. Kubernetes recomienda implementar un máximo de 110 pods en un nodo determinado.

Por lo tanto, si tienes 100 nodos en tu nube que ejecutan Kubernetes y cada nodo ejecuta 110 pods, puedes terminar con 11,000 posibles instancias de procesamiento que deben definir de alguna manera como segmentos distintos. Si tiene 200 nodos, puede terminar con 22 000 instancias informáticas posibles. Vale la pena 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 contenedorizadas en toda su nube híbrida para estimar la cantidad esperada de cargas de trabajo gestionadas y los posibles segmentos. La lección aprendida es que el número máximo de cargas de trabajo gestionadas, que los diferentes proveedores de microsegmentación pueden admitir, 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 u OpenShift. Sin embargo, la mayoría de estas soluciones se centran específicamente en entornos de contenedores y no en cargas de trabajo no contenedorizadas 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 contenedorizadas, sin sistema operativo y máquinas virtuales, todas coexistiendo en la misma estructura de nube.

Si decide implementar una solución de segmentación para contenedores y una solución de segmentación diferente para máquinas virtuales y sin sistema operativo, el resultado serán dos conjuntos de herramientas distintos que no automatizan ni correlacionan eventos entre ellos. Este enfoque puede funcionar a pequeña escala, pero será difícil de poner en práctica y gestionar a medida que crezca la implementación. Debe evitar este enfoque aislado para la segmentación de la carga de trabajo. Las cargas de trabajo en contenedores deben gestionar de la misma manera en todo el tejido informático para crear una solución unificada para implementar y gestionar toda la segmentación de cargas de trabajo.

Illumio, por ejemplo, funciona en todas las cargas de trabajo, desde bare-metal hasta máquinas virtuales y contenedores. No hay disparidad de características entre las cargas de trabajo en contenedores y las cargas de trabajo no en contenedores, 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 hay un equilibrador de carga implementado en el perímetro del clúster, 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 clasificar como segmento? ¿Algunos de ellos o todos?

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 contenedores se ejecutarán en uno o más pods y, a menudo, estos pods deberán comunicar entre sí. Cada pod se puede definir como un segmento, pero el desafío es que Kubernetes puede voltear hacia abajo y luego voltear 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 dificulta el manejo de 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 activar y desactivar pods de forma dinámica, 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 un 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, con código que se ejecuta esencialmente de manera distribuida dentro de uno o más pods. Un espacio de nombres de contenedores es una abstracción en varios pods y servicios.

Illumio, por ejemplo, le permite definir un "perfil" en 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 esté en 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 clúster 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 todo el tejido de la nube.

Es por eso que debe cerciorar de que su proveedor de microsegmentación pueda gestionar más de 100,000 cargas de trabajo. Cuantos más entornos de contenedores se implementen en una estructura en la nube, más rápido se enfocarán estos números altos. 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 debe responder a los cambios en tiempo real.

Al emplear la instancia Kubelink de Illumio implementada en un clúster de contenedores, puede descubrir dinámicamente las cargas de trabajo que se implementan y retiran, habilitar 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 gestionan. La automatización y la orquestación son dos conceptos importantes en los contenedores, e Illumio implementa ambos para poner en práctica la gestión de la microsegmentación tanto dentro como fuera del entorno de contenedores.

La implementación de contenedores en la nube no debe significar sacrificar la capacidad de definir segmentos en torno a las cargas de trabajo, independientemente de cómo se implementen. Cerciorar de que su solución de segmentación continuará escalando a los mismos números altos que permiten las cargas de trabajo en contenedores, sin incurrir en obstáculos. Con Illumio Core, su compañía puede alcanzar la confianza cero en cada carga de trabajo de toda su estructura en la nube, independientemente de la escala.

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

Contáctenos hoy para saber cómo proteger sus contenedores con Illumio Zero Trust Segmentation.