Contesti di sicurezza Pod

Le Pod Security Policies (PSP) e i Pod Security Standards (PSS) sono due modi principali per far rispettare la sicurezza in Kubernetes. Nota 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 puoi 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 bloccare la creazione di pod non configurati in modo errato 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, le versioni precedenti smetteranno di ricevere supporto nove mesi dopo la deprecazione 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 baseline (minimamente restrittiva, predefinita), privilegiata (non restrittiva) e limitata (più restrittiva).

Si consiglia di iniziare con il profilo di base. Il profilo di base PSS fornisce un solido equilibrio tra sicurezza e potenziali problemi, richiede un elenco minimo di eccezioni e funge da buon punto di partenza per la sicurezza dei carichi di lavoro. Se attualmente utilizzi PSP, 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/ Queste politiche possono essere applicate con diversi strumenti, inclusi quelli di OPA e Kyverno. https://www.openpolicyagent.org/ https://kyverno.io/ Ad esempio, Kyverno fornisce la raccolta completa delle politiche PSS qui. https://kyverno.io/policies/

Le impostazioni del contesto di sicurezza consentono di concedere privilegi per selezionare i processi, utilizzare i profili dei programmi per limitare le funzionalità ai singoli programmi, consentire l'escalation dei privilegi, filtrare le chiamate di sistema, tra le altre cose.

I pod Windows in Kubernetes presentano alcune limitazioni e differenze rispetto ai carichi di lavoro standard per quanto riguarda i contesti di sicurezza. Linux-based

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 di sicurezza

Per un elenco degli attributi del contesto di sicurezza supportati in Windows e linux, consulta la documentazione ufficiale qui.

Le impostazioni specifiche del Pod vengono applicate a tutti i contenitori. Se non specificato, PodSecurityContext verranno utilizzate le opzioni di. Se impostato in entrambi i valori SecurityContext e PodSecurityContext, il valore specificato in ha la SecurityContext precedenza.

Ad esempio, AsUserName l'impostazione di esecuzione per pod e contenitori, che è un'opzione di Windows, è un equivalente approssimativo dell'AsUser impostazione di Linux-specific esecuzione 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

Mentre di seguito, 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 AsUserName campo run: ContainerAdministrator,, NT AUTHORITY\ NETWORK SERVICE ContainerUser, NT AUTHORITY\ LOCAL SERVICE

In genere è una buona idea eseguire i contenitori con pod ContainerUser per Windows. Gli utenti non sono condivisi tra il contenitore e l'host, ContainerAdministrator ma dispongono di privilegi aggiuntivi all'interno del contenitore. Tieni presente che ci sono limitazioni relative al nome utente di cui 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 anche che i segreti sono scritti in chiaro sul volume del nodo (rispetto a tmpfs/in -memory su linux). Ciò significa che devi fare due cose