0
0
Mais e mais organizações estão adotando Kubernetes, mas estão enfrentando desafios de segurança ao longo do caminho. Na edição de outono de 2020 do seu relatório “State of Container and Kubernetes Security”, por exemplo, stackRox descobriu que quase 91% das organizações pesquisadas haviam adotado Kubernetes, com maioria (75%) dos participantes revelando que tinham implantado a plataforma de orquestração de contêineres em seus ambientes de produção. Mesmo assim, nove em cada dez entrevistados disseram ter sofrido um incidente de segurança envolvendo um erro de configuração, vulnerabilidade ou erro de tempo de execução em seus ambientes de contêineres e Kubernetes nos últimos 12 meses. Quase metade (44%) passou a dizer que eles tinham atrasado a mudança de um aplicativo para a produção como resultado de suas preocupações de segurança.
Essas descobertas destacam a necessidade de as organizações garantirem que suas configurações de Kubernetes complementem seus requisitos de segurança. Como parte desse processo, os administradores podem se concentrar na proteção de seus clusters, que fazem parte da arquitetura Kubernetes. Depois de definir o que é um cluster, este post de blog explorará os dois conjuntos de componentes existentes dentro de um cluster e fornecerá orientação sobre como as organizações podem proteger esses componentes ao longo do caminho.
Entendendo o cluster Kubernetes
Em seu site, Kubernetes diz que os clientes recebem um cluster — ou um conjunto de uma ou mais máquinas detrabalhadores chamadas” nós ” que são responsáveis pela execução de um aplicativo containerizado — sempre que eles implantam Kubernetes. Esses nódulos hospedam pods,grupos de um ou mais recipientes que funcionam como componentes da carga de trabalho do aplicativo. Em última análise, kubernetes torna possível para os administradores gerenciar os nós e o cluster de forma mais geral, incluindo eventos que afetam qualquer um, usando o plano de controle.
Os administradores podem garantir um cluster Kubernetes direcionando especificamente seus esforços para o plano de controle e os nós do trabalhador.
O plano de controle
Dentro do plano de controle, os administradores podem concentrar suas medidas de segurança em cinco componentes: kube-apiserver, etcd, kube-scheduler, kube-controller-manager e cloud-controller-manager.
kube-apiserver
O kube-apiserver é a principal implementação de um servidor API Kubernetes dentro de uma implantação kubernetes. Ele escala horizontalmente à medida que os administradores implantam mais instâncias de kube-apiserver para equilibrar o tráfego dentro de seus ambientes. Como front-end para o plano de controle Kubernetes, o servidor API potencialmente expõe a API kubernetes. Os administradores podem proteger esse elemento atualizando para a versão mais recente do Kubernetes e aplicando atualizações, fechando assim lacunas de segurança. A partir daí, os administradores podem restringir o acesso ao servidor API Kubernetes, configurando autenticação para clientes de API kubernetes e garantindo que todo o tráfego de API seja criptografado usando TLS.
etc
Uma loja de valores chave, etcd funciona como a loja de backup para todos os dados de cluster Kubernetes. Os administradores podem querer considerar ter um plano de backup para esses dados. Semelhante ao kube-apiserver, eles podem mais uma vez recorrer à criptografia, autenticação e controle de acesso como um meio de ganhar visibilidade sobre o acesso à leitura e gravação a esse armazenamento de dados.
kube-agendar
Dentro do plano de controle, os administradores podem usar o componente kube-scheduler para funcionar para pods recém-criados que não têm um nó atribuído no momento de sua criação. Eles podem então atribuir um nó para que esses pods sejam executados dependendo dos requisitos de recursos, restrições de políticas, localidade de dados e outros fatores. Para otimizar a segurança desse elemento, os administradores podem restringir as permissões de arquivo no kube-scheduler, configurar o serviço para servir apenas HTTPS e vinculá-lo a uma interface local.
kube-controller-manager
Essa característica do plano de controle é responsável pela execução de processos iniciados pelo controlador de nó, que responde a quando os nós descem; o controlador de replicação, que garante que haja um número correto de pods implantados no sistema; bem como outros controladores. O StackRox recomenda que os administradores protejam o kube-controller-manager seguindo todas as mesmas diretrizes de segurança usadas para o kube-scheduler, com a adição de que os administradores “garantam que uma credencial de conta de serviço individual seja configurada por controlador em conjunto com a Kubernetes RBAC para garantir que os loops de controle sejam executados com permissões mínimas necessárias”.
cloud-controller-manager
Por último, mas não menos importante, no plano de controle está o gerenciador de controlador de nuvem ou o componente que permite aos administradores vincular o cluster à API do provedor de nuvem. Os administradores podem usar o gerenciador de controlador de nuvem para executar controladores específicos para seu provedor de nuvem. Para garantir que esse elemento esteja seguro, no entanto, eles precisam seguir as mesmas diretrizes identificadas para o kube-controller-manager acima.
Kubernetes Node
Os administradores precisam proteger três partes de um nó de trabalhador kubernetes: o kubelet, kube-proxy e tempo de execução de contêiner.
kubelet
Encontrado dentro de cada nó de um cluster, o kubelet garante que todos os recipientes estejam funcionando dentro de uma cápsula. Ele vai um passo além usando várias especificações do pod para garantir que esses recipientes estejam funcionando de forma ideal. Mesmo assim, fornece essa visibilidade apenas aos contêineres criados pela Kubernetes. No suporte a esse recurso, os administradores podem aplicar patches disponíveis para remediar vulnerabilidades identificadas no kubelet. Eles também podem usar autenticação forte e autorização para limitar quem pode acessar este elemento cluster.
kube-proxy
Como o kubelet, kube-proxy é executado em cada nó no cluster. Esse recurso impõe regras de rede sobre nós, incluindo especificações para permitir a comunicação de rede de fora do cluster. Os administradores podem proteger esse componente restringindo as permissões de arquivo se estiverem usando um arquivo kubeconfig baseado em arquivo e usando uma porta segura para facilitar a comunicação protegida com o servidor API.
Tempo de execução do contêiner
O tempo de execução do contêiner faz jus ao seu nome. É o componente que é responsável pela execução de contêineres disponíveis via Docker e outros tempos de execução. Os administradores podem proteger esse software olhando de forma mais ampla para a segurança de seus contêineres. Isso inclui revisar os privilégios de seus contêineres e proibir os serviços SSH de funcionar dentro de um contêiner.
Isso não é tudo.
Garantir a arquitetura Kubernetes não termina com a discussão acima, no entanto. É importante notar que também existem complementos que usam recursos kubernetes para implementar recursos de cluster. A documentação de Kubernetes fornece mais informações sobre como proteger esses complementos.
FONTE: AT&T