Protezione del motore Kubernetes

Carichi di lavoro che si sfidano reciprocamente

Al momento, si sconsiglia di eseguire carichi di lavoro non attendibili reciprocamente nello stesso cluster. Ad esempio, non eseguire i seguenti carichi di lavoro nello stesso cluster:

• Carichi di lavoro di sviluppo e di produzione
• Piano di controllo e piano dati
• Carichi di lavoro che eseguono codice cliente arbitrario

Carichi di lavoro con diversi livelli di affidabilità

Prendere in considerazione la possibilità di avere cluster separati se si dispone di più tenant, team o utenti che accedono allo stesso cluster con livelli di attendibilità diversi. Come indicato nelle sezioni successive, Kubernetes e OKE offrono metodi per isolare i carichi di lavoro. Tuttavia, questi metodi non sono attualmente sufficienti per la multi-tenancy disco rigido.

Kubelet ha accesso in lettura alle risorse

Un kubelet in esecuzione su un nodo di lavoro in un cluster creato da OKE non può modificare le risorse che non appartengono al nodo del kubelet. Per ulteriori informazioni, consulta i dettagli sul controller di ammissione NodeRestriction nella documentazione di Kubernetes.

Si noti, in particolare quando si eseguono carichi di lavoro multi-tenant, che anche se un kubelet non può modificare le risorse che non appartengono al suo nodo, il kubelet può comunque leggere tali risorse. Tali risorse possono includere:

• servizi
• endpoint
• nodi
• pod
• segreti, configmap e volumi persistenti associati al nodo del kubelet

Per ulteriori informazioni, consulta la sezione relativa all'uso dell'autorizzazione nodo nella documentazione di Kubernetes.

Compartimenti pool di nodi

I pool di nodi in un cluster possono estendersi su compartimenti. Tuttavia, sebbene l'uso di più compartimenti offra un modo conveniente per raggruppare e gestire i nodi di lavoro, non fornisce alcun isolamento tra i nodi di lavoro nel cluster. È possibile pianificare qualsiasi carico di lavoro in qualsiasi pool di nodi, indipendentemente dal compartimento. Un caso d'uso valido per l'uso di più compartimenti per un pool di nodi consiste nel creare facilmente gruppi dinamici e criteri IAM per i nodi di lavoro. Un caso d'uso non valido per più compartimenti potrebbe consistere nel mettere ogni pool di nodi in cui è in esecuzione un carico di lavoro del cliente in un compartimento separato presupponendo che i compartimenti forniscano un certo tipo di limite o isolamento di sicurezza.

Subnet pool di nodi

Si consiglia di utilizzare solo subnet private per i pool di nodi. È necessario configurare un service gateway per fornire l'accesso ai servizi Oracle Cloud Infrastructure. Non è possibile utilizzare un gateway di servizi se le subnet sono pubbliche con un gateway Internet . Se le subnet private richiedono l'accesso a Internet, utilizzare un gateway NAT .

Controllo dell'accesso ai pod dei nodi

Per impostazione predefinita, è possibile pianificare un pod in qualsiasi nodo del cluster. Kubernetes offre un rich set di criteri per il controllo del posizionamento dei pod sui nodi e il posizionamento e la rimozione dei pod basati sui tint disponibili per gli utenti finali. Per molti cluster, l'uso di questi criteri per separare i carichi di lavoro può essere una convenzione che gli autori adottano o applicano tramite gli strumenti. Questi controlli di posizionamento non sono adeguati in un ambiente multi-tenant quando gli utenti con funzionalità di distribuzione non sono attendibili. Se si dispone di utenti non attendibili che distribuiscono il codice, è necessario considerare un cluster per gruppo non attendibile.

Limita accesso fornito ai principal delle istanze

Per impostazione predefinita, tutti i pod su un nodo sono in grado di accedere ai certificati dei principal dell'istanza utilizzando l'endpoint dei metadati dell'istanza. Per evitare l'escalation dei privilegi tramite i principal delle istanze, è necessario isolare i carichi di lavoro tra pool di nodi con gruppi dinamici diversi in modo che i pod in un determinato pool di nodi abbiano il set minimo di privilegi necessari per funzionare.

Ad esempio, si supponga di disporre dei due carichi di lavoro seguenti, che richiedono entrambi un accesso diverso:

• LogArchiver: richiede l'accesso per gestire i bucket e gli oggetti nello storage degli oggetti
• HostMonitor: richiede l'accesso all'API di computazione per gestire le istanze

L'approccio più semplice consiste nel pianificarle nello stesso pool di nodi e fornire al principal dell'istanza tutto l'accesso necessario. Tuttavia, ciò aumenta l'impatto nel caso in cui uno dei carichi di lavoro venga compromesso. Un approccio migliore sarebbe quello di pianificare i carichi di lavoro su pool di nodi separati con il set limitato di accesso richiesto dai principal dell'istanza per il carico di lavoro applicabile.

Blocca accesso contenitore a metadati istanza

Il modo preferito per bloccare l'accesso è utilizzare un plugin dei criteri di rete con un criterio predefinito "nega tutto". Successivamente, concederesti esplicitamente l'accesso a pod e reti utilizzando le risorse NetworkPolicy in Kubernetes tramite i selettori di etichette. Se non si dispone di un plugin dei criteri di rete installato, è possibile utilizzare una regola IPTables per limitare l'accesso da tutti i pod sull'host. Si consiglia di non utilizzare questo approccio per bloccare un sottoinsieme di pod su un host.

Importante: la regola NetworkPolicys e la seguente regola IPTable si applicano solo ai contenitori nella rete di overlay pod. I contenitori e i servizi in esecuzione nella rete host non sono interessati da nessuna delle due opzioni:

iptables --insert FORWARD 1 --in-interface veth+ --destination 169.254.0.0/16 --jump DROP

Criteri di rete

I criteri di rete in Kubernetes consentono agli amministratori di definire in che modo i gruppi di pod sono in grado di comunicare con altri pod nel cluster. Inoltre, i criteri di rete consentono di definire il modo in cui i gruppi di pod sono in grado di comunicare con i servizi esterni al cluster (ad esempio, i servizi Oracle Cloud Infrastructure).

Per limitare l'accesso mediante criteri di rete, è necessario installare un plugin di rete. I plugin di rete configurano e applicano i criteri di rete definiti in Kubernetes. Sono disponibili numerose opzioni di plugin di rete. Puoi seguire le nostre istruzioni qui per installare e configurare Calico nel tuo cluster. I plugin dei criteri di rete funzionano limitando l'accesso all'host. Per informazioni sull'installazione di Calico in OKE, vedere Esempio: installazione di Calico e configurazione dei criteri di rete.

Liste di sicurezza del pool di nodi

Gli amministratori di rete possono definire le regole della lista di sicurezza nelle subnet del pool di nodi per limitare l'accesso ai nodi di lavoro e da essi. La definizione delle regole della lista di sicurezza consente agli amministratori di applicare limitazioni di rete che non possono essere sostituite sugli host nel cluster.

Poiché tutte le comunicazioni da pod a pod si verificano in una rete di overlay VXLAN sui nodi di lavoro, non è possibile utilizzare le regole della lista di sicurezza per limitare la comunicazione da pod a pod. Tuttavia, è possibile utilizzare le liste di sicurezza per limitare l'accesso ai nodi di lavoro e da essi.

Importante: è necessario che nelle subnet del pool di nodi esista un set minimo di regole della lista di sicurezza per garantire il funzionamento del cluster. Per informazioni sul set minimo di regole della lista di sicurezza prima di modificare le regole della lista di sicurezza, vedere Esempio di configurazioni delle risorse di rete.

Usa digest immagine anziché tag

Si consiglia di estrarre solo le immagini utilizzando i digest di immagine e di non estrarre le immagini utilizzando i tag (perché i tag di immagine sono modificabili). I digest immagine sono il digest sha256 dell'immagine, che consente al docker di verificare che l'immagine scaricata sia quella prevista.

Esempio di ID digest immagine:

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Trascinare l'immagine come mostrato nell'esempio riportato di seguito.

docker pull acme@sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

È possibile utilizzare il seguente comando per visualizzare tutti i digest per le immagini locali:

docker images --digests

Limita utilizzo risorse

La quota risorsa limita il numero o la capacità delle risorse concesse a uno spazio di nomi. Questo viene spesso utilizzato per limitare la quantità di CPU, memoria o disco persistente che uno spazio di nomi può allocare, ma può anche controllare quanti pod, servizi o volumi esistono in ogni spazio di nomi.

Limita intervalli limita la dimensione massima o minima di alcune delle risorse precedenti, per evitare che gli utenti richiedano valori irragionevolmente alti o bassi per risorse comunemente riservate come la memoria o per fornire limiti predefiniti quando non ne viene specificata alcuna.

L'accesso alle quote delle risorse può essere limitato tramite i criteri RBAC in Kubernetes. Ciò può aiutare un amministratore a garantire che gli utenti di un cluster non siano in grado di utilizzare risorse a cui non dovrebbero avere accesso. Per ulteriori informazioni, consulta la sezione Limitazione dell'uso delle risorse in un cluster nella documentazione di Kubernetes.