Introdução à segurança do Kubernetes

Embora a adoção de containers e Kubernetes seja crescente, a segurança continua sendo a principal preocupação em relação a eles. A boa notícia é que há muito que pode ser feito para deixar a implementação de containers mais segura. Esta introdução à segurança do Kubernetes aborda várias etapas que podem ser realizadas para dar os primeiros passos com a segurança de containers.

As imagens de container normalmente são a fonte principal de vulnerabilidades que podem ser introduzidas em ambientes nativos em nuvem. Parte principal de uma estratégia eficaz de segurança é garantir que as práticas seguras de criação de imagens sejam cumpridas em toda a empresa. Embora a verificação de imagens seja parte importante da segurança da empresa, proteger as imagens é uma forma de garantir proativamente a segurança das aplicações em containers no início do ciclo de vida da aplicação.

Adote as seguintes práticas recomendadas para criar imagens de container com segurança:

1. Use imagens base mínimas

   A imagem deve ter somente as bibliotecas e ferramentas que o container precisará para reduzir a superfície de ataque.

2. Use imagens base de fontes de confiança

   Se você não estiver criando uma imagem do zero, escolha imagens base de uma fonte de confiança. Você deve conseguir ver o Dockerfile e o código-fonte para todos os componentes da imagem, e ela deve ser hospedada em um registro com boa reputação. As imagens base também devem ser atualizadas com frequência.

3. Especifique um usuário

   Caso o Dockerfile não especifique um usuário, o container será executado por padrão com o usuário raiz, que expande a superfície de ataque potencial e oferece um caminho simples para a escalação de privilégios caso a aplicação seja comprometida.

4. Verifique imagens do Docker

   É difícil garantir a autenticidade da imagem, mas este é também um componente importante para criar imagens seguras. Imagens base devem ser assinadas e validadas. Extrair imagens somente de registros de confiança é uma forma de assegurar que todas as imagens sejam autênticas.

5. Busque vulnerabilidades

   É importante encontrar e corrigir vulnerabilidades existentes em imagens de container, incluindo as introduzidas por bibliotecas open source.

6. Mantenha os segredos por fora

   Os segredos, que incluem dados confidenciais, como credenciais e chaves, não devem ser incorporados em imagens de container.

7. Defina limites de recursos

   Limitar a quantidade de recursos de memória ou CPU acessados pelo container ajuda a restringir o dano que ele pode causar, caso seja usado de maneira inadequada.

8. Limite privilégios

   Restrinja os privilégios do container o máximo possível e configure o container de modo a impedir que privilégios sejam escalados.

9. Use criações em várias etapas

   As ferramentas de criação usadas para gerar e compilar aplicações podem ser exploradas quando executadas em sistemas de produção. Em vez de usar as mesmas imagens na fase de criação e execução, use Dockerfiles em várias etapas para remover ferramentas desnecessárias das imagens do runtime. Depuradores também devem ser removidos das imagens de produção.

10. Use práticas de codificação voltadas para a segurança

    Elas podem ser reforçadas usando um linter para capturar código inseguro no processo de desenvolvimento.

Essas etapas são específicas para o processo de criação de imagem, mas os princípios por trás dessa criação segura também devem apresentar práticas de segurança em outras partes da aplicação. Essas práticas incluem deixar a superfície de ataque o menor possível, limitando privilégios e estreitando configurações em vez de usar as configurações padrão do Kubernetes e outros aspectos do stack nativo em nuvem.

O Center for Internet Security (CIS) cria práticas recomendadas para defesa cibernética. O CIS usa crowdsourcing para definir as recomendações de segurança. Os CIS Benchmarks estão entre suas ferramentas mais conhecidas.

As organizações podem usar o CIS Benchmark para o Kubernetes para fortalecer os ambientes Kubernetes. Estão disponíveis algumas ferramentas comerciais e open source que fazem a verificação automática das definições e controles descritos no CIS Benchmark para identificar configurações inseguras.

O CIS Benchmark oferece algumas verificações de configurações úteis, mas as organizações devem considerá-las um ponto de partida e ir além. Desse modo, elas garantem que as práticas recomendadas sejam aplicadas ao Kubernetes, incluindo a implementação de políticas de rede, configurações de controle de acesso baseado em função (RBAC), privilégios administrativos e outras proteções para o servidor da API do Kubernetes.

O controle de acesso baseado em função (RBAC) do Kubernetes usa o método padrão para gerenciar a autorização para os endpoints da API do Kubernetes. A configuração do RBAC do cluster controla quais indivíduos podem executar quais verbos, em quais tipos de recursos e namespaces. Por exemplo, uma configuração pode conceder ao usuário "alice" acesso para ver recursos do tipo "pod" na API externa do namespace. A API do RBAC inclui quatro objetos declarativos: Role, ClusterRole, RoleBinding e ClusterRoleBinding.

Roles são um recurso de namespace que consistem em regras que definem permissões para namespaces individuais, enquanto os ClusterRoles não são do namespace e concedem permissões em todo o cluster ou permissões que abrangem vários namespaces. Cada regra é uma combinação de verbos, tipos de recursos e seletores de namespace.

Uma vinculação de função é o que conecta um usuário, um grupo de usuários ou uma conta de serviços (também conhecidos como sujeitos) a uma função e concede a esses usuários as permissões definidas nessa função. Uma vinculação de função de cluster conecta uma ClusterRole a todos os namespaces do seu cluster. Assim, uma RoleBinding atribui permissões dentro de um namespace, enquanto uma ClusterRoleBinding concede essas permissões em todo o cluster.

A partir da nossa experiência com os clientes, descobrimos os seguintes cinco erros mais comuns a se buscar nas configurações do RBAC.

Erro de configuração 1:função de administrador do cluster concedida sem necessidade

A função de administrador do cluster integrada concede acesso ilimitado ao cluster. Durante a transição do controlador ABAC legado para o RBAC, alguns administradores e usuários podem ter replicado uma configuração permissiva do ABAC, concedendo ampla administração do cluster e ignorando os avisos na documentação. Se usuários ou grupos tiverem acesso de administrador contínuo ao cluster, comprometimentos ou erros na conta podem ter muitos efeitos perigosos. As contas de serviços, em geral, também não precisam desse tipo de acesso. Nos dois casos, uma Função ou Função de Cluster mais personalizada deve ser criada e concedida somente a usuários específicos que precisam dela.

Erro de configuração 2:uso impróprio da agregação de funções

No Kubernetes 1.9 e posteriores, a agregação de função pode ser usada para simplificar concessões de privilégios, permitindo que novos privilégios sejam combinados a funções existentes. No entanto, se essas agregações não forem revisadas com atenção, elas poderão alterar o uso original de uma função. Por exemplo, a função system:view poderia, inapropriadamente, agregar funções com verbos diferentes de visualizar, violando a intenção de que sujeitos com acesso a system:view nunca possam modificar o cluster.

Erro de configuração 3:concessão de função duplicada

Funções diferentes podem ter permissões em comum, dando aos indivíduos o mesmo acesso. Os administradores às vezes fazem isso deliberadamente, mas essa configuração torna mais difícil a compreensão de quais sujeitos têm determinados acessos. Essa situação pode dificultar a revogação de privilégios caso um administrador não perceba que várias agregações de funções concedem os mesmos privilégios.

Erro de configuração 4:função não utilizada

Funções que são criadas e não concedidas a nenhum sujeito podem aumentar a complexidade do gerenciamento do RBAC. Da mesma forma, funções concedidas somente a sujeitos que não existem (como contas de serviços em namespaces excluídos ou usuários que saíram da empresa) podem dificultar a visualização das configurações que realmente importam. Em geral, é seguro remover essas funções não utilizadas ou inativas. Dessa forma, as funções ativas serão o foco.

Erro de configuração 5:conceder funções ausentes

Vinculações de funções podem fazer referência a funções que não existem. Se o mesmo nome de função for reutilizado para um propósito diferente no futuro, as vinculações de funções inativas poderão conceder de maneira repentina e inesperada privilégios a sujeitos diferentes do pretendido pelo criador da nova função.

Configurar corretamente as funções e vinculações de RBAC do cluster ajuda a minimizar o impacto dos comprometimentos da aplicação, a tomada de controle da conta do usuário, bugs da aplicação ou erros humanos simples.

Máquinas virtuais e containers têm arquiteturas essencialmente diferentes, embora tenham semelhanças que podem gerar confusão. As diferenças entre containers e máquinas virtuais têm ramificações de segurança muito importantes. Os dois oferecem isolamento em diferentes graus e permitem a portabilidade. Máquinas virtuais são completamente autossuficientes, têm seu próprio sistema operacional e não compartilham recursos com outras máquinas virtuais. Containers compartilham hosts com outros containers, dificultando a ideia de uma fronteira segura.

Containers e Kubernetes apresentam um paradigma de arquitetura diferente, que exige abordagens diferentes à segurança. As técnicas bem-estabelecidas para segurança baseada em host não são válidas para os containers. Outras técnicas de segurança do host ou da especialidade de máquina virtual, como a criação de firewalls de rede em um perímetro definido, também não se aplicam aos containers. Além disso, parte essencial das práticas recomendadas de segurança de máquinas virtuais é aplicar patches de segurança, mas eles não podem ser aplicados a um container em execução. Em vez disso, é necessário atualizar a imagem de container e recriá-lo.

Para proteger containers, é preciso:

• Controlar as conexões entre containers
• Garantir que os containers estejam livres de vulnerabilidades conhecidas
• Impedir que os containers tenham acesso raiz
• Restringir permissões e acesso a apenas o necessário para o funcionamento da aplicação

O Kubernetes aumenta a complexidade e introduz mais riscos potenciais de segurança. Gerenciar as configurações e políticas de rede do Kubernetes é essencial para ter uma segurança sólida em aplicações em containers.

Além disso, devido às alterações de fluxo de trabalho resultantes da migração para aplicações em containers, é importante integrar a segurança em todo o ciclo de vida. A segurança deve ser adicionada à aplicação desde o início, começando por como imagens e containers são configurados. Não é possível adicionar segurança a uma aplicação em containers no final do processo de desenvolvimento, imediatamente antes da implantação.

Para ter aplicações em containers protegidas, é necessário controlar a fonte de todos os componentes, incluindo elementos open source, gerenciar configurações, verificar imagens e permitir controles granulares de acesso baseados em funções. Os containers e Kubernetes exigem uma abordagem diferente para a segurança, mas devido à natureza comprobatória e imutável deles, eles dão a oportunidade (quando corretamente configurados) de desenvolver as aplicações mais seguras já criadas.

No Kubernetes, containers são executados em pods (um dos muitos Objetos do Kubernetes), e a configuração do runtime de cada pod pode ser definida e reforçada usando uma combinação de contexto de segurança na especificação de pods, as Políticas de Segurança de Pod (PSPs), ou um controlador de admissão como o guardião do Open Policy Agent (OPA).

O contexto de segurança é definido na manifestação da implantação e permite definir o requisito exato para cada carga de trabalho. Ele pode ser configurado para um pod ou um container. As políticas de segurança de pods são um recurso do Kubernetes a nível do cluster que controlam o contexto de segurança em que os pods podem ser executados. Se as PSPs forem habilitadas para um cluster, qualquer tentativa de criar um pod que não cumpra a PSP associada será rejeitada pelo controlador de admissão de PSP.

Limite os privilégios do runtime de container:

• Não execute os processos da aplicação como raiz. Defina runAsUser como MustRunAsNonRoot
• Não permita a escalação de privilégios. Defina allowPrivilegeEscalation como false
• Use um sistema de arquivos raiz somente para leitura. Defina readOnlyRootFilesystem como true
• Use a montagem padrão (mascarada) /proc do sistema de arquivos
• Não use a rede do host ou o espaço do processo. Defina hostPID, hostNetwork e hostIPC como false
• Abandone recursos não utilizados do Linux e não adicione recursos opcionais não exigidos pela aplicação
• Use opções do selinux para controles de alta granularidade do processo
• Forneça a própria conta de serviços do Kubernetes a cada aplicação
• Não ative as credenciais da conta de serviços no container se o acesso à API do Kubernetes não for necessário

Use os namespaces do Kubernetes

Os namespaces do Kubernetes oferecem o escopo para objetos do cluster, permitindo o gerenciamento de alta granularidade desses objetos. Containers/pods, serviços e implantações em um namespace podem ser isolados usando controles como as políticas de rede do Kubernetes ou ter o acesso restrito com o controle de acesso baseado em função (RBAC) do Kubernetes.

Antes de começar a implantar cargas de trabalho nos clusters, planeje como você quer atribuir namespaces. Ter um namespace por aplicação é a melhor opção para ter controle, embora isso incorra em custos indiretos de gerenciamento com a atribuição de privilégios de função de RBAC e políticas de rede padrão. Se quiser agrupar mais de uma aplicação em um namespace, recomenda-se considerar como critérios principais se essas aplicações têm os mesmos requisitos de RBAC e se seria seguro conceder esses privilégios a contas de serviços e usuários que precisam de acesso à API do Kubernetes nesse namespace.

De maneira geral, o gerenciamento de configurações é a prática da engenharia de estabelecer políticas referentes às configurações e assegurar que elas sejam aplicadas de maneira consistente em toda a empresa, em todo o ciclo de vida da aplicação. As configurações são parte essencial do gerenciamento de riscos de segurança em aplicações nativas em nuvem, principalmente porque muitas configurações padrão de containers e do Kubernetes não são seguras. Erros de configuração são a fonte mais comum de riscos de segurança em aplicações em containers executadas no Kubernetes.

O gerenciamento de configurações deve ser automatizado, com grades de proteção gerenciadas de maneira central para que operadores ou desenvolvedores individuais não sejam responsáveis por configurar as cargas de trabalho manualmente. Essas grades de segurança devem ser baseadas nas políticas organizacionais de segurança.

Segundo a IBM, 95% das falhas de segurança na nuvem são causadas por erro humano. O risco de erros de configuração aumenta conforme as aplicações ficam mais complicadas, com execução em sistemas distribuídos em containers e no Kubernetes. Sem uma ferramenta de gerenciamento de configurações centralizada, é praticamente impossível que as empresas assegurem a aplicação consistente das políticas de configurações. Para empresas com uma configuração multicloud ou de nuvem híbrida, fazer a configuração corretamente e de maneira consistente é um desafio ainda maior, pois cada ambiente exige seu próprio conjunto de configurações. Desenvolvedores e operadores também sofrem com uma lacuna de habilidades, já que nem sempre estão conscientes das práticas recomendadas para a configuração segura.

Em muitos casos, a forma mais fácil de definir configurações para a execução das aplicações é também a menos segura, como permitir acesso raiz, dar privilégios de administrador ou traçar limites de recursos muito altos. Com as ferramentas certas, o gerenciamento de configurações pode ser integrado ao fluxo de trabalho de DevOps para não atrasar o desenvolvimento. Essa é uma prática recomendada, pois elimina a tensão entre lançar rapidamente e proteger as configurações da carga de trabalho.

O gerenciamento de configurações deve incluir uma forma de obter visibilidade nas configurações e colocar grades de segurança sobre quais configurações são permitidas. Dessa forma, as criações inseguras ou implantações de risco vão falhar automaticamente. As organizações precisam de um único painel de controle para ver todas as configurações relevantes nos containers e no Kubernetes. Elas também devem ficar alertas a configurações potencialmente de risco.

As bases fundamentais do gerenciamento de configurações para containers e o Kubernetes são as seguintes:

• Controles de acesso baseado em funções (RBAC): as organizações devem encontrar configurações excessivamente permissivas e/ou funções desnecessárias.
• Segredos: uma boa ferramenta de gerenciamento de configurações pode limitar o acesso a segredos de maneira proativa.
• Avaliações baseadas em políticas: parte crucial de qualquer postura de segurança inclui definir políticas organizacionais de segurança, e deve existir uma forma de verificar se as implantações estão de acordo com essas políticas pré-determinadas.
• Privilégios: privilégios devem ser atribuídos com base nos princípios de acesso com privilégios mínimos.
• Limites de recursos: clusters de containers e do Kubernetes devem limitar a disponibilidade de CPU e memória.
• Políticas de rede: as políticas de rede devem limitar ao máximo a comunicação entre as partes da aplicação, a fim de limitar potenciais danos no caso de comprometimento de um container.

A maneira mais simples de iniciar o gerenciamento de configurações é seguir as práticas recomendadas aceitas no setor, como os CIS Benchmarks. Com o avanço da adoção de containers nas empresas, uma prática recomendada é criar políticas organizacionais de governança em torno do gerenciamento de configurações. O gerenciamento de configurações deve abordar as configurações de containers e do Kubernetes, já que elas devem ser gerenciadas de maneira adequada nos dois locais para garantir uma postura sólida de segurança.

Por padrão, o Kubernetes permite que todos os pods em um cluster se comuniquem livremente. Isso facilita as operações da aplicação, mas também gera riscos de segurança. Embora o padrão seja permissivo demais, o Kubernetes também tem recursos integrados de reforço que podem ser configurados para restringir a comunicação entre ativos. A segmentação de rede é parte da restrição da comunicação entre partes da implantação. Ela também é obrigatória em alguns frameworks de conformidade, como o PCI-DSS.

A segmentação de rede funciona fracionando as redes em sub-redes menores. Do ponto de vista da segurança, a principal vantagem é que se um agente malicioso ganhar acesso a uma aplicação sendo executada no mesmo cluster do Kubernetes que outras aplicações, a segmentação de rede impedirá que esse agente acesse todas as aplicações no cluster. Também é uma forma de manter cargas de trabalho confidenciais e/ou cargas que estão no escopo de um framework de conformidade específico isoladas de outras partes da aplicação.

Políticas de rede devem ser o mais restritivas possível, permitindo que containers individuais se comuniquem somente com os containers necessários para o funcionamento correto da aplicação.

No Kubernetes, a segmentação de rede é feita com o reforço das políticas de rede, por meio dos recursos de reforço de redes nativas do Kubernetes e usando camadas adicionais de infraestrutura, como uma service mesh.

Por padrão, não há restrições para a comunicação entre pods, containers e nós, seja dentro de um mesmo namespace ou entre namespaces. Implementar políticas de rede para restringir a comunicação, geralmente começando com uma política que rejeita toda a comunicação, é uma prática recomendada como ponto de partida. Como os pods não precisam se comunicar entre si, o melhor é listar sistematicamente os pods com que um em específico precisa se comunicar. Entrar e sair da internet pública também deve ser permitido com base em uma lista de permissões, já que somente pods precisam fazer isso.

Também há riscos operacionais associados às políticas de rede em transformação e à crescente segmentação de rede. O uso de uma ferramenta para visualizar como mudanças nas políticas de rede em todo o sistema afetariam a aplicação pode ajudar a minimizar o risco de consequências inesperadas provenientes desses ajustes.

Nenhuma empresa terá uma aplicação ou infraestrutura de TI totalmente segura. Segurança exige priorizar e compreender riscos e compensações associados a diferentes ações. Caracterização de risco é o processo de descrever os riscos de segurança conhecidos da empresa e suas políticas e práticas relacionadas ao gerenciamento deles. Toda empresa deve aceitar algum nível de risco, mas deve estar claro o quanto é aceitável. A caracterização de risco deve ser feita não apenas para a empresa como um todo, mas para aplicações individuais. Cargas de trabalho confidenciais ou aquelas que estão no escopo dos requisitos de conformidade têm um perfil de risco diferente das cargas não confidenciais.

A caracterização de risco também ajuda a avaliar a importância das vulnerabilidades existentes no ambiente. Seria impossível responder a todas as vulnerabilidades. Portanto, uma postura sólida de segurança exige avaliar o risco de cada uma e priorizar corretamente a remediação.

Em uma aplicação distribuída e em containers, pode ser difícil entender e priorizar o perfil de risco de uma aplicação. Deve haver centenas de vulnerabilidades em qualquer aplicação potencial, mas elas não apresentam o mesmo risco. O risco de segurança de uma vulnerabilidade depende de fatores como:

• A gravidade da vulnerabilidade
• Se a aplicação é voltada para o público
• Se a aplicação está em produção
• Se a aplicação está no escopo dos regulamentos de conformidade
• Se a aplicação tem acesso a dados confidenciais
• O nível do privilégio do container
• A exposição de rede do container

É importante que as organizações definam com antecedência qual nível de risco é aceitável, criando políticas internas sobre a velocidade em que vulnerabilidades em cada nível de severidade devem ser corrigidas. No entanto, a caracterização de risco não é um exercício estático. O processo de avaliar riscos de segurança, especialmente no contexto de uma aplicação em containers, deve ocorrer continuamente no runtime.

Fazer a triagem manual de potenciais incidentes de segurança, vulnerabilidades e políticas é uma receita para erros e sobrecarga. Às vezes, não é possível realizar a caracterização de risco, principalmente em escala, sem o uso de ferramentas de automação para descobrir e priorizar riscos de segurança. Para realizá-la com sucesso no Kubernetes, é necessário usar dados contextuais e declarativos do Kubernetes para automatizar o processo de priorização. Isso permite que equipes de segurança concentrem-se primeiro na correção das implantações de maior risco, em vez de perderem tempo no processo de caracterização de risco.

Idealmente, a caracterização de risco pode ser usada como uma ferramenta reativa e proativa. Quando riscos são encontrados e corrigidos em uma implantação, as informações podem ser usadas para encontrar outras implantações com fatores de risco semelhantes e abordar de maneira proativa os potenciais riscos de segurança com antecedência.

A segurança do runtime é essencial na defesa contra agentes maliciosos. Idealmente, todas as vulnerabilidades sem patches, com configurações ou credenciais inseguras, seriam identificadas na etapa de criação ou implantação. Mas na verdade, a detecção e resposta no runtime é essencial: às vezes, as vulnerabilidades escapam nessas fases primárias, além de que novas vulnerabilidades são continuamente descobertas. Também é importante por motivos de conformidade e como uma linha de defesa contra ameaças internas.

Cargas de trabalho declarativas e imutáveis exigem todo um modelo novo para detectar e responder a potenciais incidentes de segurança no runtime. A execução de um número mínimo de processos pelos containers, combinada com a natureza declarativa do Kubernetes, torna alguns aspectos da segurança em runtimes mais fáceis do que em aplicações baseadas em máquinas virtuais. Por outro lado, containers em execução não devem "receber patches" da mesma forma que patches de segurança seriam aplicados a uma aplicação baseada em máquinas virtuais. Em vez disso, eles devem ser tratados como imutáveis e devem ser eliminados, atualizados e reiniciados.

A detecção é a base fundamental da segurança do runtime. Isso inclui encontrar uma linha de base de como a aplicação se comporta e investigar atividades que desviam muito dessa linha. Solicitações de rede e execuções de processos são algumas das atividades que podem ser rastreadas. Quando essas atividades desviam do esperado, pode ser um sinal de atividade suspeita ou maliciosa. Por exemplo, tentar se conectar à Internet quando não é permitido. Independentemente disso, esse tipo de comportamento anômalo apontaria para algo que precisa ser observado.

A detecção de anomalias pode ser mais precisa em containers do que é em cargas de trabalho baseadas em máquinas virtuais, pois containers têm apenas uma aplicação. Isso facilita o isolamento do que é ou não um comportamento de linha de base para um container. No entanto, ela deve estar sempre conectada a um processo de resposta a incidentes.

Dependendo do tipo de comportamento anômalo, o melhor curso de ação pode ser responder automaticamente, fazendo com que a plataforma elimine os pods ou containers afetados. Em outros casos, pode ser mais adequado enviar um alerta e avaliar o comportamento manualmente. No entanto, a resposta a potenciais incidentes deve ser a mais automatizada possível para minimizar os tempos de resposta e aumentar a segurança geral das aplicações em containers.

O kubelet é o principal "agente de nó" sendo executado em cada nó. Configurá-lo de maneira errada pode deixar seu sistema exposto a um host de riscos de segurança. Você pode usar argumentos no kubelet executável que está em funcionamento ou um arquivo de configuração do kubelet para definir sua configuração.

Para encontrar um arquivo de configuração do kubelet, execute este comando:

ps -ef | grep kubelet | configuração grep

Procure o argumento --config, que dara a localização do arquivo de configuração do kubelet.

Em seguida, execute o seguinte comando em cada nó:

ps -ef | grep kubelet

Na saída, confirme se o:

- argumento --anonymous-auth é false. No artigo do kubelet mencionado anteriormente, um dos erros de configuração explorado foi onde solicitações anônimas (e sem autenticação) tiveram permissão para serem atendidas pelo servidor kubelet.

- argumento --authorization-mode é exibido como AlwaysAllow, se estiver presente. Se não estiver, certifique-se de que há um arquivo de configuração do kubelet especificado pelo --config e que o arquivo definiu o authorization: mode como algo além de AlwaysAllow.

- argumento --client-ca-file está presente e definido no local do arquivo de autoridade de certificação do cliente. Se não estiver, certifique-se de que há um arquivo de configuração do kubelet especificado pelo --config e que o arquivo definiu o authentication: x509: clientCAFile como o local do arquivo de autoridade de certificação do cliente.

- argumento --read-only-port está presente e definido como 0. Se não estiver, certifique-se de que há um arquivo de configuração do kubelet especificado pelo --config e que o readOnlyPort está definido como 0 se estiver presente.

--protect-kernel-defaults é mostrado comotrue. Se não estiver presente, certifique-se de que há um arquivo de configuração do kubelet especificado pelo --config. Se estiver, verifique se o protectKernelDefaults está definido como true.

- argumento --hostname-override não está presente, para garantir que a configuração TLS entre o kubelet e o servidor da API não será quebrada.

- argumento --event-qps está presente e definido como 0. Se não estiver, certifique-se de que há um arquivo de configuração do kubelet especificado pelo --config e que o eventRecordQPS é mostrado como 0.

- argumentos --tls-cert-file e --tls-private-key-file estão definidos adequadamente ou a configuração do kubelet especificada pelo --config contém as configurações adequadas para tlsCertFile e tlsPrivateKeyFile. Essa configuração assegura que todas as conexões aconteçam por TLS nos kubelets.

RotateKubeletServerCertificate e --rotate-certificates são definidos como true se os kubelets tiverem seus certificados do servidor da API. Certifique-se também de que seu kubelet usa somente criptografias fortes

O servidor da API do Kubernetes lida com as chamadas da API REST dos usuários ou aplicações sendo executadas no cluster, permitindo o gerenciamento do cluster. Considerado o gateway para o control plane do Kubernetes, é possível acessar o servidor da API usando kubectl, bibliotecas do cliente ou fazendo solicitações diretamente da API. Uma forma de gerenciar a autorização do servidor da API do Kubernetes é usar o controle de acesso baseado em função (RBAC) do Kubernetes. Também é possível validar as solicitações ao servidor da API usando os controladores de admissões.

A proteção do servidor da API começa com o controle do acesso. O Center for Internet Security (CIS) oferece as práticas recomendadas para reforçar e proteger o servidor da API.

Execute o comando abaixo no seu nó mestre:

ps -ef | grep kube-apiserver

Na saída, confirme se o:

- argumento --anonymous-auth é mostrado como false. Essa configuração assegura que solicitações não rejeitadas por outros métodos de autenticação não sejam tratadas como anônimas e, portanto, sejam permitidas de acordo com a política.

- argumento --basic-auth-file não está presente. A autenticação básica usa credenciais com texto simples em vez de tokens ou certificados preferenciais.

- argumento --insecure-allow-any-token não está presente. Essa configuração garantirá a permissão somente de tokens seguros e autenticados.

- argumento –kubelet-https não está presente ou é mostrado como true. Essa configuração garante que as conexões entre o servidor da API e os kubelets estejam protegidas durante o tráfego por meio do Transport Layer Security (TLS).

- argumento --insecure-bind-address não está presente. Essa configuração impedirá que o servidor da API seja vinculado a um endereço inseguro, impedindo o acesso não autenticado e sem criptografia ao seu nó mestre, o que minimiza o risco de invasores lerem dados confidenciais em tráfego.

- argumento --insecure-port é mostrado como 0. Essa configuração impedirá que o servidor da API atenda a uma porta insegura, o que impedirá o acesso não autenticado e sem criptografia ao nó mestre e minimizará o risco de um invasor tomar o controle do cluster.

- argumento --secure-port ou não existe ou é mostrado como um número inteiro entre 1 e 65535. O objetivo é assegurar que todo o tráfego seja servido por https com autenticação e autorização.

- argumento --profiling é mostrado como false. A menos que você esteja enfrentando obstáculos ou precise resolver problemas, não há necessidade de um perfil, e a presença dele sem necessidade deixa expostos detalhes do programa e sistema.

- argumento --repair-malformed-updates é mostrado como false. Essa configuração garantirá que solicitações dos clientes com má formação intencional sejam rejeitadas pelo servidor da API.

- argumento --enable-admission-plugins é definido como um valor que não contém AlwaysAdmit. Se você configurar para admitir sempre, as solicitações serão admitidas mesmo que não estejam explicitamente permitidas pelo plug-in de controle de admissões, o que diminui a eficácia do plug-in.

- argumento --enable-admission-plugins é definido com um valor que contém AlwaysPullImages. Essa configuração garante que os usuários não tenham autorização para levar imagens do nó para um pod apenas sabendo o nome da imagem. Com esse controle, as imagens sempre serão puxadas antes de iniciar um container, o que exigirá credenciais válidas.

-argumento --enable-admission-plugins é definido com um valor que contém SecurityContextDeny. Esse controle garante que não seja possível personalizar o contexto de segurança no nível do pod de uma forma que não tenha sido descrita na Política de Segurança de pods.

- argumento --disable-admission-plugins é definido com um valor que não contém NamespaceLifecycle. Não é desejável desativar esse controle, pois ele garante que objetos não sejam criados em namespaces inexistentes ou naqueles configurados para serem encerrados.

- argumento --audit-log-path é definido como um caminho apropriado onde desejar que seus registros de auditoria sejam armazenados. Como prática de segurança, é sempre bom habilitar a auditoria de todos os componentes do Kubernetes, quando disponíveis, incluindo o servidor da API.

- argumento --audit-log-maxage é definido como 30 ou qualquer outro número de dias que você precise armazenar seus arquivos de registro de auditoria para estar em conformidade com as políticas de retenção de dados internos e externos.

- argumento --audit-log-maxbackup é definido como 10 ou qualquer número que ajude você a cumprir com os requisitos de conformidade de retenção do número de arquivos antigos de registro.

- argumento --audit-log-maxsize é definido como 100 ou qualquer outro número que ajude você a cumprir com os requisitos de conformidade. Observe que o número 100 indica 100 MB.

- argumento --authorization-mode está presente e não é definido como AlwaysAllow. Essa configuração garante que somente solicitações autorizadas tenham permissão pelo servidor da API, principalmente em clusters de produção.

- argumento --token-auth-file não está presente. Esse argumento, quando presente, usa autenticação baseada em token estático, que conta com diversas falhas de segurança. Em vez disso, use métodos de autenticação alternativos, como os certificados.

- argumento --kubelet-certificate-authority está presente. Essa configuração ajuda a impedir um ataque man-in-the-middle onde tenha uma conexão entre o servidor da API e o kubelet.

- argumentos --kubelet-client-certificate e --kubelet-client-key estão presentes. Essa configuração garante que o servidor da API se autentique nos endpoints HTTPS do kubelet. Por padrão, o servidor da API não realiza essa etapa.

- argumento --service-account-lookup está presente e definido como true. Essa configuração ajuda a evitar uma instância em que o servidor da API verifique somente a validade do token de autenticação sem garantir que o token da conta de serviços incluído na solicitação esteja presente noetcd.

- argumento --enable-admission-plugins é definido com um valor que contém PodSecurityPolicy.

- argumento --service-account-key-file está presente e definido como um par de chaves públicas/privadas separadas para assinar os tokens da conta de serviços. Se você não especificar um par de chaves públicas/privadas, ele usará a chave privada do certificado servido pelo TLS, o que prejudicará sua capacidade de fazer rotação de chaves para tokens da conta de serviços.

- argumentos --etcd-certfile e --etcd-keyfile estão presentes para que o servidor da API se identifique para o servidor do etcd usando a chave e o certificado do cliente. Observe que o etcd armazena objetos provavelmente confidenciais por natureza, então todas as conexões do cliente devem usar criptografia TLS.

- argumento --disable-admission-plugins é definido e não contém ServiceAccount. Essa configuração vai garantir que, quando um novo pod for criado, ele não usará uma conta de serviços padrão no mesmo namespace.

- argumentos --tls-cert-file e --tls-private-key-file estão presentes de tal modo que o servidor da API serve apenas tráfego HTTPS via TLS.

- argumento --client-ca-file existe para garantir que a autenticação do TLS e do certificado do cliente seja configurado para implantações de clusters do Kube.

- argumento --etcd-cafile existe e é definido de forma que o servidor da API deve verificar a si mesmo para o servidor do etcd por meio do arquivo de uma autoridade de certificação de SSL.

- argumento --tls-cipher-suites é definido de forma que use criptografias fortes.

- argumento --authorization-mode está presente com um valor com nó. Essa configuração limita quais objetos os kubelets podem ler em associação aos seus nós.

- argumento --enable-admission-plugins é definido e contém o valor NodeRestriction. Esse plug-in garante que um kubelet tenha permissão para modificar somente seu próprio objeto da API do nó e os objetos da API do pod associados ao nó.

- argumento --encryption-provider-config é definido como um arquivo de - EncryptionConfig e esse arquivo deve ter todos os recursos necessários. Essa configuração garante que todos os objetos da API REST armazenados no armazenamento de chave-valor do etcd são criptografados em repouso.

Confirme se o provedor da criptografia aescbc é utilizado para todos os recursos desejados, pois esse provedor é considerado o mais forte.

- argumento --enable-admission-plugins contém o valor EventRateLimit para definir um limite no número de eventos aceitos pelo servidor da API para otimizar o desempenho do cluster.

- argumento --feature-gates não é definido com um valor com AdvancedAuditing=false. Ou seja, certifique-se de que a auditoria avançada não foi desabilitada para propósitos de auditoria e investigação.

- argumento --request-timeout é definido ou não com um valor adequado (nem muito curto nem muito longo). O valor padrão é 60 segundos.

- argumento --authorization-mode existe e é definido com um valor que inclui o RBAC do Kubernetes.

Essa configuração garante que o RBAC esteja ativo. Além de apenas ativá-lo, você deve seguir várias outras recomendações sobre o melhor modo de usar o RBAC, incluindo:

• Evitar conceder função de administrador do cluster aos usuários, pois isso lhes dá poderes muito amplos sobre o ambiente e deve ser usado com muita moderação, apenas se for necessário.
• Fazer auditoria de suas regras de agregação de funções para assegurar o uso correto delas.
• Não dar permissões duplicadas aos sujeitos, pois isso pode dificultar a revogação do acesso.
• Remover regularmente funções não utilizadas.

Um dos maiores riscos com containers e o Kubernetes é que as configurações de nenhuma das duas tecnologias são seguras. Reduzir o risco de incidentes de segurança exige mudar as configurações padrão de maneira consistente em toda a empresa. Ignorar essa etapa, por distração, falta de conhecimento ou fluxos de trabalho que não adotam uma etapa de gerenciamento de configurações deixará as cargas de trabalho vulneráveis sem necessidade.

Configurações padrão em containers

Muitas configurações padrão e práticas comuns de criação de containers podem deixá-los vulneráveis. Veja alguns itens a serem considerados ao configurar containers.

• Especifique um usuário: se um usuário não for especificado, o usuário raiz será usado como padrão, podendo dar ao host acesso raiz ao container.
• Verifique as imagens: as configurações padrão não exigem a verificação de imagens, levando à possibilidade de extrair imagens comprometidas sem querer.
• Defina limites de recursos: os limites de recursos podem ser configurados, mas não há limites padrão. Limitar o consumo de CPU e memória pelo container ajuda a impedir que o container consuma muitos recursos caso seja comprometido.
• Instale ferramentas e bibliotecas de maneira seletiva: quanto menos ferramentas e bibliotecas em um container, menos ferramentas um agente malicioso terá para explorar caso obtenha acesso ao container. Não instale um conjunto padrão de ferramentas em cada container, instale apenas o que for realmente necessário.
• Controle o acesso ao registro permitindo listagens: além de garantir que as imagens usadas sejam de fontes confiáveis, o acesso ao registro deve ser devidamente controlado, idealmente pela permissão de listagens de usuários de confiança.

Configurações padrão no Kubernetes

O Kubernetes também oferece muitas ferramentas para melhorar a segurança da empresa, mas elas devem ser configuradas ativamente para trazer benefícios reais. Veja alguns fatores principais a serem verificados no Kubernetes.

• Configure os controles de acesso baseado em funções (RBAC): o RBAC é ativado por padrão no Kubernetes 1.6 e posteriores, mas ainda precisa ser configurado corretamente para oferecer benefícios de segurança. Idealmente, o acesso deve ser dado por namespace, não por clusters.
• Use namespaces: O "padrão" é executar tudo no mesmo namespace. Use a separação oferecida pelos namespaces para isolar cargas de trabalho.
• Use as políticas de rede do Kubernetes: não há políticas de rede prontamente configuradas, portanto, as empresas precisam instalar um plug-in de rede para controlar a entrada e saída de tráfego da aplicação e configurar as políticas conforme for mais adequado.
• Habilite a geração de logs de auditoria: a geração de logs de auditoria não costumam ser habilitados por padrão, mas devem ser ativados para obter visibilidade de chamadas anômalas de API e falhas de autorização.

As equipes de desenvolvimento, normalmente sem especialidade em segurança, são as primeiras a usar containers e Kubernetes. No entanto, ignorar a segurança expõe empresas ao risco, não importa o tipo de infraestrutura usado.

É importante relembrar que as configurações em containers e no Kubernetes não são seguras por padrão, como mencionado anteriormente. A funcionalidade de segurança nativa do Kubernetes deve ser ativamente configurada para oferecer benefícios de segurança. A maneira mais rápida e segura de manter uma aplicação ativa é dar muitos privilégios a ela e/ou definir limites de recursos muito mais altos do que o necessário para a aplicação, ou deixar no modo padrão. Embora as organizações possam se sentir tentadas a ignorar a segurança inicialmente, principalmente enquanto estão se familiarizando com os containers e o Kubernetes, isso as coloca em grande risco. Para agentes maliciosos, explorar aplicações em containers no Kubernetes é tão fácil quanto explorar aplicações legadas.

O principal risco de não fazer nada é que a aplicação ficará comprometida por agentes maliciosos. A proporção do desastre que isso causaria depende do setor da empresa, do tipo de aplicação sendo usada e do escopo e tipo de violação. A probabilidade de a negligência com a segurança resultar em um incidente também depende de fatores como a aplicação voltada para a Internet.

Não fazer nada para garantir a segurança das aplicações em containers as coloca em risco, deixando-as vulneráveis sem necessidade. Ignorar a segurança leva a:

Vulnerabilidades de segurança sem patches. Novas vulnerabilidades de segurança são descobertas o tempo todo, e algumas delas são bem sérias. Tanto a comunidade open source quanto os agentes maliciosos terão conhecimento dessas vulnerabilidades assim que forem publicadas, ou seja, demorar para cuidar delas é arriscado.

Permissões fracas. Embora o controle de acesso baseado em função (RBAC) seja habilitado por padrão no Kubernetes, é o desenvolvedor quem decide colocar os controles de acesso em vigor. Sem orientações sobre segurança, os desenvolvedores podem criar cargas de trabalho com muito acesso.

Cargas de trabalho não isoladas. Por padrão, tudo pode ser executado em um único namespace padrão. Usar namespaces para começar a isolar cargas de trabalho é uma prática recomendada básica de segurança. Sem a atenção necessária para essa etapa de segurança, esse nível de isolamento não ocorrerá.

Nenhum controle das políticas de rede. As políticas de rede do Kubernetes podem ajudar as empresas a controlarem o tráfego, mas elas exigem um plug-in de rede e que as políticas sejam configuradas.

Deixar para depois a aplicação de controles de segurança poderá resultar em práticas de segurança desarticuladas, um obstáculo na análise de segurança que atrasa o desenvolvimento e aumenta o risco de incidentes de segurança. Em vez disso, ajude as empresas a aplicar controles de segurança com antecedência e constância no ciclo de vida de desenvolvimento de softwares.

Como o verdadeiro sistema de orquestração de containers, o Kubernetes possibilita o gerenciamento de containers, mas também introduz potenciais vulnerabilidades de segurança em ambientes de infraestrutura. As diferenças entre segurança com containers, Kubernetes, máquinas virtuais e uma insistente lacuna de habilidades em relação à segurança do Kubernetes podem levar a riscos desnecessários.

As práticas recomendadas de segurança do Kubernetes, como todas as de segurança, incluem práticas para deixar a aplicação e a infraestrutura mais seguras, além de práticas organizacionais e culturais para um controle centralizado da segurança.

Criar e impor políticas organizacionais de segurança é uma prática recomendada, independentemente do stack de tecnologia de confiança da empresa. A segurança é um processo de gerenciamento de riscos, e não se deve confiar em ferramentas para decidir quanto risco é aceitável para cada aplicação, por exemplo. Esse tipo de decisão deve ser realizada por humanos que podem levar em consideração quanto risco é aceitável para a empresa em geral, para unidades de negócios individuais e para cada aplicação.

Controle central de segurança. Em relação ao primeiro ponto, as empresas precisam de uma maneira de garantir que as políticas de segurança e a governança definidas estão sendo seguidas. Equipes centrais precisam ver as configurações e vulnerabilidades em toda a distribuição da aplicação e precisam de uma maneira de visualizar facilmente e priorizar potenciais problemas. Além disso, elas precisam conseguir criar grades de segurança para o feedback instantâneo no caso de a criação contar com uma configuração de risco, uma imagem insegura ou outros riscos potenciais de segurança.

Adote medidas de segurança no começo do processo. Adotar uma abordagem "shift left" e tomar medidas de segurança no começo do processo não apenas ajuda a remover o obstáculo na análise de segurança e a lançar as aplicações mais rapidamente, mas também diminui a probabilidade de erros que resultam na exploração de vulnerabilidade ou erro de configuração.

Potencialize a automação. A expansão da área de ocupação do Kubernetes para vários clusters e centenas de namespaces impossibilita realizar manualmente o gerenciamento de configurações ou o monitoramento do comportamento do runtime.

Existem também práticas técnicas recomendadas muito importantes específicas para tornar o Kubernetes o mais seguro possível.

• Mantenha o Kubernetes atualizado. Como os patches de segurança podem não ser liberados para versões anteriores, recomenda-se executar uma versão mais recente e compatível.
• Use o controle de acesso baseado em função. O acesso deve ser sempre configurado com privilégios mínimos.
• Limite a comunicação entre pods. Os limites devem ser o mais restritos possível, para que os pods funcionem conforme devido.
• Use a segmentação de rede. Cada pod deve ser capaz de se comunicar apenas com os recursos internos ou externos que precisa e permanecer isolado de todos os outros.

O gerenciamento de vulnerabilidades é um componente essencial para a segurança das aplicações. É o processo de identificar, avaliar e corrigir vulnerabilidades em todas as etapas do ciclo de vida de desenvolvimento de software. O gerenciamento de vulnerabilidades em aplicações nativas em nuvem e em containers precisa ser automatizado e integrado aos processos de DevOps de criação e envio das aplicações. O ambiente é muito complexo para gerenciar vulnerabilidades manualmente. No mundo real, se o desenvolvimento for muito demorado, as empresas ficarão tentadas a ignorar medidas de segurança.

Esse gerenciamento não é apenas mais uma etapa necessária para a aplicação, mas sim um processo contínuo que inicia com a introspecção e verificação de imagens na etapa de criação e continua por todo o ciclo de vida da aplicação, nos ambientes de teste e produção.

A verificação de imagens e a implementação de políticas referentes a vulnerabilidades de imagens durante a etapa de criação são os primeiros passos em direção ao gerenciamento eficaz de vulnerabilidades nativas em containers. A capacidade de executar verificações sob demanda, conforme as imagens são criadas ou depois que os containers são executados, é importante para identificar vulnerabilidades que podem ter sido expostas no runtime. O gerenciamento de vulnerabilidades deve ser capaz de identificar a exposição em containers e no Kubernetes, já que ambos podem ser fonte de vulnerabilidades.

Aplicações completamente seguras não existem, e o bom gerenciamento permite que as equipes não vejam apenas essas vulnerabilidades, mas também informações adicionais que ajudarão a priorizar o nível crítico de determinada vulnerabilidade específico para a empresa. Por exemplo, até mesmo um CVE de alta prioridade tem um perfil de risco diferente dependendo da confidencialidade da carga de trabalho. O bom gerenciamento de vulnerabilidades é capaz de equilibrar, avaliar e priorizar correções para adotar a melhor postura possível em segurança.

Ele deve ser automatizado principalmente em aplicações nativas em nuvem. A inteligência humana é necessária para definir políticas, mas as ferramentas devem ser responsáveis por encontrar violações da política e tomar as medidas adequadas com base na vulnerabilidade, nível de risco e parte do ciclo de vida, reprovando criações automaticamente e bloqueando implantações ou tornando-as inutilizáveis na produção.

A verificação de vulnerabilidades e imagens deve começar na fase de criação, mas deve continuar em todo o ciclo de vida da aplicação, incluindo o runtime. Novas vulnerabilidades na segurança podem ser descobertas a qualquer momento, e a capacidade de detectá-las ao executar implantações é primordial para a postura de segurança da empresa. Vulnerabilidades em implantações em execução podem resultar em um risco imediato de segurança. Por isso, as empresas precisam saber detectar e corrigi-las o mais rápido possível.

Na fase de criação, imagens que não estão em conformidade (incluindo as com vulnerabilidades graves e corrigíveis) devem ser reprovadas. As equipes de DevOps devem receber o feedback diretamente do sistema de CI. No momento da implantação, ferramentas de segurança podem usar o controle de admissões para impedir automaticamente a implantação de containers com vulnerabilidades conhecidas detectadas na imagem. É essencial saber como priorizar a correção, de acordo com a gravidade da vulnerabilidade, a confidencialidade da carga de trabalho e a tolerância geral da empresa para riscos de segurança. As empresas devem ter tempo para criar políticas personalizadas e implementar ferramentas que permitam a imposição dessas políticas, no momento da criação e da implantação, por meio da automação. Depois que as implantações já estiverem em execução, é essencial que as organizações continuem buscando vulnerabilidades.

Diferentes recursos em verificadores de imagens

Nem todos os verificadores de imagens oferecem o mesmo nível de verificações abrangentes: alguns verificam somente o sistema operacional subjacente, outros também verificam bibliotecas, outros fazem as verificações no nível da linguagem e outros verificam conteúdos de arquivos. É importante escolher um verificador que ao menos atenda às necessidades da empresa e que seja compatível com as linguagens de programação usadas pelas suas aplicações.

Alguns verificadores fazem o trabalho em tempo real em cada extração de imagem, mas essa abordagem pode aumentar a latência. Sendo assim, as empresas devem decidir se vale a pena prejudicar o desempenho para obter informações em tempo real.

Fazer verificações no runtime

Assim como acontece na verificação de imagens na fase de criação, nem todas as vulnerabilidades detectadas devem ter a mesma resposta. As empresas precisam definir uma forma para priorizar a correção com base na confidencialidade da carga de trabalho e dos dados, na exposição à Internet, bem como na gravidade das vulnerabilidades detectadas. Nenhuma empresa terá os mesmos procedimentos ou objetivos a nível do serviço para dar a resposta adequada às vulnerabilidades descobertas. Algumas alternativas estão associadas a, por exemplo, bloquear todos os containers com vulnerabilidades, independentemente da gravidade ou confidencialidade. A verificação de vulnerabilidades bem-sucedida em implantações em execução exige as ferramentas corretas para garantir a visibilidade e informação corretas e políticas organizacionais de segurança meticulosas, que conquistem o equilíbrio ideal entre gerenciamento de vulnerabilidades e impacto operacional.

A complexidade das redes corporativas e das aplicações distribuídas nelas aumentaram, e os modelos de ameaça e métodos utilizados para aprofundar a infiltração seguiram o exemplo. Perímetros de segurança podem servir somente como uma defesa inicial para proteger redes internas, não como uma estratégia abrangente de proteção da infraestrutura e de dados. Uma segurança robusta requer uma combinação de controles e estratégias.

Redes de confiança zero podem ser uma peça importante no quebra-cabeça de segurança. Para isso, basta se concentrar em aumentar a segurança do tráfego interno da aplicação. Esse modelo substitui o princípio antigo de que todo tráfego dentro de uma rede de firewall é autêntico por uma suposição contrária: nenhuma conexão de rede deve ser considerada segura até que se prove o contrário.

Tradicionalmente, os administradores de rede trabalhavam com a suposição de que toda entidade (seja aplicação, servidor, ou parte de hardware ou software de rede) encontrada em suas redes internas pertencia a elas e era de confiança. Alguns aplicações não exigiam autenticação de conexões do cliente ou confiavam em credenciais estáticas e compartilhadas, como uma senha para um banco de dados. Todas as aplicações tinham que cuidar de qualquer esquema de autenticação ou autorização, isso quando tinham algum. Conexões de rede internas, mesmo aquelas para serviços confidenciais, muitas vezes não usavam nenhuma criptografia.

Muitas redes corporativas ainda seguem esse padrão. No entanto, um único invasor colocado nesse ambiente frágil, seja por um hack direto, um cavalo de troia aplicado por acidente por um indivíduo autorizado ou simplesmente um buraco em um firewall de rede pode causar estragos ao se aproveitar dessa rede implícita de confiança. As possibilidades não são infinitas, mas são previsíveis. Da detecção de pacotes de rede de texto simples à descoberta de senhas da aplicação para banco de dados ou outros sistemas críticos, à conquista do controle do equipamento de rede, esse cenário deixa o ambiente aberto para riscos inaceitáveis, incluindo extração ou perda de dados.

Confiança zero é a base para um número crescente de infraestruturas de produção que priorizam a segurança. Em vez de supor que toda entidade em uma rede é de confiança sem verificação, ela assume que tudo é suspeito, inclusive a própria infraestrutura da rede. O framework de confiança zero não oferece uma implementação prescritiva ou um conjunto específico de tecnologias a serem usadas. Em vez disso, apresenta um conjunto de princípios e objetivos, deixando os detalhes técnicos específicos de implementação a cargo de cada empresa.

Arquiteturas de confiança zero

Arquiteturas de confiança zero, em geral, seguem os seguintes princípios:

• Os controles de segurança devem ser aplicados igualmente a todas as entidades, seja software ou hardware, independentemente do seu local na rede.
• As conexões de rede devem ser autenticadas nas duas pontas, pelo servidor e pelo cliente. A autenticação do cliente pelo servidor é normalmente esperada, mas os clientes também devem verificar se estão conectados a um servidor válido. Conexões devem ser reautenticadas e solicitações devem ser reautorizadas conforme necessário ao abranger mais de uma transação.
• Autorizações devem seguir o princípio de privilégio mínimo, permitindo somente o mínimo de permissões necessárias para a carga de trabalho de um cliente.
• Todas as transações e conexões de rede devem estar sujeitas a monitoramento contínuo.

Implementar o modelo confiança zero no Kubernetes

Como seria o modelo confiança zero em um cluster do Kubernetes? Embora não exista nenhuma metodologia para implementar os princípios de confiança zero em um cluster do Kubernetes, as service meshes surgiram como uma solução conhecida para muitos dos objetivos de arquitetura.

Elas criam uma camada de rede virtualizada para conectar e controlar serviços distribuídos de aplicação. A maioria das soluções de service mesh inicialmente não tinham como foco a segurança de rede, mas sim facilitar e gerenciar a descoberta inteligente de serviços e rotear solicitações. No entanto, os projetos de open source mais conhecidos hoje oferecem funcionalidades que se encaixam em uma arquitetura de confiança zero. Conforme muitas service meshes tentam criar uma sobreposição que não precise de modificação de aplicações individuais, o trabalho de fazer mudanças significativas é simplificado para habilitar controles rígidos de autenticação e autorização.

As service meshes compatíveis com o Kubernetes costumam usar roteamento descentralizado e point-to-point (P2P), dando a cada pod de cluster sua própria instância de proxy. Esses proxies podem gerenciar certificados TLS do cliente, que podem ser usados pelo proxy para provar a identidade ao fazer conexões com outros serviços ou receber conexões de outros clientes. O uso dos certificados TLS para provar a identidade do cliente e do servidor é chamado de Transport Layer Security mútuo (mTLS). O mTLS, além de realizar a autenticação da conexão, também serve para criptografar a conexão de rede. Além da autenticação e criptografia durante a transmissão, service meshes diferentes oferecem suporte a diferentes fontes de autorização, desde listas estáticas até integrações com single sign-on de terceiros ou outros serviços.

As service meshes não oferecem uma solução de confiança zero completa para clusters do Kubernetes, mas oferecem alguns de seus principais benefícios. Mesmo que você não alcance uma arquitetura perfeita de confiança zero em seus clusters do Kubernetes, qualquer alteração adicional nesse sentido ajudará a proteger o cluster e suas cargas de trabalho.

A proteção de aplicações nativas em nuvem e da infraestrutura subjacente requer mudanças significativas na abordagem de segurança. As empresas devem aplicar controles no início do ciclo de vida do desenvolvimento de aplicações, usar controles integrados para impor políticas que evitem problemas operacionais e de escalabilidade e acompanhar o ritmo cada vez mais acelerado dos cronogramas de lançamento.

O Red Hat Advanced Cluster Security (ACS) for Kubernetes é a plataforma de segurança nativa do Kubernetes pioneira do setor. Ele prepara as organizações para criar, implantar e executar aplicações nativas em nuvem de forma mais segura. A solução ajuda a aprimorar a segurança do processo de criação da aplicação, a proteger a plataforma de aplicação e suas configurações e a detectar e responder problemas no runtime.