Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Isolamento degli inquilini

Quando pensiamo alla multi-tenancy, spesso vogliamo isolare un utente o un'applicazione da altri utenti o applicazioni in esecuzione su un'infrastruttura condivisa.

Kubernetes è un orchestratore a tenant singolo, ossia una singola istanza del piano di controllo è condivisa tra tutti i tenant all'interno di un cluster. Esistono, tuttavia, vari oggetti Kubernetes che è possibile utilizzare per creare una parvenza di multi-tenancy. Ad esempio, i namespace e i controlli di Role-based accesso (RBAC) possono essere implementati per isolare logicamente i tenant gli uni dagli altri. Allo stesso modo, le quote e gli intervalli limite possono essere utilizzati per controllare la quantità di risorse del cluster che ogni tenant può consumare. Tuttavia, il cluster è l'unico costrutto che fornisce un solido limite di sicurezza. Questo perché un utente malintenzionato che riesce ad accedere a un host all'interno del cluster può recuperare tutti i segreti e i volumi montati su quell'host. ConfigMaps Potrebbero anche impersonare il Kubelet, il che consentirebbe loro di manipolare gli attributi dello spostamento laterale del nodo all'interno del cluster. and/or

Le sezioni seguenti spiegheranno come implementare l'isolamento dei tenant mitigando al contempo i rischi derivanti dall'utilizzo di un singolo tenant orchestrator come Kubernetes.

Multi-tenancy flessibile

Con il soft multi-tenancy, utilizzi costrutti nativi di Kubernetes, ad esempio namespace, ruoli e associazioni di ruoli e policy di rete, per creare una separazione logica tra i tenant. L'RBAC, ad esempio, può impedire ai tenant di accedere o manipolare le risorse degli altri. Le quote e gli intervalli limite controllano la quantità di risorse del cluster che ciascun tenant può consumare, mentre le politiche di rete possono aiutare a impedire che le applicazioni distribuite in namespace diversi comunichino tra loro.

Nessuno di questi controlli, tuttavia, impedisce ai pod di tenant diversi di condividere un nodo. Se è necessario un isolamento più forte, puoi utilizzare un selettore di nodi, regole anti-affinità, and/or taint e tolleranze per forzare la pianificazione dei pod di tenant diversi su nodi separati, spesso denominati nodi con tenant unici. Ciò potrebbe diventare piuttosto complicato e a costi proibitivi in un ambiente con molti tenant.

Kiosk è un progetto open source che può aiutare nell'implementazione del soft multi-tenancy. È implementato come una serie di CRD e controller che forniscono le seguenti funzionalità:

Loft è un'offerta commerciale dei manutentori di Kiosk e che aggiunge le seguenti funzionalità: DevSpace

Esistono tre casi d'uso principali che possono essere risolti con il soft multi-tenancy.

Impostazione aziendale

La prima è in un ambiente aziendale in cui gli «inquilini» sono semi-affidabili in quanto sono dipendenti, appaltatori o sono altrimenti autorizzati dall'organizzazione. In genere, ogni tenant si allinea a una divisione amministrativa come un reparto o un team.

In questo tipo di impostazione, un amministratore del cluster è in genere responsabile della creazione di namespace e della gestione delle politiche. Possono anche implementare un modello di amministrazione delegata in cui a determinati individui viene affidata la supervisione di un namespace, consentendo loro di eseguire operazioni CRUD per oggetti non correlati alle policy come implementazioni, servizi, pod, job, ecc.

L'isolamento fornito da un runtime del contenitore può essere accettabile in questa impostazione o potrebbe essere necessario aumentarlo con controlli aggiuntivi per la sicurezza dei pod. Potrebbe anche essere necessario limitare la comunicazione tra servizi in namespace diversi se è richiesto un isolamento più rigoroso.

Kubernetes come servizio

Al contrario, il soft multi-tenancy può essere utilizzato nelle impostazioni in cui si desidera offrire Kubernetes as a Service (KaaS). Con KaaS, l'applicazione è ospitata in un cluster condiviso insieme a una raccolta di controller e CRD che forniscono una serie di servizi PaaS. I tenant interagiscono direttamente con il server API Kubernetes e sono autorizzati a eseguire operazioni CRUD su oggetti non soggetti a policy. C'è anche un elemento di self-service in quanto i tenant possono essere autorizzati a creare e gestire i propri namespace. In questo tipo di ambiente, si presume che i tenant eseguano codice non attendibile.

Per isolare i tenant in questo tipo di ambiente, probabilmente dovrai implementare rigide politiche di rete e il pod sandboxing. Il sandboxing consiste nell'esecuzione dei contenitori di un pod all'interno di una micro VM come Firecracker o in un kernel in spazio utente. Oggi puoi creare pod in modalità sandbox con EKS Fargate.

Software as a Service (SaaS)

L'ultimo caso d'uso per il soft multi-tenancy è in un ambiente (SaaS). Software-as-a-Service In questo ambiente, ogni tenant è associato a una particolare istanza di un'applicazione in esecuzione all'interno del cluster. Ogni istanza ha spesso i propri dati e utilizza controlli di accesso separati che di solito sono indipendenti da Kubernetes RBAC.

A differenza degli altri casi d'uso, il tenant in un ambiente SaaS non si interfaccia direttamente con l'API Kubernetes. L'applicazione SaaS è invece responsabile dell'interfacciamento con l'API Kubernetes per creare gli oggetti necessari per supportare ciascun tenant.

Kubernetes costruisce

In ognuno di questi casi, i seguenti costrutti vengono utilizzati per isolare gli inquilini gli uni dagli altri:

Spazi dei nomi

I namespace sono fondamentali per l'implementazione di soft multi-tenancy. Consentono di suddividere il cluster in partizioni logiche. Le quote, le politiche di rete, gli account di servizio e altri oggetti necessari per implementare la multi-tenancy sono associati a un namespace.

Policy di rete

Per impostazione predefinita, tutti i pod di un cluster Kubernetes possono comunicare tra loro. Questo comportamento può essere modificato utilizzando le politiche di rete.

Le politiche di rete limitano la comunicazione tra i pod utilizzando etichette o intervalli di indirizzi IP. In un ambiente multi-tenant in cui è richiesto un rigoroso isolamento della rete tra i tenant, consigliamo di iniziare con una regola predefinita che nega la comunicazione tra i pod e un'altra regola che consenta a tutti i pod di interrogare il server DNS per la risoluzione dei nomi. Fatto ciò, puoi iniziare ad aggiungere altre regole permissive che consentano la comunicazione all'interno di un namespace. Questo può essere ulteriormente perfezionato se necessario.

Role-based controllo degli accessi (RBAC)

I ruoli e le associazioni di ruolo sono gli oggetti Kubernetes utilizzati per applicare il controllo degli accessi basato sui ruoli (RBAC) in Kubernetes. I ruoli contengono elenchi di azioni che possono essere eseguite sugli oggetti del cluster. Le associazioni di ruolo specificano gli individui o i gruppi a cui si applicano i ruoli. Nelle impostazioni aziendali e KaaS, RBAC può essere utilizzato per consentire l'amministrazione di oggetti da parte di gruppi o individui selezionati.

Quote

Le quote vengono utilizzate per definire i limiti dei carichi di lavoro ospitati nel cluster. Con le quote, puoi limitare la quantità totale di CPU e memoria che può essere consumata all'interno di un namespace o limitare il numero di oggetti che possono essere creati. Gli intervalli limite consentono di dichiarare i valori minimi, massimi e predefiniti di CPU e memoria per singoli pod e contenitori all'interno di un namespace.

L'eccessivo impegno delle risorse in un cluster condiviso è spesso utile perché consente di massimizzare le risorse. Tuttavia, l'accesso illimitato a un cluster può causare una carenza di risorse, con conseguente riduzione delle prestazioni e perdita della disponibilità delle applicazioni. Se le richieste di un pod sono impostate su un valore troppo basso e l'utilizzo effettivo delle risorse supera la capacità del nodo, il nodo inizierà a subire una pressione sulla CPU o sulla memoria. Quando ciò accade, i pod possono essere riavviati and/or e rimossi dal nodo.

Per evitare che ciò accada, dovresti pianificare di imporre delle quote sui namespace in un ambiente multi-tenant per costringere i tenant a specificare richieste e limiti durante la pianificazione dei propri pod sul cluster. Inoltre, mitigherà una potenziale negazione del servizio limitando la quantità di risorse che un pod può consumare.

Puoi anche utilizzare le quote per ripartire le risorse del cluster in modo da allinearle alla spesa di un tenant. Ciò è particolarmente utile nello scenario KaaS.

Priorità e prelazione dei pod

La priorità e la prelazione dei Pod possono essere utili quando si desidera dare maggiore importanza a un Pod rispetto agli altri Pod. Ad esempio, con la priorità dei pod puoi configurare i pod del cliente A in modo che vengano eseguiti con una priorità più alta rispetto al cliente B. Quando la capacità disponibile è insufficiente, lo scheduler rimuove i pod con priorità inferiore dal cliente B per ospitare i pod con priorità più alta del cliente A. Ciò può essere particolarmente utile in un ambiente SaaS in cui i clienti disposti a pagare un premio ricevono una priorità più alta.

Controlli attenuanti

La tua principale preoccupazione in qualità di amministratore di un ambiente multi-tenant è impedire a un utente malintenzionato di accedere all'host sottostante. Per mitigare questo rischio, è necessario prendere in considerazione i seguenti controlli:

Ambienti di esecuzione in modalità sandbox per contenitori

Il sandboxing è una tecnica mediante la quale ogni contenitore viene eseguito in una propria macchina virtuale isolata. Le tecnologie che eseguono il pod sandboxing includono Firecracker. https://firecracker-microvm.github.io/

Per ulteriori informazioni su come rendere Firecracker un runtime supportato per EKS, vedi https://threadreaderapp.com/thread/1238496944684597248.html.

Open Policy Agent (OPA) Gatekeeper &

Gatekeeper è un controller di ammissione Kubernetes che applica le policy create con OPA. https://www.openpolicyagent.org/ Con OPA puoi creare una policy che esegua i pod dei tenant su istanze separate o con una priorità più alta rispetto agli altri tenant. Una raccolta di politiche OPA comuni è disponibile nel repository di questo progetto. GitHub https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa

Esiste anche un plug-in OPA sperimentale per CoreDNS che consente di utilizzare OPA per i record restituiti da CoreDNS. filter/control

Kyverno

Kyverno è un motore di policy nativo di Kubernetes in grado di convalidare, modificare e generare configurazioni con policy come risorse Kubernetes. Kyverno utilizza Kustomize-style overlay per la convalida, supporta JSON Patch e Strategic Merge Patch per la mutazione e può clonare risorse tra namespace sulla base di trigger flessibili.

Puoi usare Kyverno per isolare i namespace, applicare la sicurezza dei pod e altre best practice e generare configurazioni predefinite come le policy di rete. Diversi esempi sono inclusi nel repository di questo progetto. GitHub https://github.com/aws/aws-eks-best-practices/tree/master/policies/kyverno Molti altri sono inclusi nella libreria delle politiche sul sito web di Kyverno.

Isolamento dei carichi di lavoro dei tenant in nodi specifici

La limitazione dei carichi di lavoro dei tenant all'esecuzione su nodi specifici può essere utilizzata per aumentare l'isolamento nel modello soft multi-tenancy. Con questo approccio, i carichi di lavoro specifici dei tenant vengono eseguiti solo su nodi di cui è stato eseguito il provisioning per i rispettivi tenant. Per ottenere questo isolamento, le proprietà native di Kubernetes (affinità dei nodi e contaminanti e tolleranze) vengono utilizzate per indirizzare nodi specifici per la pianificazione dei pod e impedire che i pod di altri tenant vengano pianificati sui nodi specifici del tenant.

Parte 1 - Affinità tra i nodi

L'affinità tra i nodi Kubernetes viene utilizzata per indirizzare i nodi per la pianificazione, in base alle etichette dei nodi. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ Con le regole di affinità dei nodi, i pod vengono attratti da nodi specifici che corrispondono ai termini del selettore. Nella specifica del pod riportata di seguito, l'affinità dei requiredDuringSchedulingIgnoredDuringExecution nodi viene applicata al rispettivo pod. Il risultato è che il pod prenderà di mira i nodi etichettati con quanto segue: 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
...

Con questa affinità tra i nodi, l'etichetta è richiesta durante la pianificazione, ma non durante l'esecuzione; se le etichette dei nodi sottostanti cambiano, i pod non verranno eliminati solo a causa di tale modifica dell'etichetta. Tuttavia, la pianificazione futura potrebbe risentirne.

Parte 2 - Macchie e tolleranze

L'attrazione dei pod verso i nodi è solo la prima parte di questo approccio in tre parti. Affinché questo approccio funzioni, dobbiamo impedire ai pod di essere programmati su nodi per i quali i pod non sono autorizzati. Per respingere i pod indesiderati o non autorizzati, Kubernetes utilizza i node taint. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ I taint vengono utilizzati per creare condizioni sui nodi che impediscono la pianificazione dei pod. Il seguente taint utilizza una coppia chiave-valore di. tenant: tenants-x

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

Dato il nodo precedentetaint, solo i pod che tollerano il taint potranno essere programmati sul nodo. Per consentire la pianificazione dei pod autorizzati sul nodo, le rispettive specifiche del pod devono includere un indicatore del taint, toleration come mostrato di seguito.

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

La programmazione dei pod con quanto sopra riportato non toleration verrà interrotta sul nodo, almeno non a causa di quel problema specifico. I taint vengono utilizzati anche da Kubernetes per interrompere temporaneamente la pianificazione dei pod in determinate condizioni, come la pressione delle risorse dei nodi. Grazie all'affinità tra i nodi, ai taint e alle tolleranze, possiamo attirare efficacemente i pod desiderati verso nodi specifici e respingere i pod indesiderati.

Parte 3: gestione Policy-based della selezione dei nodi

Esistono diversi strumenti che possono essere utilizzati per aiutare a gestire l'affinità dei nodi e le tolleranze delle specifiche dei pod, inclusa l'applicazione delle regole nelle pipeline CICD. Tuttavia, l'applicazione dell'isolamento dovrebbe essere eseguita anche a livello di cluster Kubernetes. A tal fine, è possibile utilizzare strumenti di gestione delle policy per modificare le richieste del server API Kubernetes in entrata, in base ai payload delle richieste, per applicare le rispettive regole e tolleranze di affinità tra i nodi menzionate sopra.

Ad esempio, i pod destinati allo spazio dei nomi tenants-x possono essere contrassegnati con l'affinità e la tolleranza dei nodi corrette per consentire la pianificazione sui nodi tenants-x. Utilizzando strumenti di gestione delle policy configurati utilizzando il Kubernetes Mutating Admission Webhook, è possibile utilizzare le policy per modificare le specifiche dei pod in entrata. https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook Le mutazioni aggiungono gli elementi necessari per consentire la pianificazione desiderata. Di seguito è riportato un esempio di OPA/Gatekeeper policy che aggiunge un'affinità tra i nodi.

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"

La politica precedente viene applicata a una richiesta del server API Kubernetes, per applicare un pod allo spazio dei nomi tenants-x. La policy aggiunge la regola di affinità dei requiredDuringSchedulingIgnoredDuringExecution nodi, in modo che i pod vengano attratti dai nodi contrassegnati dall'etichetta. tenant: tenants-x

Una seconda politica, mostrata di seguito, aggiunge la tolleranza alla stessa specifica del pod, utilizzando gli stessi criteri di corrispondenza dello spazio dei nomi e dei gruppi, dei tipi e delle versioni di destinazione.

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"

Le politiche di cui sopra sono specifiche per i pod; ciò è dovuto ai percorsi verso gli elementi mutati negli elementi delle policy. location È possibile scrivere policy aggiuntive per gestire le risorse che creano i pod, come le risorse Deployment e Job. Le politiche elencate e altri esempi sono disponibili nel GitHub progetto complementare a questa guida.

Il risultato di queste due mutazioni è che i baccelli vengono attratti dal nodo desiderato e, allo stesso tempo, non respinti dalla specifica colorazione del nodo. Per verificarlo, possiamo vedere i frammenti di output di due kubectl chiamate con cui vengono etichettati i nodi e ottenere i pod nel tenant=tenants-x 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...

Come possiamo vedere dagli output precedenti, tutti i pod sono programmati sui nodi etichettati con. tenant=tenants-x In poche parole, i pod funzioneranno solo sui nodi desiderati e gli altri pod (senza l'affinità e le tolleranze richieste) no. I carichi di lavoro dei tenant sono effettivamente isolati.

Di seguito è riportato un esempio di specifica del pod mutata.

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
...

Negli esempi precedenti, abbiamo utilizzato le politiche scritte per. OPA/Gatekeeper Tuttavia, esistono altri strumenti di gestione delle policy che gestiscono anche il nostro caso d'uso relativo alla selezione dei nodi. Ad esempio, questa politica di Kyverno potrebbe essere utilizzata per gestire la mutazione dell'affinità dei nodi.

Riferimenti

Multi-tenancy rigida

La multi-tenancy rigida può essere implementata fornendo cluster separati per ogni tenant. Sebbene ciò fornisca un isolamento molto forte tra gli inquilini, presenta diversi inconvenienti.

Innanzitutto, quando si hanno molti inquilini, questo approccio può diventare rapidamente costoso. Non solo dovrai pagare i costi del piano di controllo per ogni cluster, ma non sarai in grado di condividere le risorse di calcolo tra i cluster. Ciò alla fine causerà una frammentazione in cui un sottoinsieme dei cluster è sottoutilizzato mentre altri sono sovrautilizzati.

In secondo luogo, probabilmente sarà necessario acquistare o creare strumenti speciali per gestire tutti questi cluster. Col tempo, la gestione di centinaia o migliaia di cluster potrebbe diventare semplicemente troppo ingombrante.

Infine, la creazione di un cluster per tenant sarà lenta rispetto alla creazione di un namespace. Tuttavia, un approccio hard-tenancy può essere necessario in settori altamente regolamentati o in ambienti SaaS in cui è richiesto un forte isolamento.

Direzioni future

La community Kubernetes ha riconosciuto le attuali carenze del soft multi-tenancy e le sfide del multi-tenancy hard. Lo Multi-Tenancy Special Interest Group (SIG) sta cercando di risolvere queste carenze attraverso diversi progetti di incubazione, tra cui Hierarchical Namespace Controller (HNC) e Virtual Cluster.

La proposta HNC (KEP) descrive un modo per creare relazioni padre-figlio tra namespace con ereditarietà degli oggetti [policy] insieme alla possibilità per gli amministratori dei tenant di creare namespace secondari.

La proposta Virtual Cluster descrive un meccanismo per creare istanze separate dei servizi del piano di controllo, tra cui il server API, il controller manager e lo scheduler, per ogni tenant all'interno del cluster (noto anche come «Kubernetes on Kubernetes»).

La proposta di Multi-Tenancy Benchmarks fornisce linee guida per la condivisione dei cluster utilizzando namespace per l'isolamento e la segmentazione e uno strumento a riga di comando kubectl-mtb per convalidare la conformità alle linee guida.

Multi-cluster strumenti e risorse di gestione