Questo argomento spiega come configurare i controller di ammissione sicurezza pod (PSA) per proteggere i cluster del carico di lavoro distribuiti da Tanzu Kubernetes Grid (TKG).
Per i cluster o gli spazi dei nomi all'interno di cluster che eseguono Kubernetes v1.23 e versioni successive, TKG supporta l'applicazione di criteri di sicurezza pod di tipo privileged
, baseline
o restricted
tramite il controller di ammissione di sicurezza pod (PSA).
I controller PSA in Kubernetes consentono di configurare i criteri di sicurezza del carico di lavoro su due assi:
privileged
, baseline
e restricted
, dal meno restrittivo al più restrittivo.warn
genera un avviso, audit
aggiunge una voce del registro di controllo e enforce
blocca la creazione del pod.È possibile configurare i controller PSA in modo che funzionino su spazi dei nomi specifici o a livello di cluster. Ad esempio, è possibile configurare un cluster in modo che attivi un registro di controllo quando un pod baseline
viola un criterio di sicurezza e blocchi un pod restricted
se viola il criterio.
Per ulteriori informazioni, vedere Standard di sicurezza pod nella documentazione di Kubernetes.
Il sistema PSA sostituisce i criteri di sicurezza del pod (PSP), che sono stati deprecati in Kubernetes v1.21 e rimossi nella versione 1.25, come descritto nelle note di rilascio di Kubernetes v1.25.
I PSP per i nodi sono stati deprecati in TKG v2.1 perché sono stati deprecati anche in Kubernetes. Per informazioni su come eseguire la migrazione dei pod dai PSP al controller PSA, vedere Migrazione da PodSecurityPolicy al controller di ammissione PodSecurity integrato.
Le impostazioni di PSA predefinite per un cluster del carico di lavoro TKG dipendono dalla versione di Kubernetes in esecuzione:
warn
e audit
: restricted
enforce
: nessuna impostazionewarn
e audit
: baseline
enforce
: nessuna impostazioneLe impostazioni di PSA predefinite per i cluster che eseguono le versioni di Kubernetes native in TKG 2.4, v2.3, v2.2 e v2.1 garantiscono che i pod continuino a essere eseguiti durante la migrazione da PSP a PSA, anche se generano avvisi relativi alla violazione del criterio:
A partire da TKG v2.2, tutti i componenti TKG interni sono conformi al profilo restricted
PSA.
È possibile configurare un nuovo cluster con PSA a livello di cluster o modificare il PSA di un cluster esistente.
Per configurare un PSA a livello di cluster per un nuovo cluster del carico di lavoro, impostare POD_SECURITY_STANDARD_DEACTIVATED
nel file di configurazione del cluster su false
e impostare le altre variabili di POD_SECURITY_STANDARD_*
come descritto nella tabella Standard di sicurezza pod in Informazioni di riferimento sulle variabili del file di configurazione.
POD_SECURITY_STANDARD_DEACTIVATED
POD_SECURITY_STANDARD_AUDIT
POD_SECURITY_STANDARD_WARN
POD_SECURITY_STANDARD_ENFORCE
È inoltre possibile generare il manifesto del cluster come passaggio 1 del processo in due passaggi descritto in Creazione di un cluster basato sulla classe e quindi modificare i valori della variabile podSecurityStandard
nella specifica Cluster
come descritto in Modifica di PSA per un cluster basato sulla classe esistente di seguito prima di creare il cluster nel passaggio 2.
Per modificare la configurazione PSA di un cluster basato sulla classe esistente:
Aprire la specifica dell'oggetto Cluster
in un editor:
kubectl edit -namespace NAMESPACE CLUSTER
Modificare i valori del blocco podSecurityStandard
in spec.topology.variables
:
- name: podSecurityStandard
value:
deactivated: DEACTIVATED
audit: AUDIT-PROFILE
enforce: ENFORCE-PROFILE
warn: WARN-PROFILE
auditVersion: AUDIT-VERSION
enforceVersion: ENFORCE-VERSION
warnVersion: WARN-VERSION
exemptions:
namespaces: [EXEMPT-NS]
In cui:
DEACTIVATED
è false
per applicare un PSA a livello di cluster e true
in caso contrarioAUDIT-PROFILE
, ENFORCE-PROFILE
e WARN-PROFILE
sono i profili PSA per tutte le modalità, che possono essere "privileged"
, "baseline"
, "restricted"
. Il valore predefinito è "privileged"
.VERSION
sono la versione di Kubernetes per le tre modalità, ad esempio "v1.26"
.EXEMPT-NS
è un elenco di spazi dei nomi separati da virgole da escludere dal controllo PSA.Nota: Gli spazi dei nomi del sistema
kube-system
etkg-system
verranno sempre esclusi dal controllo PSA.
Cluster
, le modifiche devono essere implementate nei nodi del piano di controllo del cluster.Per modificare la configurazione PSA di un cluster legacy esistente:
Recuperare il file della specifica AdmissionConfiguraton
corrente dall'oggetto KubeadmControlPlane
e salvarla localmente, ad esempio:
kubectl get kcp my-cluster-control-plane --template='{{ range $v := .spec.kubeadmConfigSpec.files }}{{ if eq $v.path "/etc/kubernetes/admission-control-config.yaml" }}{{ $v.content }}{{ end }}{{ end }}' > admission-config.yaml
Modificare il file admission-config.yaml
con la nuova configurazione. Ad esempio, quanto segue imposta enforce
su baseline
e mantiene le modalità audit
e warn
su restricted
:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1beta1
kind: PodSecurityConfiguration
defaults:
enforce: "baseline"
enforce-version: "v1.24"
audit: "restricted"
audit-version: "v1.24"
warn: "restricted"
warn-version: "v1.24"
exemptions:
usernames: []
runtimeClasses: []
namespaces: ["kube-system", "tkg-system"]
Modificare la specifica dell'oggetto KubeadmControlPlane
e sostituire la voce di array corrispondente in spec.kubeadmConfigSpec.files
con il nuovo file di configurazione.
Dopo aver applicato la specifica dell'oggetto KubeadmControlPlane
, le modifiche devono essere implementate nei nodi del piano di controllo del cluster.
Prima di aggiungere o modificare un PSA, evitare tempi di inattività imprevisti assicurandosi che tutti i carichi di lavoro esistenti nel cluster o nello spazio dei nomi di PSA siano conformi alle nuove impostazioni del criterio.
È possibile verificare se i pod in esecuzione in uno spazio dei nomi esistente sono conformi a un determinato criterio eseguendo kubectl label --overwrite --dry-run=server
:
kubectl label --overwrite --dry-run=server namespace <namespace> pod-security.kubernetes.io/enforce=<policy>
Le stesse informazioni vengono scritte nei registri di controllo quando si configura la modalità audit
dell'ammissione di sicurezza pod oppure vengono fornite quando si applicano risorse a un cluster e si configura la modalità warn
.
Le informazioni aggiornate sui differenti profili per la sicurezza del pod sono disponibili nella documentazione di Kubernetes.