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à. # Contesti di sicurezza Pod **Pod Security Policies (PSP)** e **Pod Security Standards (PSS)** sono due modi principali per rafforzare la sicurezza in Kubernetes. Tieni presente che PodSecurityPolicy è obsoleto a partire da Kubernetes v1.21 e verrà rimosso nella v1.25 e Pod Security Standard (PSS) è l'approccio consigliato da Kubernetes per far rispettare la sicurezza in futuro. Una Pod Security Policy (PSP) è una soluzione nativa di Kubernetes per implementare le politiche di sicurezza. PSP è una risorsa a livello di cluster che controlla gli aspetti sensibili alla sicurezza delle specifiche Pod. Utilizzando Pod Security Policy è possibile definire una serie di condizioni che i Pod devono soddisfare per essere accettati dal cluster. La funzionalità PSP è disponibile sin dai primi giorni di Kubernetes ed è progettata per impedire la creazione di pod mal configurati su un determinato cluster. [Per ulteriori informazioni sulle politiche di sicurezza dei pod, consulta la documentazione di Kubernetes.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) In base alla [politica di deprecazione di Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/), le versioni precedenti smetteranno di ricevere supporto nove mesi dopo l'obsolescenza della funzionalità. D'altra parte, i Pod Security Standards (PSS), che è l'approccio di sicurezza consigliato e in genere implementato utilizzando i contesti di sicurezza, sono definiti come parte delle specifiche del Pod e del contenitore nel manifesto del Pod. PSS è lo standard ufficiale che il team di progetto Kubernetes ha definito per soddisfare le migliori pratiche relative alla sicurezza per i Pods. Definisce politiche come quelle di base (minimamente restrittive, predefinite), privilegiate (non restrittive) e limitate (le più restrittive). Ti consigliamo di iniziare con il profilo di base. Il profilo di base PSS offre un solido equilibrio tra sicurezza e potenziale attrito, richiede un elenco minimo di eccezioni e rappresenta un buon punto di partenza per la sicurezza dei carichi di lavoro. Se stai utilizzando PSPs attualmente, ti consigliamo di passare a PSS. [Maggiori dettagli sulle politiche PSS sono disponibili nella documentazione di Kubernetes.](https://kubernetes.io/docs/concepts/security/pod-security-standards/) [https://www.openpolicyagent.org/](https://www.openpolicyagent.org/) [Ad esempio, Kyverno fornisce qui la raccolta completa delle politiche PSS.](https://kyverno.io/policies/pod-security/) Le impostazioni del contesto di sicurezza consentono di concedere privilegi a determinati processi, utilizzare i profili di programma per limitare le funzionalità ai singoli programmi, consentire l'aumento dei privilegi, filtrare le chiamate di sistema, tra le altre cose. I pod Windows in Kubernetes presentano alcune limitazioni e caratteristiche distintive rispetto ai carichi di lavoro standard basati su Linux per quanto riguarda i contesti di sicurezza. Windows utilizza un oggetto Job per contenitore con un filtro dello spazio dei nomi di sistema per contenere tutti i processi in un contenitore e fornire l'isolamento logico dall'host. Non è possibile eseguire un contenitore Windows senza il filtro dello spazio dei nomi. Ciò significa che i privilegi di sistema non possono essere rivendicati nel contesto dell'host e quindi i contenitori privilegiati non sono disponibili in Windows. [Le seguenti `windowsOptions` sono le uniche opzioni documentate del contesto di [sicurezza di Windows, mentre le altre sono opzioni generali del contesto](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#windowssecuritycontextoptions-v1-core) di sicurezza](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#securitycontext-v1-core) Per un elenco degli attributi del contesto di sicurezza supportati in Windows e Linux, consulta la documentazione ufficiale disponibile [qui](https://kubernetes.io/docs/setup/production-environment/windows/_print/#v1-container). Le impostazioni specifiche del Pod vengono applicate a tutti i contenitori. Se non specificato, PodSecurityContext verranno utilizzate le opzioni di. Se impostato in entrambi SecurityContext e PodSecurityContext, il valore specificato in ha la SecurityContext precedenza. Ad esempio, l'impostazione runAsUser del nome per contenitori e contenitori, che è un'opzione di Windows, è un equivalente approssimativo dell' runAsUser impostazione specifica di Linux e nel seguente manifesto, il contesto di sicurezza specifico del pod viene applicato a tutti i contenitori ``` apiVersion: v1 kind: Pod metadata: name: run-as-username-pod-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo nodeSelector: kubernetes.io/os: windows ``` Di seguito, invece, il contesto di sicurezza a livello di contenitore ha la precedenza sul contesto di sicurezza a livello di pod. ``` apiVersion: v1 kind: Pod metadata: name: run-as-username-container-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo .. securityContext: windowsOptions: runAsUserName: "ContainerAdministrator" nodeSelector: kubernetes.io/os: windows ``` Esempi di valori accettabili per il campo runAsUser Name: ContainerAdministrator,, NT AUTHORITY\$1 NETWORK SERVICE ContainerUser, NT AUTHORITY\$1 LOCAL SERVICE In genere è consigliabile eseguire i contenitori con pod ContainerUser per Windows. Gli utenti non sono condivisi tra il contenitore e l' ContainerAdministrator host, ma dispongono di privilegi aggiuntivi all'interno del contenitore. Tieni presente che ci sono [delle limitazioni relative](https://kubernetes.io/docs/tasks/configure-pod-container/configure-runasusername/#windows-username-limitations) al nome utente di cui devi essere a conoscenza. Un buon esempio di quando usare ContainerAdministrator è impostare PATH. Puoi usare la direttiva USER per farlo, in questo modo: ``` USER ContainerAdministrator RUN setx /M PATH "%PATH%;C:/your/path" USER ContainerUser ``` Nota inoltre che i segreti sono scritti in testo non crittografato sul volume del nodo (rispetto a tmpfs/in-memory su linux). Ciò significa che devi fare due cose + Usa file ACLs per proteggere la posizione segreta del file + Usa la crittografia a livello di volume utilizzando [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)