As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Isolamento de inquilinos

Quando pensamos em multilocação, geralmente queremos isolar um usuário ou aplicativo de outros usuários ou aplicativos executados em uma infraestrutura compartilhada.

O Kubernetes é um orquestrador de locatário único, ou seja, uma única instância do plano de controle é compartilhada entre todos os locatários em um cluster. No entanto, existem vários objetos do Kubernetes que você pode usar para criar a aparência de multilocação. Por exemplo, namespaces e controles de Role-based acesso (RBAC) podem ser implementados para isolar logicamente os inquilinos uns dos outros. Da mesma forma, cotas e faixas de limite podem ser usadas para controlar a quantidade de recursos de cluster que cada locatário pode consumir. No entanto, o cluster é a única construção que fornece um forte limite de segurança. Isso ocorre porque um invasor que consegue obter acesso a um host dentro do cluster pode recuperar todos os segredos e volumes montados nesse host. ConfigMaps Eles também poderiam se passar pelo Kubelet, o que lhes permitiria manipular os atributos do nó que and/or se move lateralmente dentro do cluster.

As seções a seguir explicarão como implementar o isolamento de inquilinos e, ao mesmo tempo, reduzir os riscos de usar um único orquestrador de inquilinos, como o Kubernetes.

Multilocação flexível

Com a multilocação flexível, você usa construções nativas do Kubernetes, por exemplo, namespaces, funções e associações de função e políticas de rede, para criar uma separação lógica entre inquilinos. O RBAC, por exemplo, pode impedir que os inquilinos acessem ou manipulem os recursos uns dos outros. As cotas e os limites controlam a quantidade de recursos de cluster que cada locatário pode consumir, enquanto as políticas de rede podem ajudar a impedir que aplicativos implantados em namespaces diferentes se comuniquem entre si.

No entanto, nenhum desses controles impede que pods de diferentes locatários compartilhem um nó. Se for necessário um isolamento mais forte, você poderá usar um seletor de nós, regras antiafinidade, and/or contaminações e tolerâncias para forçar os pods de diferentes locatários a serem programados em nós separados; geralmente chamados de nós de inquilino único. Isso pode ser bastante complicado e custoso em um ambiente com muitos inquilinos.

O Kiosk é um projeto de código aberto que pode auxiliar na implementação de multilocação flexível. Ele é implementado como uma série de CRDs e controladores que fornecem os seguintes recursos:

Loft é uma oferta comercial dos mantenedores do Kiosk e DevSpace que adiciona os seguintes recursos:

Há três casos de uso principais que podem ser resolvidos por meio de multilocação flexível.

Ambiente corporativo

A primeira é em um ambiente corporativo em que os “inquilinos” são semiconfiáveis, pois são funcionários, contratados ou estão autorizados pela organização. Cada inquilino normalmente se alinhará a uma divisão administrativa, como um departamento ou equipe.

Nesse tipo de configuração, um administrador de cluster geralmente será responsável por criar namespaces e gerenciar políticas. Eles também podem implementar um modelo de administração delegada em que determinados indivíduos supervisionam um namespace, permitindo que eles realizem operações CRUD para objetos não relacionados a políticas, como implantações, serviços, pods, trabalhos etc.

O isolamento fornecido pelo tempo de execução de um contêiner pode ser aceitável nessa configuração ou pode precisar ser aumentado com controles adicionais para a segurança do pod. Também pode ser necessário restringir a comunicação entre serviços em namespaces diferentes se for necessário um isolamento mais rigoroso.

Kubernetes como serviço

Por outro lado, a multilocação flexível pode ser usada em configurações nas quais você deseja oferecer o Kubernetes como serviço (KaaS). Com o KaaS, seu aplicativo é hospedado em um cluster compartilhado junto com uma coleção de controladores e CRDs que fornecem um conjunto de serviços PaaS. Os inquilinos interagem diretamente com o servidor da API Kubernetes e têm permissão para realizar operações CRUD em objetos não relacionados à política. Há também um elemento de autoatendimento em que os inquilinos podem criar e gerenciar seus próprios namespaces. Nesse tipo de ambiente, presume-se que os locatários estejam executando código não confiável.

Para isolar os inquilinos nesse tipo de ambiente, você provavelmente precisará implementar políticas de rede rígidas, bem como o sandbox de pod. O sandboxing é onde você executa os contêineres de um pod dentro de uma micro VM como o Firecracker ou em um kernel de espaço de usuário. Hoje, você pode criar pods em sandbox com o EKS Fargate.

Software como serviço (SaaS)

O caso de uso final da multilocação flexível está em uma configuração Software-as-a-Service (SaaS). Nesse ambiente, cada locatário está associado a uma instância específica de um aplicativo em execução no cluster. Cada instância geralmente tem seus próprios dados e usa controles de acesso separados que geralmente são independentes do RBAC do Kubernetes.

Diferentemente dos outros casos de uso, o locatário em uma configuração de SaaS não interage diretamente com a API Kubernetes. Em vez disso, o aplicativo SaaS é responsável pela interface com a API Kubernetes para criar os objetos necessários para dar suporte a cada inquilino.

Construções do Kubernetes

Em cada um desses casos, as seguintes construções são usadas para isolar os inquilinos uns dos outros:

Namespaces

Os namespaces são fundamentais para implementar a multilocação flexível. Eles permitem que você divida o cluster em partições lógicas. Cotas, políticas de rede, contas de serviço e outros objetos necessários para implementar a multilocação têm como escopo um namespace.

Políticas de rede

Por padrão, todos os pods em um cluster Kubernetes podem se comunicar entre si. Esse comportamento pode ser alterado usando políticas de rede.

As políticas de rede restringem a comunicação entre pods usando rótulos ou intervalos de endereços IP. Em um ambiente multilocatário em que é necessário um isolamento estrito da rede entre os locatários, recomendamos começar com uma regra padrão que nega a comunicação entre os pods e outra regra que permite que todos os pods consultem o servidor DNS para resolução de nomes. Com isso estabelecido, você pode começar a adicionar mais regras permissivas que permitem a comunicação dentro de um namespace. Isso pode ser refinado ainda mais conforme necessário.

Role-based controle de acesso (RBAC)

Funções e associações de função são os objetos do Kubernetes usados para impor o controle de acesso baseado em funções (RBAC) no Kubernetes. As funções contêm listas de ações que podem ser executadas em objetos em seu cluster. As vinculações de função especificam os indivíduos ou grupos aos quais as funções se aplicam. Nas configurações corporativas e de KaaS, o RBAC pode ser usado para permitir a administração de objetos por grupos ou indivíduos selecionados.

Cotas

As cotas são usadas para definir limites nas cargas de trabalho hospedadas em seu cluster. Com cotas, você pode limitar a quantidade total de CPU e memória que podem ser consumidas em um namespace ou limitar o número de objetos que podem ser criados. Os intervalos de limite permitem que você declare os valores mínimo, máximo e padrão de CPU e memória para pods e contêineres individuais em um namespace.

O comprometimento excessivo de recursos em um cluster compartilhado geralmente é benéfico, pois permite maximizar seus recursos. No entanto, o acesso ilimitado a um cluster pode causar falta de recursos, o que pode levar à degradação do desempenho e à perda da disponibilidade do aplicativo. Se as solicitações de um pod forem definidas como muito baixas e a utilização real dos recursos exceder a capacidade do nó, o nó começará a sentir pressão na CPU ou na memória. Quando isso acontece, os pods podem ser reiniciados e and/or expulsos do node.

Para evitar que isso aconteça, você deve planejar a imposição de cotas aos namespaces em um ambiente multilocatário para forçar os locatários a especificar solicitações e limites ao programar seus pods no cluster. Isso também mitigará uma possível negação de serviço ao restringir a quantidade de recursos que um pod pode consumir.

Você também pode usar cotas para distribuir os recursos do cluster para alinhá-los aos gastos de um inquilino. Isso é particularmente útil no cenário KaaS.

Prioridade e preempção do pod

A prioridade e a preempção do pod podem ser úteis quando você deseja dar mais importância a um pod em relação a outros pods. Por exemplo, com a prioridade de pod, você pode configurar os pods do cliente A para serem executados com uma prioridade mais alta do que o cliente B. Quando não houver capacidade suficiente disponível, o programador removerá os pods de menor prioridade do cliente B para acomodar os pods de maior prioridade do cliente A. Isso pode ser especialmente útil em um ambiente SaaS em que os clientes dispostos a pagar um prêmio recebem uma prioridade maior.

Controles de mitigação

Sua principal preocupação como administrador de um ambiente multilocatário é impedir que um invasor tenha acesso ao host subjacente. Os seguintes controles devem ser considerados para mitigar esse risco:

Ambientes de execução em sandbox para contêineres

O sandboxing é uma técnica pela qual cada contêiner é executado em sua própria máquina virtual isolada. As tecnologias que realizam sandboxing de pods incluem o Firecracker.

Para obter informações adicionais sobre o esforço de tornar o Firecracker um tempo de execução compatível com o EKS, consulte https://threadreaderapp.com/thread/1238496944684597248.html.

Gatekeeper do Open Policy Agent (OPA) &

O Gatekeeper é um controlador de admissão do Kubernetes que impõe políticas criadas com o OPA. https://www.openpolicyagent.org/ Com o OPA, você pode criar uma política que executa pods de inquilinos em instâncias separadas ou com maior prioridade do que outros inquilinos. Uma coleção de políticas comuns de OPA pode ser encontrada no GitHub repositório deste projeto.

Há também um plugin OPA experimental para o CoreDNS que permite usar o OPA nos registros retornados filter/control pelo CoreDNS.

Kyverno

O Kyverno é um mecanismo de política nativo do Kubernetes que pode validar, alterar e gerar configurações com políticas como recursos do Kubernetes. O Kyverno usa Kustomize-style sobreposições para validação, suporta JSON Patch e patch de mesclagem estratégico para mutação e pode clonar recursos em namespaces com base em gatilhos flexíveis.

Você pode usar o Kyverno para isolar namespaces, reforçar a segurança do pod e outras práticas recomendadas e gerar configurações padrão, como políticas de rede. Vários exemplos estão incluídos no GitHub repositório desse projeto. Muitos outros estão incluídos na biblioteca de políticas no site da Kyverno.

Isolando cargas de trabalho de locatários em nós específicos

A restrição da execução de cargas de trabalho de locatários em nós específicos pode ser usada para aumentar o isolamento no modelo de multilocação flexível. Com essa abordagem, as cargas de trabalho específicas do locatário são executadas somente em nós provisionados para os respectivos inquilinos. Para alcançar esse isolamento, as propriedades nativas do Kubernetes (afinidade do nó, contaminações e tolerâncias) são usadas para direcionar nós específicos para o agendamento de pods e impedir que pods de outros inquilinos sejam programados nos nós específicos do inquilino.

Parte 1 - Afinidade do nó

A afinidade de nós do Kubernetes é usada para direcionar os nós para agendamento, com base nos rótulos dos nós. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ Com as regras de afinidade de nós, os pods são atraídos por nós específicos que correspondem aos termos do seletor. Na especificação do pod abaixo, a afinidade do requiredDuringSchedulingIgnoredDuringExecution nó é aplicada ao respectivo pod. O resultado é que o pod terá como alvo os nós rotulados com o seguinte key/value:node-restriction.kubernetes.io/tenant: tenants-x.

...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-restriction.kubernetes.io/tenant
            operator: In
            values:
            - tenants-x
...

Com essa afinidade de nó, o rótulo é necessário durante o agendamento, mas não durante a execução; se os rótulos dos nós subjacentes mudarem, os pods não serão despejados apenas devido à alteração do rótulo. No entanto, o agendamento futuro pode ser afetado.

Parte 2 - Manchas e tolerâncias

Atrair pods para os nós é apenas a primeira parte dessa abordagem em três partes. Para que essa abordagem funcione, precisamos impedir que os pods sejam programados para nós para os quais os pods não estão autorizados. Para repelir pods indesejados ou não autorizados, o Kubernetes usa contaminações de nós. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ As contaminações são usadas para colocar condições nos nós que impedem que os pods sejam programados. A mancha abaixo usa um par de valores-chave de. tenant: tenants-x

...
    taints:
      - key: tenant
        value: tenants-x
        effect: NoSchedule
...

Dado o nó acimataint, somente os pods que toleram a contaminação poderão ser programados no nó. Para permitir que os pods autorizados sejam programados no node, as respectivas especificações do pod devem incluir um “tolerationto the taint”, conforme mostrado abaixo.

...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

Os pods com os itens acima não toleration serão impedidos de serem programados no nó, pelo menos não por causa dessa mancha específica. Os contaminantes também são usados pelo Kubernetes para interromper temporariamente o agendamento de pods durante certas condições, como a pressão de recursos do nó. Com afinidade entre nós, contaminações e tolerâncias, podemos efetivamente atrair os frutos desejados para nós específicos e repelir os frutos indesejados.

Parte 3 - Policy-based gerenciamento para seleção de nós

Há várias ferramentas que podem ser usadas para ajudar a gerenciar a afinidade dos nós e as tolerâncias das especificações dos pods, incluindo a aplicação de regras nos pipelines do CICD. No entanto, a imposição do isolamento também deve ser feita no nível do cluster Kubernetes. Para isso, as ferramentas de gerenciamento de políticas podem ser usadas para alterar as solicitações de entrada do servidor da API Kubernetes, com base nas cargas de solicitação, para aplicar as respectivas regras e tolerâncias de afinidade de nós mencionadas acima.

Por exemplo, os pods destinados ao namespace tenants-x podem ser carimbados com a afinidade e a tolerância corretas do nó para permitir o agendamento nos nós tenants-x. Utilizando ferramentas de gerenciamento de políticas configuradas usando o Webhook Kubernetes Mutating Admission, as políticas podem ser usadas para alterar as especificações do pod de entrada. As mutações adicionam os elementos necessários para permitir o agendamento desejado. Um exemplo OPA/Gatekeeper de política que adiciona uma afinidade de nós é visto abaixo.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-nodeaffinity-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms"
  parameters:
    assign:
      value:
        - matchExpressions:
          - key: "tenant"
            operator: In
            values:
            - "tenants-x"

A política acima é aplicada a uma solicitação do servidor da API Kubernetes para aplicar um pod ao namespace tenants-x. A política adiciona a regra de afinidade de requiredDuringSchedulingIgnoredDuringExecution nós, para que os pods sejam atraídos por nós com o rótulo. tenant: tenants-x

Uma segunda política, vista abaixo, adiciona a tolerância à mesma especificação de pod, usando os mesmos critérios de correspondência de namespace e grupos, tipos e versões de destino.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-toleration-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.tolerations"
  parameters:
    assign:
      value:
      - key: "tenant"
        operator: "Equal"
        value: "tenants-x"
        effect: "NoSchedule"

As políticas acima são específicas para pods; isso se deve aos caminhos para os elementos mutantes nos elementos das políticaslocation. Políticas adicionais podem ser escritas para lidar com recursos que criam pods, como recursos de implantação e trabalho. As políticas listadas e outros exemplos podem ser vistos no GitHub projeto complementar deste guia.

O resultado dessas duas mutações é que os frutos são atraídos para o nódulo desejado e, ao mesmo tempo, não são repelidos pela mancha específica do nódulo. Para verificar isso, podemos ver os trechos de saída de duas kubectl chamadas para rotular os nós e obter os tenant=tenants-x pods no namespace. tenants-x

kubectl get nodes -l tenant=tenants-x
NAME
ip-10-0-11-255...
ip-10-0-28-81...
ip-10-0-43-107...

kubectl -n tenants-x get pods -owide
NAME                                  READY   STATUS    RESTARTS   AGE   IP            NODE
tenant-test-deploy-58b895ff87-2q7xw   1/1     Running   0          13s   10.0.42.143   ip-10-0-43-107...
tenant-test-deploy-58b895ff87-9b6hg   1/1     Running   0          13s   10.0.18.145   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-nxvw5   1/1     Running   0          13s   10.0.30.117   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-vw796   1/1     Running   0          13s   10.0.3.113    ip-10-0-11-255...
tenant-test-pod                       1/1     Running   0          13s   10.0.35.83    ip-10-0-43-107...

Como podemos ver nas saídas acima, todos os pods são programados nos nós rotulados com. tenant=tenants-x Simplificando, os pods funcionarão somente nos nós desejados, e os outros pods (sem a afinidade e as tolerâncias necessárias) não. As cargas de trabalho dos inquilinos são efetivamente isoladas.

Um exemplo de especificação de pod mutado é visto abaixo.

apiVersion: v1
kind: Pod
metadata:
  name: tenant-test-pod
  namespace: tenants-x
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: tenant
            operator: In
            values:
            - tenants-x
...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

Nos exemplos acima, usamos políticas escritas para OPA/Gatekeeper. No entanto, existem outras ferramentas de gerenciamento de políticas que também lidam com nosso caso de uso de seleção de nós. Por exemplo, essa política Kyverno pode ser usada para lidar com a mutação de afinidade do nó.

Referências

Multilocação rígida

A multilocação rígida pode ser implementada provisionando clusters separados para cada locatário. Embora isso ofereça um isolamento muito forte entre os inquilinos, tem várias desvantagens.

Primeiro, quando você tem muitos inquilinos, essa abordagem pode rapidamente se tornar cara. Além de pagar pelos custos do plano de controle de cada cluster, você não poderá compartilhar recursos de computação entre clusters. Eventualmente, isso causará fragmentação em que um subconjunto de seus clusters é subutilizado, enquanto outros são superutilizados.

Em segundo lugar, você provavelmente precisará comprar ou criar ferramentas especiais para gerenciar todos esses clusters. Com o tempo, gerenciar centenas ou milhares de clusters pode simplesmente se tornar muito complicado.

Finalmente, a criação de um cluster por locatário será lenta em relação à criação de um namespace. No entanto, uma abordagem de locação forçada pode ser necessária em setores altamente regulamentados ou em ambientes SaaS, onde é necessário um forte isolamento.

Direções futuras

A comunidade Kubernetes reconheceu as deficiências atuais da multilocação flexível e os desafios da multilocação rígida. O Grupo de Interesse Multi-Tenancy Especial (SIG) está tentando resolver essas deficiências por meio de vários projetos de incubação, incluindo o Hierarchical Namespace Controller (HNC) e o Virtual Cluster.

A proposta do HNC (KEP) descreve uma maneira de criar relacionamentos pai-filho entre namespaces com herança de objetos [policy], além da capacidade dos administradores de locatários criarem subnamespaces.

A proposta do Virtual Cluster descreve um mecanismo para criar instâncias separadas dos serviços do plano de controle, incluindo o servidor de API, o gerenciador do controlador e o agendador, para cada inquilino dentro do cluster (também conhecido como “Kubernetes on Kubernetes”).

A proposta da Multi-Tenancy Benchmarks fornece diretrizes para compartilhar clusters usando namespaces para isolamento e segmentação e uma ferramenta de linha de comando https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/kubectl-mtb/README.md kubectl-mtb para validar a conformidade com as diretrizes.

Multi-cluster ferramentas e recursos de gerenciamento