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, ovvero una singola istanza del piano di controllo è condivisa tra tutti i tenant all'interno di un cluster. Esistono, tuttavia, vari oggetti Kubernetes che puoi utilizzare per creare una parvenza di multi-tenancy. Ad esempio, i namespace e i controlli di accesso basati sui ruoli (RBAC) possono essere implementati per isolare logicamente i tenant gli uni dagli altri. Allo stesso modo, le quote e gli intervalli di limiti 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 del nodo che si spostano lateralmente all'interno del cluster. and/or
Le sezioni seguenti spiegheranno come implementare l'isolamento dei tenant mitigando al contempo i rischi dell'utilizzo di un orchestratore a tenant singolo come Kubernetes.
Soft multi-tenancy
Con la multi-tenancy software, si utilizzano costrutti Kubernetes nativi, ad esempio namespace, ruoli e associazioni di ruoli e politiche di rete, per creare una separazione logica tra i tenant. RBAC, ad esempio, può impedire ai tenant di accedere o manipolare le risorse reciproche. Le quote e gli intervalli limite controllano la quantità di risorse del cluster che ogni 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, è possibile utilizzare un selettore di nodi, regole di antiaffinità, and/or contaminazioni e tolleranze per forzare la programmazione dei pod di tenant diversi su nodi separati, spesso denominati nodi tenant unici. In un ambiente con molti tenant, questa operazione potrebbe diventare piuttosto complicata e a costi proibitivi.
Importante
La multi-tenancy soft implementata con Namespace non consente di fornire ai tenant un elenco filtrato di namespace perché i namespace sono un tipo con ambito globale. Se un tenant ha la possibilità di visualizzare un particolare namespace, può visualizzare tutti i namespace all'interno del cluster.
avvertimento
Con soft-multi-tenancy, i tenant mantengono la possibilità di interrogare CoredNS per tutti i servizi eseguiti all'interno del cluster per impostazione predefinita. Un utente malintenzionato potrebbe sfruttarlo eseguendo dig SRV
..svc.cluster.local da qualsiasi pod del cluster. Se devi limitare l'accesso ai record DNS dei servizi eseguiti all'interno dei tuoi cluster, prendi in considerazione l'utilizzo dei plugin Firewall o Policy per CoredNS. Per ulteriori informazioni, vedere policy# -policy. https://github.com/coredns/ kubernetes-metadata-multi-tenancy
Kiosk
-
Account e utenti di account per separare i tenant in un cluster Kubernetes condiviso
-
Self-Service Namespace Provisioning per gli utenti dell'account
-
Limiti dell'account per garantire la qualità del servizio e l'equità nella condivisione di un cluster
-
Modelli di namespace per l'isolamento sicuro dei tenant e l'inizializzazione self-service dello spazio dei nomi
Loft
-
Accesso multicluster per concedere l'accesso agli spazi in diversi cluster
-
La modalità Sleep riduce le implementazioni in uno spazio durante i periodi di inattività
-
Single Sign-On con provider di autenticazione OIDC come GitHub
Esistono tre casi d'uso principali che possono essere risolti con la multi-tenancy software.
Impostazioni aziendali
La prima è in un ambiente aziendale in cui gli «inquilini» sono parzialmente affidabili in quanto sono dipendenti, appaltatori o sono altrimenti autorizzati dall'organizzazione. In genere, ogni tenant si allinea a una divisione amministrativa, ad esempio 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 determinate persone viene affidata la supervisione di un namespace, che consente loro di eseguire operazioni CRUD per oggetti non correlati alle politiche come distribuzioni, servizi, pod, lavori, ecc.
L'isolamento fornito dal runtime di un container può essere accettabile all'interno di 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, la multi-tenancy soft può essere utilizzata 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 che forniscono una serie di servizi PaaS. CRDs I tenant interagiscono direttamente con il server API Kubernetes e sono autorizzati a eseguire operazioni CRUD su oggetti non conformi alle policy. Esiste 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, sarà probabilmente necessario implementare politiche di rete rigorose e il sandboxing dei pod. Il sandboxing consiste nell'eseguire i contenitori di un pod all'interno di una micro VM come Firecracker o in un kernel dello spazio utente. Oggi puoi creare pod in modalità sandbox con EKS Fargate.
Software as a Service (SaaS)
L'ultimo caso d'uso per la multi-tenancy software è in un ambiente ( Software-as-a-ServiceSaaS). 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'impostazione 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 a supportare ciascun tenant.
Kubernetes Constructs
In ognuno di questi casi vengono utilizzati i seguenti costrutti per isolare gli inquilini gli uni dagli altri:
Spazi dei nomi
I namespace sono fondamentali per l'implementazione della multi-tenancy soft. Consentono di dividere il cluster in partizioni logiche. Le quote, le politiche di rete, gli account di servizio e altri oggetti necessari per implementare la multi-tenancy rientrano nell'ambito di un namespace.
Policy di rete
Per impostazione predefinita, tutti i pod in un cluster Kubernetes possono comunicare tra loro. Questo comportamento può essere modificato utilizzando le policy 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 neghi 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. A questo punto, puoi iniziare ad aggiungere altre regole permissive che consentano la comunicazione all'interno di un namespace. Questo può essere ulteriormente perfezionato se necessario.
Nota
Amazon VPC CNI ora supporta le politiche di rete Kubernetes per creare policy
Importante
Le politiche di rete sono necessarie ma non sufficienti. L'applicazione delle politiche di rete richiede un motore di policy come Calico o Cilium.
Controllo degli accessi basato sui ruoli (RBAC)
I ruoli e le associazioni di ruolo sono gli oggetti Kubernetes utilizzati per imporre 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 specificare la quantità massima di CPU e memoria che un pod può consumare oppure puoi limitare il numero di risorse che possono essere allocate in un cluster o in un namespace. Gli intervalli di limiti consentono di dichiarare valori minimi, massimi e predefiniti per ogni limite.
L'impegno eccessivo 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 peggioramento delle prestazioni e perdita di 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 pressioni sulla CPU o sulla memoria. Quando ciò accade, i pod possono essere riavviati and/or e rimossi dal nodo.
Per evitare che ciò accada, dovreste pianificare di imporre quote ai namespace in un ambiente multi-tenant per obbligare i tenant a specificare richieste e limiti durante la pianificazione dei loro pod sul cluster. Inoltre, attenuerà una potenziale interruzione del servizio limitando la quantità di risorse che un pod può consumare.
È inoltre possibile utilizzare le quote per ripartire le risorse del cluster in base alla spesa del tenant. Ciò è particolarmente utile nello scenario KaaS.
Priorità e priorità del pod
La priorità e la priorità 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 è possibile configurare i pod del cliente A in modo che funzionino con una priorità più alta rispetto al cliente B. Quando la capacità disponibile è insufficiente, lo scheduler rimuoverà i pod con priorità più bassa 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ù elevata.
Importante
La priorità dei Pod può avere un effetto indesiderato su altri Pod con priorità inferiore. Ad esempio, anche se i pod delle vittime vengono eliminati senza problemi, ma ciò non PodDisruptionBudget è garantito, ciò potrebbe compromettere un'applicazione con priorità inferiore che si basa su un quorum di Pod, vedi Limitazioni della prelazione.
Controlli attenuanti
La tua principale preoccupazione come amministratore di un ambiente multi-tenant è impedire a un utente malintenzionato di accedere all'host sottostante. È necessario prendere in considerazione i seguenti controlli per mitigare questo rischio:
Ambienti di esecuzione in modalità sandbox per contenitori
Il sandboxing è una tecnica mediante la quale ogni contenitore viene eseguito nella propria macchina virtuale isolata. Le tecnologie che eseguono il sandboxing tramite pod includono Firecracker e Firekube
Open Policy Agent (OPA) e Gatekeeper
Gatekeeper
Esiste anche un plug-in OPA sperimentale per CoreDNS
Kyverno
Kyverno
Puoi usare Kyverno per isolare i namespace, applicare la sicurezza dei pod e altre best practice e generare configurazioni predefinite come le politiche di rete. Nel repository di questo progetto sono inclusi diversi esempi. GitHub
Isolamento dei carichi di lavoro dei tenant su nodi specifici
È possibile utilizzare la limitazione dei carichi di lavoro dei tenant affinché vengano eseguiti su nodi specifici per aumentare l'isolamento nel modello soft multi-tenancy. Con questo approccio, i carichi di lavoro specifici dei tenant vengono eseguiti solo su nodi forniti per i rispettivi tenant. Per ottenere questo isolamento, vengono utilizzate le proprietà native di Kubernetes (affinità dei nodi, fattori e tolleranze) 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à dei nodirequiredDuringSchedulingIgnoredDuringExecution nodi viene applicata al rispettivo pod. Il risultato è che il pod prenderà di mira i nodi etichettati con la seguente chiave/valore:. 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 è necessaria durante la pianificazione, ma non durante l'esecuzione; se le etichette dei nodi sottostanti cambiano, i pod non verranno rimossi esclusivamente a causa di quella modifica dell'etichetta. Tuttavia, la pianificazione futura potrebbe risentirne.
avvertimento
Il prefisso dell'etichetta node-restriction.kubernetes.io/ ha un significato speciale in Kubernetes. NodeRestrictionkubelet impedisce adding/removing/updating di etichettare con questo prefisso. Gli aggressori non sono in grado di utilizzare kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet poiché kubelet non è consentito modificare queste etichette. Se questo prefisso viene utilizzato per la pianificazione di tutta la pianificazione da pod a nodo, previene gli scenari in cui un utente malintenzionato potrebbe voler attirare un diverso set di carichi di lavoro su un nodo modificando le etichette dei nodi.
Invece dell'affinità dei nodi, avremmo potuto usare il selettore di nodi.
Parte 2 - Macchie e tolleranze
Attirare i pod verso i nodi è solo la prima parte di questo approccio in tre parti. Affinché questo approccio funzioni, dobbiamo impedire ai pod di programmarsi su nodi per i quali i pod non sono autorizzati. Per respingere i pod indesiderati o non autorizzati, Kubernetes utilizza i nodi taints.tenant: tenants-x
... taints: - key: tenant value: tenants-x effect: NoSchedule ...
Dato il nodo precedentetaint, solo i pod che tollerano la contaminazione potranno essere programmati sul nodo. Per consentire la programmazione dei pod autorizzati sul nodo, le specifiche dei rispettivi pod devono includere una toleration a to the taint, come illustrato di seguito.
... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
Ai pod con quanto sopra non toleration verrà impedito di programmare sul nodo, almeno non a causa di quella specifica contaminazione. I taint vengono utilizzati anche da Kubernetes per interrompere temporaneamente la pianificazione dei pod in determinate condizioni, come la pressione delle risorse del nodo. Grazie all'affinità tra i nodi, alle contaminazioni e alle tolleranze, possiamo attirare efficacemente i pod desiderati verso nodi specifici e respingere i pod indesiderati.
Importante
Alcuni pod Kubernetes sono necessari per funzionare su tutti i nodi. Esempi di questi pod sono quelli avviati dalla Container Network Interface (CNI) e dai daemonset kube-proxy
Parte 3 - Gestione basata su policy per la 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 effettuata anche a livello di cluster Kubernetes. A tal fine, è possibile utilizzare strumenti di gestione delle politiche per modificare le richieste del server API Kubernetes in entrata, in base ai payload delle richieste, per applicare le rispettive regole di affinità dei nodi e le tolleranze sopra menzionate.
Ad esempio, i pod destinati allo spazio dei nomi tenants-x possono essere timbrati 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.
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 di cui sopra 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 con l'etichetta. tenant: tenants-x
Una seconda politica, illustrata 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 dei pod; ciò è dovuto ai percorsi degli elementi mutati negli elementi delle policy. location È possibile scrivere politiche aggiuntive per gestire le risorse che creano pod, come le risorse Deployment e Job. Le politiche elencate e altri esempi sono disponibili nel GitHubprogetto
Il risultato di queste due mutazioni è che i baccelli sono attratti dal nodo desiderato e, allo stesso tempo, non sono respinti dalla specifica contaminazione del nodo. Per verificarlo, possiamo vedere i frammenti di output di due kubectl chiamate con cui etichettare i nodi e inserire 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, mentre gli altri pod (senza le affinità e le tolleranze richieste) no. I carichi di lavoro degli inquilini sono efficacemente isolati.
Di seguito è riportato un esempio di specifica mutata del pod.
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 ...
Importante
Gli strumenti di gestione delle policy integrati nel flusso di richieste del server dell'API Kubernetes, che utilizzano webhook di ammissione mutanti e convalidanti, sono progettati per rispondere alla richiesta del server API entro un periodo di tempo specificato. Di solito si tratta di 3 secondi o meno. Se la chiamata webhook non riesce a restituire una risposta entro il tempo configurato, la and/or convalida della mutazione della richiesta del server API in entrata può avvenire o meno. Questo comportamento dipende dal fatto che le configurazioni del webhook di ammissione siano impostate su Fail Open o Fail Close.
Negli esempi precedenti, abbiamo utilizzato 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 policy di Kyverno
Nota
Se funzionano correttamente, la modifica delle politiche influirà sulle modifiche desiderate ai payload delle richieste del server API in entrata. Tuttavia, è necessario includere anche le politiche di convalida per verificare che si verifichino le modifiche desiderate, prima che le modifiche possano persistere. Ciò è particolarmente importante quando si utilizzano queste politiche per tenant-to-node l'isolamento. È inoltre consigliabile includere politiche di controllo per verificare regolarmente la presenza di configurazioni indesiderate nel cluster.
Riferimenti
-
k-rail
Progettato per aiutarti a proteggere un ambiente multi-tenant attraverso l'applicazione di determinate politiche. -
Pratiche di sicurezza per applicazioni MultiTenant SaaS che utilizzano Amazon EKS
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 potrai condividere le risorse di elaborazione tra i cluster. Ciò alla fine causerà una frammentazione in cui un sottoinsieme dei cluster viene sottoutilizzato mentre altri vengono sovrautilizzati.
In secondo luogo, probabilmente dovrai acquistare o creare strumenti speciali per gestire tutti questi cluster. Col tempo, la gestione di centinaia o migliaia di cluster potrebbe semplicemente diventare troppo complicata.
Infine, la creazione di un cluster per tenant sarà lenta rispetto alla creazione di un namespace. Tuttavia, può essere necessario un approccio basato sulla tenancy in settori altamente regolamentati o in ambienti SaaS in cui è richiesto un forte isolamento.
Direzioni future
La community Kubernetes ha riconosciuto le attuali carenze della multi-tenancy soft e le sfide legate alla multi-tenancy rigida. Il Multi-Tenancy Special Interest Group (SIG)
La proposta HNC (KEP) descrive un modo per creare relazioni padre-figlio tra namespace con l'ereditarietà degli oggetti [policy] insieme alla possibilità per gli amministratori tenant di creare sottonamespace.
La proposta Virtual Cluster descrive un meccanismo per la creazione di 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 Multi-Tenancy Benchmarks
Strumenti e risorse per la gestione di più cluster
