TuxNet DokuWiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • security
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:24] – [Anwendung von Pod Security Standards verstehen] 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 86: Zeile 103:
 ---- ----
  
-===== 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 98: 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 133: 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.1761816254.txt.gz · Zuletzt geändert: von marko