Container Service for Kubernetes:Segurança em ambientes multitenant

Multitenancy suave

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

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

A multitenancy suave com namespaces não fornece aos tenants uma lista filtrada de namespaces, pois eles são recursos com escopo de cluster. Se um tenant visualizar um namespace, poderá visualizar todos os namespaces do cluster.

Por padrão, os tenants podem consultar o CoreDNS para obter informações sobre todos os serviços 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 tenant geralmente corresponde a uma unidade administrativa, como um departamento ou equipe.

  Os administradores do cluster normalmente criam namespaces e gerenciam políticas. Um modelo delegado concede permissões de supervisão a indivíduos sobre um namespace e permite operações CRUD em objetos fora de 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 serviços entre namespaces.

• Kubernetes as a Service (KaaS)

  A multitenancy 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 serviços de PaaS. Os tenants interagem diretamente com o servidor de API do Kubernetes, realizam operações CRUD em objetos fora de política e podem criar e gerenciar seus próprios namespaces. Presume-se que os tenants executem código não confiável.

  Isole os tenants com políticas de rede rigorosas e sandboxing de pods. Consulte Sandboxed-Container.

• Software as a Service (SaaS)

  Cada tenant 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 tenants não interagem diretamente com a Kubernetes API. A aplicação SaaS interage com a Kubernetes API para criar objetos para cada tenant.

Configurações nativas do Kubernetes

O Kubernetes é uma plataforma de orquestração single-tenant: uma única instância do plano de controle é compartilhada entre todos os tenants. Use namespaces e RBAC para isolar logicamente os tenants, além de resource quotas e limit ranges para controlar o consumo de recursos por tenant. 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 multitenancy suave e dividem um cluster em camadas lógicas. Cotas de recursos, políticas de rede, contas de serviço 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 Visão geral da autorização.

• 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 entre tenants, adicione duas regras:

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

  • Uma regra que permite 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, o que causará reinicializações ou evicções de pods.

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

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

• Prioridade e preempção de pods

  A prioridade e a preempção de pods permitem diferentes níveis de QoS para 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 multitenant, 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 e oferece 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 logging, 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 objetos 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, o que aprimora as políticas de rede nativas do Kubernetes.

• Kyverno

  O Kyverno é um mecanismo de políticas para 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.

Multitenancy rígida

Direções futuras

A comunidade Kubernetes reconhece as limitações da multitenancy suave e os desafios da multitenancy 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 tenant, também conhecida como "Kubernetes on Kubernetes".

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

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