0
0
Kubernetes mudou a forma como estruturamos, implantamos e executamos nossos aplicativos e se tornou um padrão de fato para executar infraestrutura em escala. Com a rápida adoção de tecnologias baseadas em contêineres, as organizações estão cada vez mais preocupadas com a segurança de seus clusters Kubernetes. E deveriam estar! Embora as distribuições em nuvem e empresas forneçam recursos sólidos de segurança, elas requerem ajuste de acordo com as necessidades de segurança organizacional.
Neste artigo, passarei por três áreas fundamentais que você precisa considerar para proteger um cluster Kubernetes:
- Controle de acesso baseado em função (RBAC)
- Agente de Políticas Abertas (OPA)
- Políticas de rede
Vamos mergulhar!
Controle de acesso baseado em função
Vamos considerar uma organização com três equipes de aplicação (Azul, Verde e Vermelho). Como essas equipes estão trabalhando em diferentes produtos, eles devem ter acesso diferente ao cluster Kubernetes. Por exemplo, as equipes Verde e Vermelha não devem ser capazes de ver, acessar ou excluir o que a equipe Azul implantou.
O RBAC é uma maneira de controlar o que os usuários de recursos da Kubernetes podem acessar. Embora o RBAC esteja ativado por padrão, você deve configurá-lo para usá-lo.
Existem 5 elementos-chave para o RBAC:
- Assuntos – Usuários e processos
- Recursos – Objetos aos quais o acesso deve ser restrito
- Verbos – Conjuntos de operações que podem ser executadas, muitas vezes referidos como ações
- Funções – Um objeto que conecta recursos de API com verbos
- RoleBinding – Um objeto que conecta Papéis com Sujeitos
Vamos voltar ao nosso exemplo de organização e definir uma política onde apenas a equipe Azul pode criar, excluir e listar Pods, Implantações e Serviços.
Primeiro, criamos um objeto Role chamado ‘role-blue’, onde definimos as ações que podem ser executadas em recursos específicos da Kubernetes. Neste caso específico, o Papel permite que as ações ‘criar’, ‘excluir’ e ‘lista’ sejam executadas nos recursos; ‘pods’, ‘implantações’ e ‘serviços’.
Em seguida, criamos um RoleBinding chamado ‘blue-rb’. Este RoleBinding pertence a ‘blue-ns’, que liga o papel acima criado ‘role-blue’ com a equipe azul, chamada ‘azul’.
Uma vez que esses recursos são aplicados ao cluster, os usuários da equipe ‘azul’ terão a capacidade de executar as operações definidas em ‘role-blue’.
Agente de Política Aberta
O Open Policy Agent (OPA) é um mecanismo de política de uso geral que unifica a aplicação da política em toda a pilha. Sua linguagem declarativa de alto nível fornece flexibilidade para especificar a política como código. Você pode usar o OPA para aplicar políticas em Kubernetes, pipelines CI/CD, gateways de API e muito mais. Vamos mergulhar em como usá-lo e implementá-lo em Kubernetes.
A implementação kubernetes da OPA é chamada gatekeeper. Ele é projetado e implantado como um Controle de Admissão que intercepta solicitações, processa-os e responde com uma permissão ou nega resposta.
Quando permitido, o objeto é implantado no cluster; caso contrário, a solicitação será rejeitada e o feedback fornecido ao usuário. Os administradores podem definir políticas que instruem o Kubernetes a limitar os recursos, como memória ou CPU que os contêineres ou espaços de nome podem consumir, aprovar apenas contêineres com base em imagens de registros específicos, restringir a criação de serviços NodePort ou impor nomeação padrão.
Por exemplo, aqui está um modelo de exemplo e uma política de restrição que permite a criação de Pods somente quando o ResourceQuota é configurado em um namespace.
Política de rede
As políticas de rede são muito semelhantes a um firewall regular, mas diferem no sentido de que são centradas no aplicativo. Quando você define uma política de rede para um aplicativo, a Kubernetes aplica automaticamente essas regras aos contêineres associados devido ao ambiente altamente dinâmico no qual os contêineres são constantemente criados e encerrados. As políticas de rede controlam o fluxo de tráfego para ou a partir desses contêineres.
Por padrão, o tráfego de rede de e para Pods não é restrito. Um bom ponto de partida é estabelecer uma regra de tráfego negado e, em seguida, apenas permitir o tráfego necessário.
Por padrão, a Kubernetes usa uma estrutura de rede plana permitindo que qualquer Pod se comunique com outros Pods ou Serviços no cluster. Em um cluster com vários aplicativos ou aplicativos de vários níveis, a defesa em profundidade desempenha um papel fundamental na proteção da camada de comunicação. As políticas de rede nos permitem conseguir isso.
Aqui está uma “política de rede de aplicativos” que aplica as seguintes regras no namespace ‘azul’ para os Pods com o rótulo “role=db”:
- [Ingress] Permite conexões do ipBlock 172.17.0.0/24 na porta 6379
- [Ingress] Permite conexões de outros pods se forem rotulados como “role=frontend” e se pertencerem ao namespace com rótulos “project=myproject” na porta 6379
- [Egress] O pod pode se comunicar com outros pods com faixa IP 10.0.0.0/24 na porta 5978.
Conclusão
Com rbac, OPA e políticas de rede em vigor, você pode proteger seu cluster Kubernetes, garantindo que os contribuintes tenham o acesso adequado, que as políticas de segurança sejam aplicadas e que a rede esteja bem protegida.
FONTE: HELPNET SECURITY