Como projetar e implementar uma estratégia eficaz de microssegmentação de contêineres com o Kubernetes

Microsegmentação muitas vezes é visto como um desafio de implementar em grande escala. Se sua meta é criar um segmento — um limite de confiança — em torno de cada carga de trabalho em toda a sua estrutura de nuvem, vários fatores devem ser considerados durante a fase de arquitetura. Os hosts implantados como bare-metal ou VMs são entidades familiares e seu comportamento é bem conhecido do ponto de vista de rede e segurança. Mas quando você inclui ambientes de contêiner na arquitetura geral, provavelmente introduzirá algumas ressalvas que normalmente não são significativas nas arquiteturas tradicionais de rede e segurança.

Quando você implanta contêineres em sua nuvem híbrida geral, várias questões surgirão sobre segurança:

• Como faço para automatizar a implantação e o gerenciamento do microssegmentação em todas as cargas de trabalho de contêineres?
• Como incluo a política de segmentação de contêineres e a automação nas ferramentas de segurança existentes usadas para gerenciar hosts bare-metal e VM?
• Precisarei gerenciar duas soluções distintas de microssegmentação: uma para contêineres e outra para todo o resto?

Os contêineres podem se comportar de forma estranha, do ponto de vista da rede e da segurança. Por exemplo, os pods podem morrer repentinamente e depois serem reativados automaticamente, mas com um endereço IP diferente. Por outro lado, os serviços são implantados na frente dos pods e agem como um balanceador de carga. Então, para qual dessas entidades devo definir um segmento? Um namespace pode abranger essas entidades, então como faço para segmentar isso? E quantas cargas de trabalho eu acabarei criando quando tudo estiver totalmente implantado?

Os contêineres podem ser um tópico difícil de entender sozinhos e tentar resolver o “problema” da microssegmentação com contêineres pode facilmente complicar ainda mais o assunto.

Como você pode resolver o desafio da microssegmentação para poder introduzir contêineres em seu ambiente existente sem quebrar a estratégia de segurança atual ou acidentalmente incorrer em algum obstáculo à medida que a arquitetura evolui?

Felizmente, isso é um problema solucionável. Deixe-me explicar.

Considerações ao adicionar contêineres a uma estratégia de microssegmentação existente

Um bom lugar para começar a conversa sobre contêineres e microssegmentação é abordar a escala. Ao projetar uma estratégia de segmentação para todas as suas cargas de trabalho em toda a sua nuvem híbrida, a escalabilidade é sempre uma ressalva importante. Até que ponto o ambiente geral crescerá?

Geralmente, a resposta a essa pergunta é somar todos os seus hosts — bare-metal e VMs — e talvez dobrar ou triplicar esse número para acomodar o crescimento futuro esperado. Esse número será um pouco confuso, pois alguns aplicativos são executados em um cluster de hosts ou VMs; um host nem sempre é igual a uma carga de trabalho. Mas igualar uma carga de trabalho a um host é uma referência útil para estimar números de escala. Esse número total final é então comparado com os limites superiores de cargas de trabalho gerenciadas que um fornecedor específico de microssegmentação pode suportar.

Os hosts bare-metal não migram com frequência, então são entidades bastante estáticas para definir segmentos. As VMs, por outro lado, podem ser um pouco imprevisíveis. Por exemplo, eles podem ser ativados e desativados dinamicamente, migrados entre segmentos de rede e atribuídos a vários endereços IP em seus ciclos de vida. Portanto, o número total de hosts será um pouco fluido. Dito isso, geralmente você pode estimar quantas VMs devem estar ativas em sua nuvem para atingir o número total de cargas de trabalho que precisam ser gerenciadas e segmentadas. Freqüentemente, esse número final estará na casa das centenas ou talvez poucos milhares.

Portanto, ao considerar os limites superiores de escala que diferentes fornecedores de microssegmentação podem suportar, esses números máximos geralmente parecem “bons o suficiente”. Por exemplo, se uma nuvem tem 1.000 cargas de trabalho em execução hoje e esse número pode dobrar ou até triplicar nos próximos anos, não deve haver nenhuma preocupação em atingir o limite máximo máximo de 20.000 cargas de trabalho gerenciadas de um fornecedor específico em breve. Grandes números são vistos como uma preocupação remota.

Mas o que acontece quando você adiciona recipientes à imagem? Uma carga de trabalho em contêiner é uma instância de computação que se comporta de maneira diferente das VMs e dos hosts bare-metal.

Por exemplo, o Kubernetes chama o host subjacente, VM ou bare-metal, executando contêineres de “node”. Em cada nó, um ou mais “pods” são criados, e é dentro de cada pod que as instâncias reais de tempo de execução do contêiner estão sendo executadas. O Kubernetes recomenda que no máximo 110 pods sejam implantados em um determinado nó.

Portanto, se você tiver 100 nós em sua nuvem executando o Kubernetes e cada nó estiver executando 110 pods, você pode acabar com 11.000 instâncias de computação possíveis que precisam, de alguma forma, ser definidas como segmentos distintos. Se você tiver 200 nós, poderá acabar com 22.000 instâncias de computação possíveis. Vale a pena repetir: apenas 200 nós em seu ambiente de contêineres podem resultar em 22.000 segmentos de carga de trabalho possíveis.

E isso é apenas em seu ambiente de contêineres. Você precisará adicionar todas as cargas de trabalho não conteinerizadas em toda a sua nuvem híbrida para estimar o número esperado de cargas de trabalho gerenciadas e possíveis segmentos. A lição aprendida é que o número máximo de cargas de trabalho gerenciadas, que diferentes fornecedores de microssegmentação podem suportar, não parece mais tão inatingível.

Uma solução para contêineres e não contêineres

Ao considerar como segmentar um ambiente de contêiner, existem vários fornecedores que permitem a microssegmentação dentro e entre clusters no Kubernetes ou no OpenShift. No entanto, a maioria dessas soluções se concentra especificamente em ambientes de contêiner e não em cargas de trabalho não conteinerizadas em sua nuvem híbrida. E a realidade é que a maioria das redes que têm cargas de trabalho de contêineres também tem cargas de trabalho não conteinerizadas, bare-metal e VMs, todas coexistindo na mesma estrutura de nuvem.

Se você optar por implantar uma solução de segmentação para contêineres e uma solução de segmentação diferente para bare-metal e VMs, o resultado serão dois conjuntos de ferramentas distintos que não automatizam nem correlacionam eventos entre eles. Essa abordagem pode funcionar em pequenas escalas, mas se tornará difícil de operacionalizar e gerenciar à medida que a implantação cresce. Você deve evitar essa abordagem isolada para a segmentação da carga de trabalho. As cargas de trabalho em contêineres precisam ser gerenciadas da mesma forma em toda a estrutura computacional para criar uma solução unificada para implantar e gerenciar tudo segmentação da carga de trabalho.

O Illumio, por exemplo, funciona em todas as cargas de trabalho, de bare-metal a VMs e contêineres. Não há disparidade de recursos entre cargas de trabalho em contêineres e cargas de trabalho não conteinerizadas, então você obtém microssegmentação com visualização, automação e gerenciamento de políticas para todas as cargas de trabalho.

Namespaces, pods ou serviços?

O Kubernetes define três entidades principais de contêineres nas quais o tráfego de rede de saída e entrada pode ser controlado: um pod, um serviço ou um namespace. (Nota: os nós não são considerados como um destino entre essas entidades, e um cluster é definido como o limite mais amplo em torno de uma coleção de nós). Além disso, geralmente há um balanceador de carga implantado no perímetro do cluster, resultando em quatro entidades possíveis que podem ser segmentadas. Ao definir sua arquitetura de microssegmentação, quais dessas entidades devem ser classificadas como um segmento? Alguns deles ou todos eles?

Um pod é a menor entidade à qual o Kubernetes pode atribuir um endereço IP. As instâncias de tempo de execução de contêineres serão executadas em um ou mais pods e, muitas vezes, esses pods precisarão se comunicar entre si. Cada pod pode ser definido como um segmento, mas o desafio é que o Kubernetes pode desacelerar e, posteriormente, girar os pods, o que, do ponto de vista da rede, significa que os endereços IP de destino ou de origem podem desaparecer repentinamente. As equipes de rede e segurança não gostam quando as entidades desaparecem repentinamente na estrutura geral, tornando difícil lidar com ferramentas de convergência e segurança de rotas.

O Kubernetes pode implantar um serviço, que é implantado na frente de um determinado número de pods, agindo quase como um balanceador de carga para os pods por trás dele. Os serviços são muito mais estáveis e, embora o Kubernetes possa ativar e desativar dinamicamente os pods, raramente o fará com os serviços. Portanto, é uma prática recomendada definir um serviço como um segmento, e não como pods individuais.

É importante que você pergunte ao fornecedor de microssegmentação se ele pode definir um pod ou um serviço como um segmento, permitindo que a escolha seja deixada para o administrador de segurança.

Os aplicativos implantados em contêineres geralmente são implantados como um namespace, com o código essencialmente executado de forma distribuída em um ou mais pods. Um namespace de contêineres é uma abstração entre vários pods e serviços.

O Illumio, por exemplo, permite definir um “perfil” em relação a um namespace e, em seguida, definir esse perfil como um segmento. O resultado é que o Illumio permite que a definição de um segmento seja em relação a um pod, serviço ou namespace. E, diferentemente das ferramentas de microssegmentação projetadas especificamente para ambientes em contêineres, o Illumio também pode definir segmentos em relação ao host subjacente, aos pontos de entrada/saída no limite do cluster e às cargas de trabalho legadas circundantes que precisam acessar recursos dentro dos contêineres. Os segmentos não existem apenas em contêineres, eles existem em toda a estrutura da nuvem.

É por isso que você deve garantir que seu fornecedor de microssegmentação possa gerenciar mais de 100.000 cargas de trabalho. Quanto mais ambientes de contêiner são implantados em uma estrutura de nuvem, mais rápido esses altos números entram em foco. E esses números consistem em cargas de trabalho que, em contêineres, geralmente são efêmeras, com cargas de trabalho ganhando vida e desaparecendo dinamicamente. Isso significa que sua solução de microssegmentação precisa responder às mudanças em tempo real.

Ao usar a instância Kubelink da Illumio implantada em um cluster de contêineres, você pode descobrir dinamicamente cargas de trabalho que são implantadas e descomissionadas, habilitando nosso mapa de dependência de aplicativose aplique ferramentas para reagir em tempo real a toda e qualquer mudança nas cargas de trabalho que estão sendo gerenciadas. Automação e orquestração são dois conceitos importantes em contêineres, e a Illumio implementa ambos para operacionalizar o gerenciamento de microssegmentação dentro e fora do ambiente de contêineres.

Implantar contêineres em sua nuvem não deve significar sacrificar a capacidade de definir segmentos em torno das cargas de trabalho, independentemente de como elas são implantadas. Certifique-se de que sua solução de segmentação continue a escalar para os mesmos números altos que as cargas de trabalho em contêineres permitem, sem incorrer em obstáculos. Com o Illumio Core, sua empresa pode alcançar Confiança zero em torno de cada carga de trabalho em toda a sua estrutura de nuvem, independentemente da escala.

Quer mais? Leia como O Illumio Core pode proteger o Kubernetes e o OpenShift.

Entre em contato conosco hoje para saber como proteger seus contêineres com a segmentação Illumio Zero Trust.