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 **Suggerimento** [Esplora le](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) best practice tramite i workshop Amazon EKS. Le specifiche del pod includono una varietà di attributi diversi che possono rafforzare o indebolire il tuo 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 .7.html. and/or gain access to sensitive information bound to the host, including Secrets and ConfigMaps. Below is a list of the default capabilities assigned to containers. For additional information about each capability, see http://man7.org/linux/man-pages/man7/capabilities `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` **Example** Per impostazione predefinita, ai pod EC2 e Fargate vengono assegnate le funzionalità sopra menzionate. 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.](https://kubernetes.io/docs/reference/access-authn-authz/node/) 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 + pod + 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) + eventi 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](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 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)](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) 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](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Avrai tempo fino alla versione 1.25 o circa 2 anni per passare a un'alternativa. Questo [documento](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md#motivation) 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 soluzioni (PAC) dell'ecosistema Kubernetes + [Standard di sicurezza Kubernetes Pod (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 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](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) 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](https://kyverno.io/blog/2023/05/24/podsecuritypolicy-migration-with-kyverno/) 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.](https://aws.amazon.com/blogs/containers/managing-pod-security-on-amazon-eks-with-kyverno/) ### 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](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 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. + [OPA/Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/) + [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) + [Kyverno](https://kyverno.io/) + [Kubewarden](https://www.kubewarden.io/) + [Politica JS](https://www.jspolicy.com/) Per ulteriori informazioni sulle soluzioni PAC e su come aiutarvi a scegliere la soluzione appropriata per le vostre esigenze, consultate i collegamenti seguenti. + [Contromisure basate su politiche per Kubernetes — Parte 1](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-1/) + [Contromisure basate su politiche per Kubernetes — Parte 2](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-2/) ### 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](https://github.com/kubernetes/community/tree/master/sig-auth) ha creato i Pod Security Standards (PSS) e [Pod](https://kubernetes.io/docs/concepts/security/pod-security-standards/) Security Admission (PSA).](https://kubernetes.io/docs/concepts/security/pod-security-admission/) [L'iniziativa PSA include un progetto webhook per i controller di ammissione che implementa i controlli definiti nel PSS.](https://github.com/kubernetes/pod-security-admission#pod-security-admission) Questo approccio di controllo delle ammissioni è 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](https://kubernetes.io/docs/concepts/security/pod-security-standards/#profile-details), 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 -oyaml` mostrerà il messaggio proveniente dall'`.status.conditions`elemento (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. `kubectl`*Di* 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](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller). Nell'implementazione *Validating Webhook*, le esenzioni possono essere configurate all'interno di una [ConfigMap](https://github.com/kubernetes/pod-security-admission/blob/master/webhook/manifests/20-configmap.yaml)risorsa Kubernetes che viene montata come volume nel contenitore. [pod-security-webhook](https://github.com/kubernetes/pod-security-admission/blob/master/webhook/manifests/50-deployment.yaml) ``` 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 *ValidatingWebhookConfiguration*risorsa, vista di seguito, anche lo spazio dei *pod-security-webhook*nomi è 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.](https://github.com/kubernetes/pod-security-admission/tree/master/webhook) ### 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) Pro: + 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](https://kyverno.io/docs/writing-policies/autogen/) Deployments. [Kyverno può anche generare risorse Kubernetes aggiuntive «`quando viene creata *una nuova risorsa o quando la fonte viene aggiornata`» utilizzando* Generate Rules.)](https://kyverno.io/docs/writing-policies/generate/) + 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 imparare, configurare e supportare + La redazione delle politiche potrebbe richiedere nuove skills/languages/capabilities #### Pod Security Admission (rispetto a policy-as-code) Pro: + 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 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, in`spec.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 di`spec.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](https://github.com/GoogleContainerTools/kaniko), buildah o un servizio di compilazione simile. [CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)](https://github.com/containers/buildah) **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](https://labs.bishopfox.com/tech-blog/bad-pods-kubernetes-pod-privilege-escalation): 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 di applicazioni scritte male che consumano una quantità eccessiva di risorse. `podSpec`Consente 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 contenitore`resources.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 | highest | limite = richiesta\$1 = 0 | Supera solo i limiti di memoria | | Scoppibile | medium | limite\$1 = richiesta\$1 = 0 | Può essere ucciso se supera la memoria richiesta | | Miglior sforzo | lowest | 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](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/). [Puoi forzare l'uso di richieste e limiti impostando una [quota di risorse](https://kubernetes.io/docs/concepts/policy/resource-quotas/) su un namespace o creando un intervallo di limiti.](https://kubernetes.io/docs/concepts/policy/limit-range/) 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 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 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 **Example** ``` 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](https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables) 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](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) sulla politica DNS di Pod. **Example** ``` 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. **Example** In base a [Windows, i contenitori in Kubernetes](https://kubernetes.io/docs/concepts/windows/intro/) `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 di immersione nella sicurezza di Amazon EKS - Pod Security](https://catalog.workshops.aws/eks-security-immersionday/en-US/3-pod-security) + [open-policy-agent/gatekeeper-library: La libreria di policy OPA Gatekeeper, una libreria di OPA/Gatekeeper policy](https://github.com/open-policy-agent/gatekeeper-library) che puoi usare come sostituto. PSPs + [Libreria delle politiche di Kyverno](https://kyverno.io/policies/) + [Una raccolta di politiche OPA e Kyverno comuni per EKS.](https://github.com/aws/aws-eks-best-practices/tree/master/policies) + [Contromisure basate sulle politiche: parte 1](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-1/) + [Contromisure basate sulle politiche: parte 2](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-2/) + [Pod Security Policy Migrator](https://appvia.github.io/psp-migration/) è uno strumento che converte in politiche PSPs OPA/Gatekeeper o Kyverno KubeWarden + [NeuVector di SUSE](https://www.suse.com/neuvector/), piattaforma open source per la sicurezza dei container zero-trust, fornisce politiche di processo e file system, nonché regole di controllo delle ammissioni.