Benutzer-Werkzeuge

Webseiten-Werkzeuge


it-wiki:kubernetes:security

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
it-wiki:kubernetes:security [2025/10/30 09:10] markoit-wiki:kubernetes:security [2025/10/31 03:55] (aktuell) – [Container und Container Image Security] marko
Zeile 1: Zeile 1:
 ====== Pod Security Admission ====== ====== Pod Security Admission ======
 Die Kubernetes Pod Security Admission (PSA) ist eine im Core von Kubernetes integrierte Admission-Controller-Strategie, um die Sicherheit von Pods zu gewährleisten. Sie ersetzt den früheren `PodSecurityPolicy` Mechanismus, der ab Kubernetes v1.25 als veraltet gilt. Mit Pod Security Admission lassen sich für Namespaces einfache, deklarative Sicherheitsstandards festlegen, die direkt im Namespace-Objekt hinterlegt werden. Die Kubernetes Pod Security Admission (PSA) ist eine im Core von Kubernetes integrierte Admission-Controller-Strategie, um die Sicherheit von Pods zu gewährleisten. Sie ersetzt den früheren `PodSecurityPolicy` Mechanismus, der ab Kubernetes v1.25 als veraltet gilt. Mit Pod Security Admission lassen sich für Namespaces einfache, deklarative Sicherheitsstandards festlegen, die direkt im Namespace-Objekt hinterlegt werden.
 +{{ :it-wiki:kubernetes:0_pnpqbwz8dg-vtrr0.png?nolink&600 |}}
 ===== Funktionsweise ===== ===== Funktionsweise =====
 Der Pod Security Admission Controller überprüft beim Erstellen oder Aktualisieren eines Pods, ob dessen Spezifikation den im Namespace konfigurierten Sicherheitsstufen entspricht. Pods, die restriktive Einstellungen unterlaufen, werden abgewiesen oder mit Warnungen versehen. Der Pod Security Admission Controller überprüft beim Erstellen oder Aktualisieren eines Pods, ob dessen Spezifikation den im Namespace konfigurierten Sicherheitsstufen entspricht. Pods, die restriktive Einstellungen unterlaufen, werden abgewiesen oder mit Warnungen versehen.
Zeile 21: Zeile 21:
 kubectl label namespace <namespace-name> \ kubectl label namespace <namespace-name> \
     pod-security.kubernetes.io/enforce=baseline \     pod-security.kubernetes.io/enforce=baseline \
-    pod-security.kubernetes.io/enforce-version=v1.33 \+    pod-security.kubernetes.io/enforce-version=v1.34 \
     pod-security.kubernetes.io/warn=restricted \     pod-security.kubernetes.io/warn=restricted \
-    pod-security.kubernetes.io/warn-version=v1.33+    pod-security.kubernetes.io/warn-version=v1.34
 </code> </code>
  
Zeile 30: Zeile 30:
   * Bei Verstoß gegen `restricted` gibt es eine Warnung.   * Bei Verstoß gegen `restricted` gibt es eine Warnung.
  
 +Ein weiteres Beispiel als Manifestfile
 +<code yaml>
 +apiVersion: v1
 +kind: Namespace
 +metadata:
 +  name: my-baseline-namespace
 +  labels:
 +    pod-security.kubernetes.io/enforce: baseline
 +    pod-security.kubernetes.io/enforce-version: v1.34
 +
 +    # We are setting these to our _desired_ `enforce` level.
 +    pod-security.kubernetes.io/audit: restricted
 +    pod-security.kubernetes.io/audit-version: v1.34
 +    pod-security.kubernetes.io/warn: restricted
 +    pod-security.kubernetes.io/warn-version: v1.34
 +</code>
 +Es besteht auch die Möglichkeit statt einer eindeutigen Version einfach ''latest'' zu nehmen.
 ===== Profile im Detail ===== ===== Profile im Detail =====
   - **Privileged**   - **Privileged**
Zeile 49: Zeile 66:
 **Hinweis:**   **Hinweis:**  
 Für eine produktive Umgebung sollte die Konfiguration regelmäßig geprüft und mit weiteren Maßnahmen (z. B. Role-based Access Control, Image Policies) kombiniert werden. Für eine produktive Umgebung sollte die Konfiguration regelmäßig geprüft und mit weiteren Maßnahmen (z. B. Role-based Access Control, Image Policies) kombiniert werden.
 +
 +===== Anwendung von Pod Security Standards verstehen =====
 +''<nowiki>--dry-run=server</nowiki>'' dient dazu, zu verstehen was passiert, wenn verschiedene Pod-Sicherheitsstandards angewendet werden:
 +  - **Privileged** <code bash>kubectl label --dry-run=server --overwrite ns --all \
 +pod-security.kubernetes.io/enforce=privileged</code> Die Ausgabe sieht in etwa so aus:<code bash>namespace/default labeled
 +namespace/kube-node-lease labeled
 +namespace/kube-public labeled
 +namespace/kube-system labeled
 +namespace/local-path-storage labeled</code>
 +  - **Baseline** <code bash>kubectl label --dry-run=server --overwrite ns --all \
 +pod-security.kubernetes.io/enforce=baseline</code> Die Ausgabe sieht in etwa so aus:<code bash>namespace/default labeled
 +namespace/kube-node-lease labeled
 +namespace/kube-public labeled
 +Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest"
 +Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes
 +Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes
 +Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged
 +namespace/kube-system labeled
 +namespace/local-path-storage labeled</code>
 +  - **Restricted** <code bash>kubectl label --dry-run=server --overwrite ns --all \
 +pod-security.kubernetes.io/enforce=restricted</code> Die Ausgabe sieht in etwa so aus:<code bash>namespace/default labeled
 +namespace/kube-node-lease labeled
 +namespace/kube-public labeled
 +Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest"
 +Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile
 +Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true
 +Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
 +Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
 +namespace/kube-system labeled
 +Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest"
 +Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
 +namespace/local-path-storage labeled</code>
 +
 +Aus der vorherigen Ausgabe geht hervor, dass die Anwendung des privileged Pod-Sicherheitsstandards keine Warnungen für irgendwelche Namespaces ausgibt. Die Standards ''baseline'' und ''restricted'' hingegen weisen beide Warnungen auf, insbesondere im ''kube-system'' Namespace.
  
 ---- ----
  
-===== Umsetzung im produktiven Cluster / Pod-Sicherheitsstandards auf Clusterebene =====+===== Pod-Sicherheitsstandards auf Clusterebene =====
 Es werden die folgenden Pod-Sicherheitsstandards auf die Version latest angewendet: Es werden die folgenden Pod-Sicherheitsstandards auf die Version latest angewendet:
   * baseline standard in enforce mode   * baseline standard in enforce mode
Zeile 64: Zeile 115:
 fehlschlagen, werden diese Namespaces von der Anwendung der Pod-Sicherheitsstandards ausgenommen. fehlschlagen, werden diese Namespaces von der Anwendung der Pod-Sicherheitsstandards ausgenommen.
  
-Bei der Implementierung von Pod Security Admission in der produktiven Umgebung sollte Folgendes beachtet werden:+Bei der Implementierung von Pod Security Admission auf Cluster Ebene sollte Folgendes beachtet werden:
   * Abhängig von der Risikobewertung eines Clusters könnte ein strengerer Pod-Sicherheitsstandard die bessere Wahl sein. Beispielsweise ''restricted''   * Abhängig von der Risikobewertung eines Clusters könnte ein strengerer Pod-Sicherheitsstandard die bessere Wahl sein. Beispielsweise ''restricted''
  
Zeile 99: Zeile 150:
       runtimeClasses: []       runtimeClasses: []
       # Array of namespaces to exempt.       # Array of namespaces to exempt.
-      namespaces: [kube-system,calico-system,longhorn-system,tigera-operator,trident]+      namespaces: [kube-system,calico-system]
 </code> </code>
  
 +<note>
 +<nowiki>--admission-control-config-file</nowiki>\\
 +Das obige Manifest muss über den kube-apiserver angegeben werden.
 +</note>
  
- +  - Bereiten Sie das Konfigurationsverzeichnis vor: <code bash>mkdir -p /etc/kubernetes/psa  
 +cp psa-config.yaml /etc/kubernetes/psa/</code> 
 +  - Ändern Sie die API-Serverkonfiguration: <code yaml>apiServer:  
 +  extraArgs:  
 +    admission-control-config-file:  /etc/kubernetes/psa/psa-config.yaml  
 +  extraVolumes:  
 +    -  name:  psa-config  
 +      hostPath:  /etc/kubernetes/psa  
 +      mountPath:  /etc/kubernetes/psa  
 +      readOnly:  true</code> 
 +  - Starten Sie den API-Server neu:\\ Nach der Aktualisierung der Konfiguration muss der API-Server neu gestartet werden, um die Änderungen anzuwenden. 
 +\\ 
 +\\
 ====== Container und Container Image Security ====== ====== Container und Container Image Security ======
 ===== trivy ===== ===== trivy =====
it-wiki/kubernetes/security.1761815417.txt.gz · Zuletzt geändert: von marko