Neste artigo ensinaremos as melhores práticas do uso do Kubernetes. Essa é um tecnologia incrível e poderosa, mas como tantas outras não resolve todos os seus problemas. Mas qualquer pessoa que trabalhe com ele sabe como as coisas podem ficar complexas rapidamente. A segurança do Kubernetes não é diferente.
Por Adriano Frare
Security / Pen Test e Colunista do Crypto ID
O Kubernetes não é seguro por padrão. Existem várias vias de ataque e CVEs são encontrados regularmente. Como pode se verificado neste link.
Numa visão geral, Kubernetes é um servidor de API, bem como um sistema distribuído de agentes e bancos de dados etc em uma rede – todos os quais também precisam ser protegidos.
Por exemplo, a maneira mais segura de se autenticar em qualquer cluster do Kubernetes é usando OAuth. Mas, geralmente, a autenticação por meio de um arquivo de certificado de cliente privado e / ou nome de usuário e senha são ativados por padrão. Por outro lado, configurar uma interface de rede de contêiner (o serviço interno que facilita a comunicação de contêiner e pod na rede Kubernetes) que oferece suporte a políticas de rede (discutidas abaixo) pode ser um incômodo, mas a maioria das ofertas gerenciadas a torna uma opção de clique.
(DevSegOps) – Segurança dever ser pensada desde o seu desenvolvimento, distribuição e no seu uso
Contêineres
Os contêineres precisam ser construídos com segurança, e as imagens dos contêineres implantadas devem ser confiáveis para execução no sistema.
Construção
Construir contêineres seguros requer a varredura deles em busca de vulnerabilidades – incluindo pacotes do sistema Linux, bem como pacotes de aplicativos para linguagens dinâmicas como Python ou Ruby.
Para apoiar esse esforço em escala, considere o uso de uma ferramenta como Cloud Native Buildpacks (https://buildpacks.io/) , que permite que uma plataforma ou equipe de operações faça builds de contêiner padronizados que os desenvolvedores podem usar para colocar seu aplicativo – substituindo completamente o Dockerfile para um projeto. Essas compilações centralizadas podem ser mantidas atualizadas para que os desenvolvedores possam se concentrar no que são bons, em vez de ter que ser pau para toda obra DevOps.
As ferramentas de varredura de imagens de contêiner examinam as camadas de uma imagem construída em busca de vulnerabilidades conhecidas e são indispensáveis para manter seus builds e dependências atualizados. Eles podem ser executados durante o desenvolvimento e em pipelines de CI para mudar as práticas de segurança para a esquerda, dando aos desenvolvedores o primeiro aviso de uma vulnerabilidade.
A prática recomendada é reduzir o contêiner ao mínimo necessário para executar o aplicativo. Uma ótima maneira de arruinar o dia de um invasor é ter um contêiner sem casca!
Assinatura de contêineres
Os desenvolvedores de aplicativos podem estar acostumados a escanear dependências de aplicativos, mas agora que estão enviando um sistema operacional inteiro com seus aplicativos, eles também precisam de suporte para proteger o sistema operacional.
Agora você construiu contêineres seguros. Mas como você pode ter certeza de que os contêineres que você construiu são os que realmente são colocados em seu cluster?
O Docker oferece suporte à assinatura de imagens com uma chave, que pode ser autenticada no momento do pull e da implantação. Assinar contêineres é semelhante a adicionar certificados TLS a terminais.
Ele evita ataques man-in-the-middle, permitindo que você verifique se as imagens de contêineres que você está puxando são exatamente as que você enviou. Para que isso funcione, você precisa ter sistemas nos lados de empurrar e puxar que reconheçam a mesma chave. Veremos como evitar que imagens não assinadas sejam implantadas em seu cluster abaixo, quando examinarmos os controladores de admissão.
Sistema Operacional
Seus contêineres provavelmente estão executando Linux ou Windows, e o Kubernetes provavelmente está executando os contêineres em um deles também, já que oferece suporte a uma combinação de nós de trabalho Linux e Windows.
Para garantir que seu sistema esteja seguro, você ainda deve fazer o trabalho tradicional de garantir que os servidores só sejam expostos publicamente quando necessário, que as credenciais SSH sejam seguras, que as bibliotecas do sistema operacional estejam atualizadas e que o usuário e grupo as permissões estão bloqueadas. Se um invasor conseguir acessar seus nós mestre ou de trabalho, será muito mais fácil para ele comprometer qualquer parte do sistema Kubernetes – seja a API ou os agentes de kubelet. Mesmo em um mundo nativo da nuvem, ainda há a necessidade do bom e velho trabalho de administrador de sistemas, seja você delegado ao seu provedor de nuvem ou você mesmo.
RBAC
O Kubernetes oferece a capacidade de dar permissões específicas a usuários e contas de serviço, no cluster como um todo e em um determinado namespace.
Portanto, com esta ferramenta é possível definir quem pode fazer o quê no seu cluster? O controle de acesso baseado em função (RBAC) responde a essa pergunta.
Alguns exemplos de casos de uso estão permitindo que todas as equipes visualizem as especificações de aplicativos umas das outras, mas apenas sejam capazes de modificá-las em seus namespaces dedicados, ou permitindo que seu agente de pipeline de CI / CD implante coisas para produção e apenas alguns indivíduos controlados excluam coisas de lá. Eles variam de acordo com a organização, mas gerenciar ativamente o RBAC é essencial para um cluster seguro.
Controladores de admissão
Os controladores de admissão (AC) são a única maneira de obter segurança total do Kubernetes. Os ACs evitam que os contêineres sejam programados e executados no cluster, a menos que a especificação do pod atenda a determinados critérios. Existem muitos tipos de ACs, mas dois se destacam para análise: o PodSecurityPolicy AC e qualquer AC que valide imagens assinadas.
PodSecurityPolicies (PSPs) estão entre os invasores e os aspectos mais vulneráveis do sistema Kubernetes. Por exemplo, os contêineres no Kubernetes podem solicitar a montagem de qualquer caminho no host subjacente usando um volume do tipo “hostPath”, como o soquete Docker. Um contêiner que monta o soquete docker pode, sem status privilegiado, executar qualquer comando docker no host como root. Isso é assustador!
A única maneira de evitar isso é um PSP desautorizando os volumes hostPath. Existem vários outros caminhos de ataque profundo que as configurações do PSP podem prevenir. Se você fizer apenas uma coisa para proteger seu cluster, deve ser criar PSPs e habilitar o Controlador de admissão PSP.
Usando o Open Policy Agent (OPA), o qual está disponível no endereço https://www.openpolicyagent.org, você pode ter cada imagem de contêiner verificada para uma assinatura válida antes que ela seja permitida em seu cluster. Este é um ótimo guia sobre como usar o Notário e o OPA juntos para estabelecer uma cadeia de confiança total desde a criação até a implantação.
Políticas de Rede
As políticas de rede do Kubernetes são como regras de firewall internas para o cluster, o que deve falar sobre sua importância. Eles permitem que um administrador configure o cluster para cenários como:
- Um namespace só pode se comunicar com outro namespace onde estão suas dependências.
- O tráfego externo só pode alcançar um contêiner de gateway de API e nenhum outro contêiner.
- Impedir a saída de todos os contêineres, exceto para um registro DNS.
A principal limitação das políticas de rede é que a interface de rede do contêiner (CNI) usada pelo cluster deve suportá-las. Se você estiver gerenciando seu próprio cluster, não usando uma solução gerenciada de provedor de nuvem, você precisará pesquisar os CNIs disponíveis para ver o que funciona para sua rede que oferece suporte NetworkPolicy.
Conclusão
A segurança do Kubernetes é como qualquer outra tecnologia, necessita de cuidados e sempre obedecer as melhora práticas do mercado, pra a construção de um ecossistema seguro.
Office 365 – substituição do TLS 1.0 e 1.1. Por Adriano Frare
Problemas no OCSP causa revogação de ACs Intermediárias. Por Adriano Frare
Criptografia Homomórfica. Por Adriano Frare
Criptografia Homomórfica. Por Adriano Frare
Leia outros artigos de Adriano Frare em sua
Sobre Adriano Frare
Experienced Project Manager with a demonstrated history of working in the government administration industry. Skilled in Strategic Planning, ITIL, Project Management Office (PMO), IT Service Management, and Project Management Body of Knowledge (PMBOK), Digital Certificate (PKI), Secuity ( CEH), sales using methods Soluction Selling (IBM) Strong information technology professional graduated from Fundaçao Santo André.
