Sicherheitskontexte für Pods

Pod Security Policies (PSP) und Pod Security Standards (PSS) sind zwei Hauptmethoden zur Durchsetzung der Sicherheit in Kubernetes. Beachten Sie, dass dies ab Kubernetes v1.21 veraltet PodSecurityPolicy ist und in Version 1.25 entfernt wird. Pod Security Standard (PSS) ist der von Kubernetes empfohlene Ansatz zur zukünftigen Durchsetzung der Sicherheit.

Eine Pod Security Policy (PSP) ist eine native Lösung in Kubernetes zur Implementierung von Sicherheitsrichtlinien. PSP ist eine Ressource auf Clusterebene, die sicherheitsrelevante Aspekte der Pod-Spezifikation steuert. Mithilfe der Pod-Sicherheitsrichtlinie können Sie eine Reihe von Bedingungen definieren, die Pods erfüllen müssen, um vom Cluster akzeptiert zu werden. Die PSP-Funktion ist seit den Anfängen von Kubernetes verfügbar und soll verhindern, dass falsch konfigurierte Pods auf einem bestimmten Cluster erstellt werden.

Weitere Informationen zu den Pod-Sicherheitsrichtlinien finden Sie in der Kubernetes-Dokumentation. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ Gemäß der Kubernetes-Verfallsrichtlinie wird der Support für ältere Versionen neun Monate nach dem Auslaufen der Funktion eingestellt.

Andererseits werden Pod Security Standards (PSS), der empfohlene Sicherheitsansatz, der in der Regel mithilfe von Sicherheitskontexten implementiert wird, als Teil der Pod- und Container-Spezifikationen im Pod-Manifest definiert. PSS ist der offizielle Standard, den das Kubernetes-Projektteam definiert hat, um die sicherheitsbezogenen Best Practices für Pods zu berücksichtigen. Es definiert Richtlinien wie Basisrichtlinien (minimal restriktiv, Standard), privilegiert (nicht einschränkend) und eingeschränkt (am restriktivsten).

Wir empfehlen, mit dem Basisprofil zu beginnen. Das PSS-Basisprofil bietet ein solides Gleichgewicht zwischen Sicherheit und potenziellen Problemen. Es erfordert eine minimale Liste von Ausnahmen und dient als guter Ausgangspunkt für die Workload-Sicherheit. Wenn Sie derzeit PSPs verwenden, empfehlen wir, auf PSS umzusteigen. Weitere Informationen zu den PSS-Richtlinien finden Sie in der Kubernetes-Dokumentation. https://kubernetes.io/docs/concepts/security/pod-security-standards/ Diese Richtlinien können mit verschiedenen Tools durchgesetzt werden, darunter denen von OPA und Kyverno. https://kyverno.io/ Zum Beispiel bietet Kyverno hier die vollständige Sammlung von PSS-Richtlinien. https://kyverno.io/policies/

Die Sicherheitskontexteinstellungen ermöglichen es unter anderem, Berechtigungen für ausgewählte Prozesse zu vergeben, Programmprofile zu verwenden, um Funktionen auf einzelne Programme zu beschränken, die Eskalation von Rechten zu ermöglichen und Systemaufrufe zu filtern.

Windows-Pods in Kubernetes weisen einige Einschränkungen auf und unterscheiden sich von Linux-based Standard-Workloads, wenn es um Sicherheitskontexte geht.

Windows verwendet ein Job-Objekt pro Container mit einem System-Namespace-Filter, um alle Prozesse in einem Container einzuschließen und eine logische Isolierung vom Host zu gewährleisten. Es gibt keine Möglichkeit, einen Windows-Container auszuführen, ohne dass die Namespace-Filterung aktiviert ist. Das bedeutet, dass Systemberechtigungen im Kontext des Hosts nicht geltend gemacht werden können und daher privilegierte Container unter Windows nicht verfügbar sind.

Im Folgenden windowsOptions sind die einzigen dokumentierten Windows-Sicherheitskontextoptionen aufgeführt, während es sich bei den übrigen um allgemeine Sicherheitskontextoptionen handelt

Eine Liste der Sicherheitskontext-Attribute, die in Windows und Linux unterstützt werden, finden Sie in der offiziellen Dokumentation hier.

Die Pod-spezifischen Einstellungen werden auf alle Container angewendet. Wenn nicht angegeben, PodSecurityContext werden die Optionen von verwendet. Wenn SecurityContext sowohl als auch gesetzt sind PodSecurityContext, hat der in angegebene Wert SecurityContext Vorrang.

Beispielsweise entspricht die AsUserName Ausführungseinstellung für Pods und Container, bei der es sich um eine Windows-Option handelt, in etwa der Linux-specific AsUser Ausführungseinstellung, und im folgenden Manifest wird der Pod-spezifische Sicherheitskontext auf alle Container angewendet

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

Im Folgenden hat der Sicherheitskontext auf Containerebene Vorrang vor dem Sicherheitskontext auf Pod-Ebene.

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

Beispiele für zulässige Werte für das AsUserName Run-Feld: ContainerAdministrator ContainerUser, NT AUTHORITY\ NETWORK SERVICE, NT AUTHORITY\ LOCAL SERVICE

Es ist im Allgemeinen eine gute Idee, Ihre Container ContainerUser für Windows-Pods auszuführen. Die Benutzer werden nicht vom Container und vom Host gemeinsam genutzt, aber sie haben zusätzliche Rechte im Container. ContainerAdministrator Beachten Sie, dass es Einschränkungen bei Nutzernamen gibt, die Sie beachten sollten.

Ein gutes Beispiel dafür, wann man das verwenden sollte, ContainerAdministrator ist das Setzen von PATH. Sie können dazu die USER-Direktive wie folgt verwenden:

USER ContainerAdministrator
RUN setx /M PATH "%PATH%;C:/your/path"
USER ContainerUser

Beachten Sie auch, dass Geheimnisse im Klartext auf das Volume des Knotens geschrieben werden (im Gegensatz zu tmpfs/in -memory unter Linux). Das bedeutet, dass Sie zwei Dinge tun müssen