Container Service for Kubernetes:Segurança de multilocação

Contexto

Multilocação suave

Recursos nativos do Kubernetes, como namespace, roles, role bindings e network policies, fornecem isolamento lógico de locatários. O RBAC impede que locatários acessem recursos uns dos outros. As quotas e os limit ranges controlam o consumo de recursos por locatário, enquanto as network policies restringem a comunicação entre namespaces.

Esses controles não impedem que pods de diferentes locatários compartilhem um nó. Use nodeSelector, regras de anti-affinity, taints e tolerations para agendar pods de locatários em nós dedicados. Com muitos locatários, essa abordagem torna-se complexa e custosa.

A multilocação suave com namespaces não fornece aos locatários uma lista filtrada de namespaces, pois eles são recursos com escopo de cluster. Se um locatário visualizar um namespace, poderá visualizar todos os namespaces no cluster.

Por padrão, os locatários podem consultar o CoreDNS para obter todos os services do cluster. Um invasor pode explorar isso ao executar dig SRV ..svc.cluster.local a partir de qualquer pod. Para restringir o acesso aos registros DNS, use o plugin de firewall ou de política do CoreDNS. Consulte kubernetes-metadata-multi-tenancy-policy.

• Ambientes corporativos internos

  Todos os usuários do cluster pertencem à organização. Como as identidades são controladas, o risco de segurança é gerenciável. Cada locatário normalmente corresponde a uma unidade administrativa, como um departamento ou equipe.

  Os administradores do cluster geralmente criam namespaces e gerenciam políticas. Um modelo delegado concede permissões de supervisão a indivíduos sobre um namespace, permitindo operações CRUD em objetos sem política, como deployments, services, pods e jobs.

  Os mecanismos de isolamento do docker são aceitáveis neste cenário. Adicione Pod Security Policy (PSP) para controles extras. Para isolamento mais rigoroso, restrinja também a comunicação de services entre namespaces.

• Kubernetes as a Service (KaaS)

  A multilocação suave aplica-se ao oferecer Kubernetes as a Service (KaaS). As aplicações são hospedadas em um cluster compartilhado, com controladores e CRDs fornecendo services PaaS. Os locatários interagem diretamente com o servidor de API do Kubernetes, realizam operações CRUD em objetos sem política e podem criar e gerenciar seus próprios namespaces. Pressupõe-se que os locatários executem código não confiável.

  Isole os locatários com políticas de rede rigorosas e sandboxing de pods.

• Software as a Service (SaaS)

  Cada locatário associa-se a uma instância específica da aplicação no cluster. Cada instância possui seus próprios dados e utiliza um mecanismo de controle de acesso separado, frequentemente independente do Kubernetes RBAC.

  Os locatários não interagem diretamente com a Kubernetes API. A aplicação SaaS interage com a Kubernetes API para criar objetos para cada locatário.

Configurações nativas do Kubernetes

O Kubernetes é uma plataforma de orquestração monolocação: uma única instância do plano de controle é compartilhada entre todos os locatários. Use namespaces e RBAC para isolar logicamente os locatários, além de resource quotas e limit ranges para controlar o consumo de recursos por locatário. No entanto, o cluster é o único limite de segurança forte: um invasor com acesso ao host pode recuperar todos os secrets, configmaps e volumes nesse host, representar o Kubelet e mover-se lateralmente. As configurações a seguir mitigam esses riscos.

• Namespaces

  Os namespaces formam a base da multilocação suave e dividem um cluster em camadas lógicas. Cotas de recursos, políticas de rede, contas de service e outros recursos operam dentro do escopo do namespace.

• Autenticação, autorização e admissão

  A autorização em clusters ACK envolve duas etapas: autorização RAM e autorização RBAC. A autorização RAM controla a interface de gerenciamento do cluster, incluindo permissões CRUD como visibilidade do cluster, dimensionamento e adição de nós. A autorização RBAC controla o acesso aos recursos do Kubernetes com permissões refinadas no nível de namespace. O ACK fornece modelos de funções predefinidos, suporta a vinculação de funções de cluster definidas pelo usuário e autorização de usuários em lote. Consulte Authorization overview.

• Políticas de rede

  Por padrão, todos os pods em um cluster Kubernetes podem se comunicar entre si. Use políticas de rede para alterar esse comportamento padrão.

• As políticas de rede restringem a comunicação entre pods usando rótulos ou intervalos de endereços IP. Para isolamento rigoroso de locatários, adicione duas regras:

  • Uma regra padrão que negue a comunicação entre pods.

  • Uma regra que permita a todos os pods consultar o servidor DNS para resolução de nomes.

• Cotas de recursos e limites de intervalo

  As cotas de recursos limitam CPU, memória e contagens de recursos por cluster ou namespace. Os limites de intervalo definem valores mínimos, máximos e padrão para cada limite.

  O overcommit de recursos maximiza a utilização, mas o acesso irrestrito pode causar escassez de recursos e degradar o desempenho e a disponibilidade. Se a solicitação de um pod for muito baixa e o uso real exceder a capacidade do nó, o nó sofrerá pressão de CPU ou memória, causando reinicializações ou evicções de pods.

  Aplique cotas de recursos nos namespaces para exigir que os locatários especifiquem solicitações e limites. Isso também mitiga riscos de negação de service ao limitar o consumo de recursos por pod.

  Em cenários KaaS, use cotas de recursos para alocar recursos alinhados às necessidades dos locatários.

• Prioridade e preempção de pods

  A prioridade e a preempção de pods permitem diferentes níveis de QoS para os clientes. Pods de maior prioridade preemptam os de menor prioridade quando a capacidade é insuficiente. Em ambientes SaaS, isso atende clientes dispostos a pagar por melhor QoS.

Medidas de mitigação

Como administrador de segurança em um ambiente multilocação, seu objetivo principal é impedir que invasores acessem o host subjacente. Aplique os seguintes controles para reduzir esse risco:

• Sandboxed-Container

  O Sandboxed-Container executa aplicações em uma sandbox de máquina virtual leve com kernel independente, fornecendo isolamento mais forte do que o runtime padrão do docker.

  O Sandboxed-Container adequa-se a cenários como isolamento de aplicações não confiáveis, isolamento de falhas, isolamento de desempenho e isolamento de cargas de trabalho multiusuário. Ele tem impacto mínimo no desempenho e oferece a mesma experiência que containers docker para logs, monitoramento e elasticidade. Consulte Sandboxed-Container.

• Open Policy Agent (OPA) e Gatekeeper

  O Open Policy Agent (OPA) fornece controle refinado de políticas de acesso no nível do modelo de objeto quando o isolamento no nível de namespace do RBAC é insuficiente. O Gatekeeper é um controlador de admissão que aplica políticas OPA durante a implantação.

  O OPA também suporta políticas de rede de Camada 7 e controle de acesso entre namespaces com base em rótulos e anotações, aprimorando as políticas de rede nativas do Kubernetes.

• Kyverno

  O Kyverno é um mecanismo de políticas do Kubernetes que valida, muta e gera políticas de recursos. Ele suporta validação no estilo Kustomize e pode clonar recursos entre namespaces com base em gatilhos flexíveis.

  Use o Kyverno para isolar namespaces, implementar melhores práticas de segurança de pods e gerar configurações padrão, como políticas de rede. Consulte o repositório de políticas.

Multilocação rígida

Direções futuras

A comunidade Kubernetes reconhece as limitações da multilocação suave e os desafios da multilocação rígida. O Multi-Tenancy Special Interest Group (SIG) aborda esses desafios por meio de vários projetos de incubação:

• A proposta Virtual Cluster cria uma instância separada do plano de controle (servidor de API, gerenciador de controladores, agendador) para cada locatário, também conhecida como "Kubernetes on Kubernetes".

• A proposta Hierarchical Namespace Controller (HNC) permite relacionamentos pai-filho entre namespaces por meio da herança de objetos de política e subnamespaces gerenciados por locatários.

• A proposta Multi-Tenancy Benchmarks fornece diretrizes de isolamento de namespace e uma ferramenta CLI, Kubectl-mtb, para verificar a conformidade.