Pod Security

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

EC2e 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 API richieste 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 a () per il bootstrap CertificateSigningRequest CSR API TLS

• la capacità di creare TokenReview e per controlli di autenticazione/autorizzazione delegati SubjectAccessReview

EKSutilizza il controller di ammissione alla restrizione 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 da Kubernetes API 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, sono state dichiarate obsolete. PSP La loro rimozione è prevista nella versione 1.25 di Kubernetes.

Importante

PSPssono 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:

• Policy-as-code (PAC) soluzioni dell'ecosistema Kubernetes

• Standard di sicurezza Kubernetes Pod () PSS

Entrambe le PSS soluzioni PAC e possono coesistere conPSP; possono essere utilizzate nei cluster prima di essere rimosse. PSP Ciò facilita l'adozione durante la migrazione da. PSP Consulta questo documento quando consideri la migrazione da a. PSP PSS

Kyverno, una delle PAC soluzioni descritte di seguito, fornisce linee guida specifiche delineate in un post sul blog PSPs per la migrazione dalla sua soluzione, tra cui politiche analoghe, 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 qui. AWS

Policy-as-code (PAC)

Policy-as-code (PAC) le soluzioni forniscono barriere per guidare gli utenti del cluster e prevenire comportamenti indesiderati, attraverso controlli prescritti e automatizzati. PACutilizza i Kubernetes Dynamic Admission Controller per intercettare il flusso di richieste del API server 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 comporti una modifica al cluster. API PACle soluzioni utilizzano politiche per abbinare e agire sui payload delle richieste API del server, in base alla tassonomia e ai valori.

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

• OPA/Gatekeeper

• Open Policy Agent () OPA

• Kyverno

• Kubewarden

• jsPolicy

Per ulteriori informazioni sulle PAC soluzioni e su come aiutarvi a scegliere la soluzione più adatta alle vostre esigenze, consultate i collegamenti riportati di seguito.

• Contromisure basate su politiche per Kubernetes — Parte 1

• Contromisure basate su politiche per Kubernetes — Parte 2

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

In risposta all'PSPobsolescenza 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 () e Pod Security Admission (). PSS PSA L'PSAiniziativa include un progetto webhook per il controller di ammissione che implementa i controlli definiti in. PSS Questo approccio del controller di ammissione è simile a quello utilizzato nelle soluzioni. PAC

Secondo la documentazione di Kubernetes, PSS «`definiscono 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 registrazioneCNIs, 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 policy di base proibisce l'uso dihostNetwork, host PID IPC hostPathhostPort, host e l'impossibilità di aggiungere funzionalità Linux, oltre a 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 daPSS, PSA opera in tre modalità:

• imporre: le violazioni delle norme provocheranno 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 in caso di podSpecs violazione del livello di restrizione configurato. Tuttavia, in questa modalità, non verrà impedito l'applicazione al cluster di oggetti Kubernetes non pod che creano pod, come Deployments, anche se ciò viola il contenuto applicato. podSpec PSS In questo caso verrà applicato il Deployment, mentre ai pod verrà impedita l'applicazione.

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. L'infrazione non podSpecs creerà pod. L'ispezione della risorsa Deployment con kubectl get deploy <DEPLOYMENT_NAME> -oyaml mostrerà il messaggio proveniente dall'.status.conditionselemento o dai pod in errore, 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 dei pod che violano le norme. Tuttavia, in queste modalità, le annotazioni di controllo sugli eventi dei log di controllo API del server e gli avvisi ai client API del server, come kubectl, vengono attivati, rispettivamente, quando i pod, così come gli oggetti che creano i pod, contengono violazioni. podSpecs 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à PSA audit e warn sono utili per introdurre le operazioni del PSS cluster senza influire negativamente.

Le modalità PSA operative 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ù PSA etichette 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 i 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 PSS profilo 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

PSAutilizza 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 come parte della configurazione del server. PSA 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 visto sopra ConfigMap YAML, il PSS livello predefinito a livello di cluster è stato impostato su limitato per tutte le PSA modalità, 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 pod-security-webhookspazio dei nomi è esente da configurato. PSS

...
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 API server, nonché sulle risorse del cluster esistenti e sui dati esterni (a seconda della soluzione)

• Supporta la modifica delle richieste API del server 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 usato per spostarsi a sinistra, nelle CICD pipeline, prima di effettuare chiamate al server Kubernetes (dipende dalla soluzione) API

• 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 imparare, configurare e supportare

• La redazione delle policy 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 podPSP, Before, e la posizione di sicurezza dei pod richiesta corrisponde al modello definito nei Pod Security Standards (PSS), allora un percorso più semplice potrebbe essere quello di adottare laPSS, al posto di una soluzione. policy-as-code Tuttavia, se il livello di sicurezza dei vostri pod non si adatta al PSS modello, o avete intenzione di aggiungere controlli aggiuntivi, oltre a quelli definiti daPSS, allora 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 PSS violazioni, 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 daPSA, l'esperienza utente potrebbe essere migliore. Per migliorare l'esperienza dell'utente, è necessario utilizzare più PSA modalità (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 al API server Kubernetes un manifesto di distribuzione con relative PSS podSpec violazioni, il Deployment verrà applicato correttamente, ma i pod no. Inoltre, poiché sono abilitate anche le modalità di controllo e avviso, il client del API server riceverà un messaggio di avviso e anche l'evento del registro di controllo del API server 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 che gestisce. AWS Con Fargate, non è possibile eseguire un contenitore privilegiato o configurare il pod per utilizzare o. hostNetwork hostPort

Non eseguite processi nei contenitori come utente 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 USER direttiva 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 l'utente e/o il gruppo in cui eseguire l'applicazione. Questi campi sono runAsUser e rispettivamente. runAsGroup

Per imporre l'uso dispec.securityContext, e dei relativi elementi associati, all'interno di KubernetespodSpec, è 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 API server 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 creare/eseguire comodamente 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'CICDelaborazione, come la creazione di immagini dei container, devono essere isolati dai cluster che eseguono carichi di lavoro più generalizzati.

Limita l'uso di hostPath o, se necessario, limita i hostPath 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 direttamente espostihostPath, ad esempio, dalle chiavi /etc/shadow, install ssh, leggere segreti montati sull'host e altre cose dannose. Per mitigare i rischi derivanti da, configura come, ad esempio: hostPath 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 impedirne del tutto l'hostPathutilizzo. È 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. Man mano che su un nodo sono programmati pod aggiuntivi, il nodo potrebbe CPU subire una pressione 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 la memoria. 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 CPU di memoria, si sta essenzialmente indicando 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 CPU e di 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à OOM eliminato. Se un contenitore supera il CPU limite, 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 eRAM, 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 limite è possibile ottenere min/max for CPU and memory resources per pod or per container within a namespace. You can also use them to set default request/limit valori se non ne viene fornito nessuno.

Policy-as-code le soluzioni possono essere utilizzate per imporre 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 il bit or. SUID 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 API del server 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 a KubernetesAPI, 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 richiedono la ricerca o la chiamata ai servizi interni al cluster, è possibile ridurre la quantità di informazioni fornite a un pod. È possibile impostare la DNS politica del Pod in modo da non utilizzare Core DNS e non esporre 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 DNS policy di un pod è "ClusterFirst" che utilizza in-clusterDNS, mentre il valore non predefinito «Default» utilizza la risoluzione del nodo sottostante. DNS Per ulteriori informazioni, consulta i documenti di Kubernetes sulla politica di Pod. DNS

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

• Workshop Amazon EKS Security Immersion - Pod Security

• open-policy-agent/gatekeeper-library: La libreria di policy di OPA Gatekeeper è una libreria di policy OPA /Gatekeeper che puoi usare come sostituto. PSPs

• Libreria delle politiche di Kyverno

• Una raccolta di politiche comuni OPA e Kyverno per. EKS

• Contromisure basate sulle politiche: parte 1

• Contromisure basate sulle politiche: parte 2

• Pod Security Policy Migrator: uno strumento che converte nelle PSPs politiche OPA /Gatekeeper o Kyverno KubeWarden

• NeuVector tramite una piattaforma di sicurezza per container SUSE open source e zero-trust, fornisce politiche di processo e file system, nonché regole di controllo delle ammissioni.

📝 Modifica questa pagina su GitHub