Sicurezza Pod - Amazon EKS
Funzionalità LinuxSoluzioni di sicurezza PodRaccomandazioniStrumenti e risorse

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

Sicurezza Pod

Le specifiche del pod includono una varietà di attributi diversi che possono rafforzare o indebolire il livello di sicurezza generale. In qualità di professionista di Kubernetes, la tua preoccupazione principale dovrebbe essere impedire che un processo in esecuzione in un container sfugga ai limiti di isolamento del runtime del container e ottenga l'accesso all'host sottostante.

Funzionalità Linux

Per impostazione predefinita, i processi eseguiti all'interno di un contenitore vengono eseguiti nel contesto dell'utente root [Linux]. Sebbene le azioni di root all'interno di un contenitore siano parzialmente limitate dall'insieme di funzionalità Linux che il runtime del contenitore assegna ai contenitori, questi privilegi predefiniti potrebbero consentire a un utente malintenzionato di aumentare i propri privilegi e/o accedere a informazioni sensibili legate all'host, inclusi Secrets e. ConfigMaps Di seguito è riportato un elenco delle funzionalità predefinite assegnate ai contenitori. Per ulteriori informazioni su ciascuna funzionalità, consulta http://man7. org/linux/man-pages/man7/capabilities.7.html.

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 e ai pod Fargate vengono assegnate le funzionalità sopra menzionate per impostazione predefinita. Inoltre, le funzionalità Linux possono essere eliminate solo dai pod Fargate.

I pod eseguiti con privilegi ereditano tutte le funzionalità Linux associate al root sull'host. Questo dovrebbe essere evitato se possibile.

Autorizzazione dei nodi

Tutti i nodi di lavoro Kubernetes utilizzano una modalità di autorizzazione chiamata Node Authorization. Node Authorization autorizza tutte le richieste API che provengono dal kubelet e consente ai nodi di eseguire le seguenti azioni:

Operazioni di lettura:

  • services

  • endpoint

  • nodi

  • baccelli

  • segreti, mappe di configurazione, dichiarazioni di volume persistenti e volumi persistenti relativi ai pod legati al nodo di Kubelet

Operazioni di scrittura:

  • nodi e stato del nodo (abilita il plugin di NodeRestriction ammissione per limitare un kubelet a modificare il proprio nodo)

  • pods e pod status (abilita il plugin di NodeRestriction ammissione per limitare un kubelet a modificare i pod legati a se stesso)

  • events

Operazioni relative all'autenticazione:

  • Accesso in lettura/scrittura all'API CertificateSigningRequest (CSR) per il bootstrap TLS

  • la capacità di creare e per controlli delegati TokenReview SubjectAccessReview authentication/authorization

EKS utilizza il controller di ammissione delle restrizioni del nodo che consente al nodo di modificare solo un insieme limitato di attributi del nodo e oggetti pod associati al nodo. Tuttavia, un utente malintenzionato che riesce ad accedere all'host sarà comunque in grado di raccogliere informazioni sensibili sull'ambiente dall'API Kubernetes che potrebbero consentirgli di spostarsi lateralmente all'interno del cluster.

Soluzioni di sicurezza Pod

Politica di sicurezza Pod (PSP)

In passato, le risorse Pod Security Policy (PSP) venivano utilizzate per specificare una serie di requisiti che i pod dovevano soddisfare prima di poter essere creati. A partire dalla versione 1.21 di Kubernetes, PSP è diventata obsoleta. La loro rimozione è prevista nella versione 1.25 di Kubernetes.

Importante

PSPs sono obsoleti nella versione 1.21 di Kubernetes. Avrai tempo fino alla versione 1.25 o circa 2 anni per passare a un'alternativa. Questo documento spiega la motivazione di questa deprecazione.

Migrazione a una nuova soluzione di sicurezza dei pod

Poiché PSPs sono stati rimossi a partire dalla versione 1.25 di Kubernetes, gli amministratori e gli operatori del cluster devono sostituire tali controlli di sicurezza. Due soluzioni possono soddisfare questa esigenza:

Entrambe le soluzioni PAC e PSS possono coesistere con PSP; possono essere utilizzate in cluster prima che PSP venga rimossa. Questo facilita l'adozione durante la migrazione da PSP. Consulta questo documento per valutare la migrazione da PSP a PSS.

Kyverno, una delle soluzioni PAC descritte di seguito, ha fornito linee guida specifiche in un post sul blog per la migrazione dalla sua soluzione, che includono politiche analoghe, PSPs confronti di funzionalità e una procedura di migrazione. Ulteriori informazioni e linee guida sulla migrazione a Kyverno rispetto a Pod Security Admission (PSA) sono state pubblicate sul blog di AWS qui.

Policy-as-code (PAC)

Policy-as-code Le soluzioni (PAC) forniscono barriere per guidare gli utenti del cluster e prevenire comportamenti indesiderati, attraverso controlli prescritti e automatizzati. PAC utilizza i Kubernetes Dynamic Admission Controller per intercettare il flusso di richieste del server dell'API Kubernetes, tramite una chiamata webhook, e modificare e convalidare i payload delle richieste, in base a policy scritte e archiviate come codice. La mutazione e la convalida avvengono prima che la richiesta del server API comporti una modifica al cluster. Le soluzioni PAC utilizzano politiche per abbinare e agire sui payload delle richieste del server API, in base alla tassonomia e ai valori.

Sono disponibili diverse soluzioni PAC open source per Kubernetes. Queste soluzioni non fanno parte del progetto Kubernetes, ma provengono dall'ecosistema Kubernetes. Alcune soluzioni PAC sono elencate di seguito.

Per ulteriori informazioni sulle soluzioni PAC e su come aiutarvi a scegliere la soluzione appropriata per le vostre esigenze, consultate i collegamenti seguenti.

Pod Security Standards (PSS) e Pod Security Admission (PSA)

In risposta all'obsolescenza della PSP e alla continua necessità di controllare la sicurezza dei pod out-of-the-box, con una soluzione Kubernetes integrata, il Kubernetes Auth Special Interest Group ha creato i Pod Security Standards (PSS) e Pod Security Admission (PSA). L'iniziativa PSA include un progetto webhook per i controller di ammissione che implementa i controlli definiti nel PSS. Questo approccio basato sul controller di ammissione è simile a quello utilizzato nelle soluzioni PAC.

Secondo la documentazione di Kubernetes, il PSS «definisce tre diverse politiche per coprire ampiamente lo spettro della sicurezza. Queste politiche sono cumulative e vanno da quelle altamente permissive a quelle altamente restrittive. `»

Queste politiche sono definite come:

  • Privilegiato: politica senza restrizioni (non sicura), che fornisce il livello di autorizzazioni più ampio possibile. Questa politica consente l'aumento dei privilegi noto. È l'assenza di una politica. Ciò è utile per applicazioni come agenti di registrazione CNIs, driver di archiviazione e altre applicazioni a livello di sistema che richiedono un accesso privilegiato.

  • Linea di base: politica minimamente restrittiva che impedisce l'aumento dei privilegi noti. Consente la configurazione Pod predefinita (specificata in modo minimo). La politica di base vieta l'uso di HostNetwork, HostPID, HostIPC, HostPath, HostPort, l'impossibilità di aggiungere funzionalità Linux e diverse altre restrizioni.

  • Limitato: politica fortemente limitata, che segue le attuali best practice di rafforzamento dei Pod. Questa politica eredita dalla linea di base e aggiunge ulteriori restrizioni, come l'impossibilità di essere eseguita come root o come gruppo root. Le politiche limitate possono influire sulla capacità di funzionamento di un'applicazione. Sono principalmente destinate all'esecuzione di applicazioni critiche per la sicurezza.

Queste policy definiscono i profili per l'esecuzione dei pod, disposti in tre livelli di accesso privilegiato e limitato.

Per implementare i controlli definiti dal PSS, PSA opera in tre modalità:

  • imporre: le violazioni delle norme comporteranno il rifiuto del pod.

  • audit: le violazioni delle politiche attiveranno l'aggiunta di un'annotazione di controllo all'evento registrato nel registro di controllo, ma sono altrimenti consentite.

  • avviso: le violazioni delle norme attiveranno un avviso rivolto all'utente, ma sono altrimenti consentite.

Queste modalità e i livelli di profilo (restrizione) sono configurati a livello di Kubernetes Namespace, utilizzando etichette, come illustrato nell'esempio seguente.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

Se utilizzate indipendentemente, queste modalità operative hanno risposte diverse che si traducono in esperienze utente diverse. La modalità enforce impedirà la creazione di pod se le rispettive PodSpecs violano il livello di restrizione configurato. Tuttavia, in questa modalità, non verrà impedito l'applicazione al cluster di oggetti Kubernetes diversi dai pod che creano pod, come Deployments, anche se il PodSpec viola il PSS applicato. In questo caso verrà applicata la distribuzione, mentre verrà impedita l'applicazione dei pod.

Si tratta di un'esperienza utente difficile, in quanto non vi è alcuna indicazione immediata che l'oggetto Deployment applicato correttamente smentisca la mancata creazione del pod. Il PodSpecs offensivo non creerà pod. L'ispezione della risorsa Deployment con kubectl get deploy <DEPLOYMENT_NAME> -oyaml mostrerà il messaggio proveniente dall'.status.conditionselemento (i) pod (i) fallito, come illustrato di seguito.

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

In entrambe le modalità di controllo e di avviso, le restrizioni relative ai pod non impediscono la creazione e l'avvio di pod che violano le norme. Tuttavia, in queste modalità, le annotazioni di controllo sugli eventi del registro di controllo del server API e gli avvisi ai client del server API, come kubectl, vengono attivati, rispettivamente, quando i pod, così come gli oggetti che creano i pod, contengono PodSpecs con violazioni. kubectlDi seguito viene visualizzato un messaggio di avviso.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

Le modalità di controllo e avviso PSA sono utili per introdurre il PSS senza influire negativamente sulle operazioni del cluster.

Le modalità operative PSA non si escludono a vicenda e possono essere utilizzate in modo cumulativo. Come illustrato di seguito, le modalità multiple possono essere configurate in un unico namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Nell'esempio precedente, gli avvisi e le annotazioni di controllo di facile utilizzo vengono forniti quando si applicano Deployments, mentre l'applicazione delle violazioni viene fornita anche a livello di pod. In effetti, più etichette PSA possono utilizzare diversi livelli di profilo, come illustrato di seguito.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Nell'esempio precedente, PSA è configurato per consentire la creazione di tutti i pod che soddisfano il livello di profilo di base e quindi avvisa i pod (e gli oggetti che creano pod) che violano il livello di profilo limitato. Si tratta di un approccio utile per determinare i possibili impatti quando si passa dai profili di base a quelli con restrizioni.

Pod esistenti

Se uno spazio dei nomi con pod esistenti viene modificato per utilizzare un profilo PSS più restrittivo, le modalità audit e warn produrranno messaggi appropriati; tuttavia, la modalità enforce non eliminerà i pod. I messaggi di avviso sono riportati di seguito.

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

Esenzioni

PSA utilizza le esenzioni per escludere l'applicazione di violazioni ai pod che altrimenti sarebbero state applicate. Queste esenzioni sono elencate di seguito.

  • Nomi utente: le richieste degli utenti con un nome utente autenticato (o impersonato) esente vengono ignorate.

  • RuntimeClassNames: i pod e le risorse del carico di lavoro che specificano un nome di classe runtime esente vengono ignorati.

  • Namespace: i pod e le risorse del carico di lavoro in uno spazio dei nomi esente vengono ignorati.

Queste esenzioni vengono applicate staticamente nella configurazione del controller di ammissione PSA come parte della configurazione del server API.

Nell'implementazione Validating Webhook, le esenzioni possono essere configurate all'interno di una ConfigMaprisorsa Kubernetes che viene montata come volume nel contenitore. pod-security-webhook

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

Come illustrato nello ConfigMap YAML precedente, il livello PSS predefinito a livello di cluster è stato impostato su limitato per tutte le modalità PSA, audit, enforce e warn. Ciò influisce su tutti i namespace, ad eccezione di quelli esentati:. namespaces: ["kube-system","policy-test1"] Inoltre, nella ValidatingWebhookConfigurationrisorsa, vista di seguito, anche lo spazio dei pod-security-webhooknomi è esente dal PSS configurato.

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...
Importante

Pod Security Admissions è diventato stabile in Kubernetes v1.25. Se volevi utilizzare la funzionalità Pod Security Admission prima che fosse abilitata per impostazione predefinita, dovevi installare il controller di ammissione dinamico (webhook mutante). Le istruzioni per l'installazione e la configurazione del webhook sono disponibili qui.

Scelta tra policy-as-code e Pod Security Standards

I Pod Security Standards (PSS) sono stati sviluppati per sostituire la Pod Security Policy (PSP), fornendo una soluzione integrata in Kubernetes e che non richiedeva soluzioni dell'ecosistema Kubernetes. Detto questo, le soluzioni policy-as-code (PAC) sono notevolmente più flessibili.

Il seguente elenco di pro e contro è stato progettato per aiutarti a prendere una decisione più informata sulla tua soluzione di sicurezza per i pod.

Policy-as-code (rispetto agli standard di sicurezza dei Pod)

Vantaggi:

  • Più flessibile e più granulare (fino agli attributi delle risorse, se necessario)

  • Non si concentra solo sui pod, ma può essere utilizzato per diverse risorse e azioni

  • Non solo applicato a livello di namespace

  • Più maturo degli standard di sicurezza Pod

  • Le decisioni possono basarsi su qualsiasi elemento presente nel payload della richiesta del server API, nonché sulle risorse del cluster esistenti e sui dati esterni (a seconda della soluzione)

  • Supporta la modifica delle richieste del server API prima della convalida (dipende dalla soluzione)

  • Può generare policy complementari e risorse Kubernetes (a seconda della soluzione). Dalle policy dei pod, Kyverno può generare automaticamente policy per controller di livello superiore, come Deployments. Kyverno può anche generare risorse Kubernetes aggiuntive «`quando viene creata una nuova risorsa o quando la fonte viene aggiornata`» utilizzando Generate Rules.)

  • Può essere utilizzato per spostarsi a sinistra, nelle pipeline CICD, prima di effettuare chiamate al server API Kubernetes (dipende dalla soluzione)

  • Può essere utilizzato per implementare comportamenti che non sono necessariamente correlati alla sicurezza, come le migliori pratiche, gli standard organizzativi, ecc.

  • Può essere utilizzato in casi d'uso non Kubernetes (dipende dalla soluzione)

  • Grazie alla flessibilità, l'esperienza utente può essere adattata alle esigenze degli utenti

Contro:

  • Non integrato in Kubernetes

  • Più complesso da apprendere, configurare e supportare

  • La redazione delle politiche potrebbe richiedere nuove skills/languages/capabilities

Pod Security Admission (rispetto a policy-as-code)

Vantaggi:

  • Integrato in Kubernetes

  • Più semplice da configurare

  • Nessuna nuova lingua da usare o regole da creare

  • Se il livello di ammissione predefinito del cluster è configurato su privilegiato, è possibile utilizzare le etichette dei namespace per inserire i namespace nei profili di sicurezza dei pod.

Contro:

  • Non così flessibile o granulare come policy-as-code

  • Solo 3 livelli di restrizioni

  • Concentrato principalmente sui pod

Riepilogo

Se al momento non disponete di una soluzione di sicurezza per i pod, oltre a PSP, e la configurazione di sicurezza dei pod richiesta corrisponde al modello definito nei Pod Security Standards (PSS), allora una soluzione più semplice potrebbe essere quella di adottare il PSS al posto di una soluzione. policy-as-code Tuttavia, se la posizione di sicurezza dei tuoi pod non si adatta al modello PSS o prevedi di aggiungere controlli aggiuntivi, oltre a quelli definiti da PSS, una policy-as-code soluzione sembrerebbe più adatta.

Raccomandazioni

Utilizza più modalità Pod Security Admission (PSA) per una migliore esperienza utente

Come accennato in precedenza, la modalità PSA enforce impedisce l'applicazione di pod con violazioni PSS, ma non blocca i controller di livello superiore, come Deployments. In effetti, il Deployment verrà applicato correttamente senza alcuna indicazione che i pod non siano stati applicati. Sebbene sia possibile utilizzare kubectl per ispezionare l'oggetto Deployment e scoprire il messaggio relativo ai pod non riusciti inviato dal PSA, l'esperienza utente potrebbe essere migliore. Per migliorare l'esperienza dell'utente, è necessario utilizzare più modalità PSA (audit, enforce, warn).

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Nell'esempio precedente, con la modalità enforce definita, quando si tenta di applicare un manifesto di distribuzione con violazioni PSS nel rispettivo PodSpec al server dell'API Kubernetes, il Deployment verrà applicato correttamente, ma i pod no. Inoltre, poiché sono abilitate anche le modalità di controllo e avviso, il client del server API riceverà un messaggio di avviso e anche l'evento del registro di controllo del server API verrà annotato con un messaggio.

Limita i contenitori che possono essere eseguiti come privilegiati

Come accennato, i contenitori che funzionano con privilegi ereditano tutte le funzionalità Linux assegnate a root sull'host. Raramente i contenitori necessitano di questo tipo di privilegi per funzionare correttamente. Esistono diversi metodi che possono essere utilizzati per limitare le autorizzazioni e le funzionalità dei contenitori.

Importante

Fargate è un tipo di lancio che consente di eseguire container «serverless» in cui i contenitori di un pod vengono eseguiti sull'infrastruttura gestita da AWS. Con Fargate, non è possibile eseguire un contenitore privilegiato o configurare il pod per utilizzare HostNetwork o HostPort.

Non eseguite i processi nei contenitori come root

Per impostazione predefinita, tutti i contenitori vengono eseguiti come root. Ciò potrebbe essere problematico se un utente malintenzionato è in grado di sfruttare una vulnerabilità dell'applicazione e ottenere l'accesso tramite shell al contenitore in esecuzione. È possibile mitigare questo rischio in diversi modi. Innanzitutto, rimuovendo la shell dall'immagine del contenitore. In secondo luogo, aggiungendo la direttiva USER al Dockerfile o eseguendo i contenitori nel pod come utente non root. Kubernetes PodSpec include una serie di campi, inspec.securityContext, che consentono di specificare il gruppo di utenti and/or in base al quale eseguire l'applicazione. Questi campi sono e rispettivamente. runAsUser runAsGroup

Per imporre l'uso dispec.securityContext, e dei relativi elementi associati, all'interno di Kubernetes PodSpec, è possibile aggiungere ai cluster gli standard di sicurezza policy-as-code Pod. Queste soluzioni consentono di scrivere e/o utilizzare policy o profili in grado di convalidare i payload delle richieste del server API Kubernetes in entrata, prima che vengano mantenuti in etcd. Inoltre, policy-as-code le soluzioni possono modificare le richieste in entrata e, in alcuni casi, generare nuove richieste.

Non eseguire mai Docker in Docker o montare il socket nel contenitore

Sebbene ciò consenta di accedere comodamente alle build/run immagini nei contenitori Docker, in pratica stai cedendo il controllo completo del nodo al processo in esecuzione nel contenitore. Se devi creare immagini di container su Kubernetes, usa invece Kaniko, buildah o un servizio di compilazione simile. CodeBuild

Nota

I cluster Kubernetes utilizzati per l'elaborazione CICD, come la creazione di immagini di container, devono essere isolati dai cluster che eseguono carichi di lavoro più generalizzati.

Limita l'uso di HostPath o, se necessario, limita i prefissi che possono essere utilizzati e configura il volume come di sola lettura

hostPathè un volume che monta una directory dall'host direttamente al contenitore. Raramente i pod necessitano di questo tipo di accesso, ma in tal caso è necessario essere consapevoli dei rischi. Per impostazione predefinita, i pod eseguiti come root avranno accesso in scrittura al file system esposto da HostPath. Ciò potrebbe consentire a un utente malintenzionato di modificare le impostazioni di kubelet, creare collegamenti simbolici a directory o file non esposti direttamente da HostPath, ad esempio /etc/shadow, installare chiavi ssh, leggere segreti montati sull'host e altre cose dannose. Per mitigare i rischi di HostPath, configura l'as, ad esempio: spec.containers.volumeMounts readOnly

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

È inoltre necessario utilizzare policy-as-code soluzioni per limitare le directory che possono essere utilizzate dai hostPath volumi o hostPath impedirne del tutto l'utilizzo. È possibile utilizzare le politiche Pod Security Standards Baseline o Restricted per impedire l'uso di. hostPath

Per ulteriori informazioni sui pericoli dell'escalation privilegiata, leggi il blog di Seth Art Bad Pods: Kubernetes Pod Privilege Escalation.

Imposta richieste e limiti per ogni contenitore per evitare contese di risorse e attacchi DoS

Un pod senza richieste o limiti può teoricamente consumare tutte le risorse disponibili su un host. Poiché su un nodo sono programmati pod aggiuntivi, il nodo potrebbe subire una pressione della CPU o della memoria che può causare la chiusura di Kubelet o l'eliminazione dei pod dal nodo. Sebbene non sia possibile evitare che ciò accada del tutto, l'impostazione di richieste e limiti aiuterà a ridurre al minimo il conflitto di risorse e a mitigare il rischio derivante da applicazioni scritte male che consumano una quantità eccessiva di risorse.

podSpecConsente di specificare richieste e limiti per CPU e memoria. La CPU è considerata una risorsa comprimibile perché può essere sottoposta a sottoscrizioni eccessive. La memoria è incomprimibile, cioè non può essere condivisa tra più contenitori.

Quando si specificano richieste di CPU o memoria, si indica essenzialmente la quantità di memoria che i contenitori hanno la garanzia di ottenere. Kubernetes aggrega le richieste di tutti i contenitori in un pod per determinare su quale nodo programmare il pod. Se un contenitore supera la quantità di memoria richiesta, può essere soggetto a chiusura in caso di pressione della memoria sul nodo.

I limiti sono la quantità massima di risorse di CPU e memoria che un contenitore può consumare e corrispondono direttamente al memory.limit_in_bytes valore del cgroup creato per il contenitore. Un contenitore che supera il limite di memoria verrà eliminato da OOM. Se un contenitore supera il limite di CPU, verrà limitato.

Nota

Quando si utilizza il contenitoreresources.limits, si consiglia vivamente che l'utilizzo delle risorse del contenitore (noto anche come Resource Footprints) sia basato sui dati e accurato, in base ai test di carico. In assenza di un ingombro preciso e affidabile delle risorse, il contenitore può essere imbottito. resources.limits Ad esempio, resources.limits.memory potrebbe essere aggiunto un riempimento superiore del 20-30% rispetto ai valori massimi osservabili, per tenere conto di potenziali imprecisioni nei limiti delle risorse di memoria.

Kubernetes utilizza tre classi Quality of Service (QoS) per dare priorità ai carichi di lavoro in esecuzione su un nodo. Ciò include:

  • garantito

  • scoppiabile

  • miglior sforzo

Se i limiti e le richieste non sono impostati, il pod viene configurato come best-effort (priorità più bassa). I pod Best-Effort sono i primi a morire quando la memoria è insufficiente. Se i limiti sono impostati su tutti i contenitori all'interno del pod o se le richieste e i limiti sono impostati sugli stessi valori e non sono uguali a 0, il pod viene configurato come garantito (priorità massima). I pod garantiti non verranno eliminati a meno che non superino i limiti di memoria configurati. Se i limiti e le richieste sono configurati con valori diversi e non uguali a 0, o se un contenitore all'interno del pod impone dei limiti e gli altri no o hanno limiti impostati per risorse diverse, i pod vengono configurati come burstable (priorità media). Questi pod offrono alcune garanzie in termini di risorse, ma possono essere eliminati quando superano la memoria richiesta.

Importante

Le richieste non influiscono sul memory_limit_in_bytes valore del cgroup del contenitore; il limite di cgroup è impostato sulla quantità di memoria disponibile sull'host. Tuttavia, se il valore delle richieste viene impostato su un valore troppo basso, il pod potrebbe essere interrotto dal kubelet se il nodo è sottoposto a una pressione di memoria.

Classe Priorità Condizione Condizione di uccisione

Garantita

più elevato

limite = richiesta! = 0

Supera solo i limiti di memoria

Scoppibile

medium

limite! = richiesta! = 0

Può essere ucciso se supera la memoria richiesta

Miglior sforzo

il più basso

limite e richiesta non impostati

Il primo a farsi uccidere quando la memoria è insufficiente

Per ulteriori informazioni sul QoS delle risorse, consulta la documentazione di Kubernetes.

Puoi forzare l'uso di richieste e limiti impostando una quota di risorse su un namespace o creando un intervallo di limiti. Una quota di risorse consente di specificare la quantità totale di risorse, ad esempio CPU e RAM, allocate a un namespace. Quando viene applicata a un namespace, ti obbliga a specificare richieste e limiti per tutti i contenitori distribuiti in quel namespace. Al contrario, gli intervalli di limiti offrono un controllo più granulare dell'allocazione delle risorse. Con gli intervalli di limiti è possibile impostare min/max le risorse di CPU e memoria per pod o per contenitore all'interno di un namespace. Puoi anche usarli per impostare valori di richiesta/limite predefiniti se non ne vengono forniti.

Policy-as-code è possibile utilizzare soluzioni per applicare richieste e limiti. o persino per creare quote di risorse e intervalli di limiti quando vengono creati i namespace.

Non consentite un'escalation privilegiata

L'escalation privilegiata consente a un processo di modificare il contesto di sicurezza in cui viene eseguito. Sudo ne è un buon esempio, così come i binari con bit SUID o SGID. L'escalation privilegiata è fondamentalmente un modo per gli utenti di eseguire un file con le autorizzazioni di un altro utente o gruppo. È possibile impedire a un contenitore di utilizzare l'escalation privilegiata implementando una policy policy-as-code mutante che imposta o impostando su. allowPrivilegeEscalation false securityContext.allowPrivilegeEscalation podSpec Policy-as-code i criteri possono essere utilizzati anche per impedire che le richieste del server API abbiano esito positivo se vengono rilevate impostazioni errate. Gli standard di sicurezza dei pod possono essere utilizzati anche per impedire ai pod di utilizzare l'escalation dei privilegi.

ServiceAccount Disabilita i supporti dei token

Per i pod che non devono accedere all'API Kubernetes, puoi disabilitare il montaggio automatico di un ServiceAccount token su una specifica del pod o per tutti i pod che ne utilizzano una particolare. ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Disabilita il rilevamento dei servizi

Per i pod che non devono cercare o chiamare servizi interni al cluster, puoi ridurre la quantità di informazioni fornite a un pod. È possibile impostare la policy DNS del pod in modo che non utilizzi CoredNS e non esponga i servizi nello spazio dei nomi del pod come variabili di ambiente. Consulta i documenti di Kubernetes sulle variabili di ambiente per ulteriori informazioni sui collegamenti ai servizi. Il valore predefinito per la policy DNS di un pod è "ClusterFirst" che utilizza il DNS interno al cluster, mentre il valore non predefinito «Default» utilizza la risoluzione DNS del nodo sottostante. Per ulteriori informazioni, consulta i documenti di Kubernetes sulla politica DNS di Pod.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

Configura le tue immagini con un file system root di sola lettura

La configurazione delle immagini con un file system root di sola lettura impedisce a un utente malintenzionato di sovrascrivere un file binario sul file system utilizzato dall'applicazione. Se l'applicazione deve scrivere sul file system, prendete in considerazione la possibilità di scrivere in una directory temporanea o di allegare e montare un volume. Puoi imporlo impostando i pod SecurityContext come segue:

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code e gli standard di sicurezza dei Pod possono essere utilizzati per imporre questo comportamento.

In base a Windows, i contenitori in Kubernetes securityContext.readOnlyRootFilesystem non possono essere impostati su quelli in esecuzione su Windows, poiché è necessario l'accesso in scrittura per l'esecuzione dei processi di registro e di sistema all'interno del contenitore. true

Strumenti e risorse