O Kubernetes é extremamente popular, mas sem medidas de segurança adequadas, também apresenta riscos. O especialista em segurança CyberArk nomeia três riscos específicos e mostra quais medidas defensivas são necessárias para controlar os riscos de hardware, servidor de API e contêiner no Kubernetes.
No desenvolvimento de software hoje, velocidade e agilidade são fundamentais. A tecnologia de contêineres está sendo usada cada vez mais. O Kubernetes emergiu como o padrão de fato para gerenciar cargas de trabalho e serviços em contêineres.
Aspectos de segurança do Kubernetes
Do ponto de vista da segurança, a plataforma de orquestração do Kubernetes traz consigo desafios específicos relacionados à identidade que precisam ser abordados no início do processo de desenvolvimento. Caso contrário, os ambientes conteinerizados podem representar um risco para a segurança de TI. Existem três principais áreas potencialmente vulneráveis no Kubernetes nas quais as organizações devem se concentrar como parte de uma verdadeira abordagem DevSecOps.
Risco do Kubernetes: Hardware
Seja executando o Kubernetes no local ou em uma nuvem gerenciada por terceiros, uma plataforma de hardware ainda é necessária. Depois que um invasor tem acesso à máquina virtual que executa o Kubernetes e obtém privilégios de root, ele também pode atacar os clusters do Kubernetes.
Para evitar isso, existem as seguintes práticas recomendadas de segurança:
- Aplicar o princípio do menor privilégio é crucial para proteger o hardware subjacente ao Kubernetes e aos próprios contêineres. As máquinas virtuais devem ser implantadas com o nível mais baixo de privilégios (ou seja, apenas aqueles estritamente necessários por motivos funcionais) para dificultar o acesso root aos invasores.
- As credenciais precisam ser alternadas regularmente, e usar uma solução de cofre automatizada faz sentido para aumentar ainda mais a proteção sem aumentar a sobrecarga.
Risco do Kubernetes: Kubernetes API Server
Além das máquinas físicas, o plano de controle do Kubernetes também precisa ser protegido. Ele fornece acesso a todos os contêineres em execução em um cluster, incluindo o servidor Kubernetes API, que atua como um front-end e facilita a interação do usuário dentro do cluster.
Um ataque ao servidor da API pode ter um grande impacto. Até mesmo um único segredo ou credencial roubado pode ser usado para escalar os direitos e privilégios de acesso de um invasor. Uma vulnerabilidade inicialmente pequena pode se transformar rapidamente em um problema em toda a rede.
As melhores práticas de segurança incluem:
- Para mitigar o risco, as organizações devem primeiro proteger os endpoints contra roubo de credenciais e ameaças de malware. Os computadores locais usados por usuários com direitos administrativos no Kubernetes são particularmente relevantes.
- A autenticação multifator (MFA) para acesso aos servidores da API do Kubernetes é essencial. Por exemplo, uma credencial roubada não pode ser usada para acesso ao Kubernetes.
- Depois que os usuários são autenticados no Kubernetes, eles podem acessar todos os recursos do cluster. A gestão das autorizações é, portanto, de importância crucial. Com o controle de acesso baseado em função, uma empresa pode garantir que os usuários tenham apenas os direitos de acesso de que realmente precisam.
- O privilégio mínimo também deve ser aplicado nas contas de serviço do Kubernetes, que são criadas automaticamente quando um cluster é configurado, para ajudar a autenticar os pods. Igualmente importante é a rotação regular de segredos para eliminar oportunidades de acesso para aqueles que não precisam mais deles.
Risco do Kubernetes: contêineres
Pods e contêineres são os blocos de construção de um cluster Kubernetes e contêm as informações necessárias para executar o aplicativo. Existem várias vulnerabilidades potenciais nesse ecossistema e fluxo de trabalho de contêiner. Isso inclui, por exemplo, acesso não seguro à API do contêiner ou ao host do contêiner e registros de imagem desprotegidos.
As melhores práticas a seguir são recomendadas para a segurança do contêiner:
- Os segredos não devem ser incorporados no código ou em uma imagem de contêiner. Caso contrário, quem tiver acesso ao código-fonte também terá acesso às informações em repositórios de código, por exemplo.
- Os riscos de segurança são significativamente minimizados com controle de acesso baseado em função, restrição de acesso secreto a processos dentro de um contêiner específico e exclusão de segredos que não são mais necessários.
- O uso secreto, incluindo rotação ou desativação, deve ser registrado. Uma solução central de gerenciamento de segredos que permite a administração automática e proteção de dados de acesso confidenciais também é vantajosa.
“Ao adotar essas práticas recomendadas, uma empresa pode melhorar significativamente a segurança em todo o ambiente Kubernetes”, disse Michael Kleist, vice-presidente de área DACH da CyberArk. “Além disso, existe também a possibilidade de apoiar os desenvolvedores com funções de autoatendimento em seu trabalho diário, por exemplo, no que diz respeito à digitalização de códigos. Isso permite que eles façam uma contribuição adicional para aumentar a segurança do Kubernetes de forma rápida e conveniente.”
Mais em CyberArk.com
Sobre a CyberArk
A CyberArk é líder global em segurança de identidade. Com Privileged Access Management como um componente central, a CyberArk fornece segurança abrangente para qualquer identidade - humana ou não humana - em aplicativos de negócios, ambientes de trabalho distribuídos, cargas de trabalho de nuvem híbrida e ciclos de vida DevOps.