Pod-Sicherheits-Policys mit Kubernetes Engine (OKE) verwenden

Erfahren Sie, wie Sie Podsicherheits-Policys mit Kubernetes-Clustern verwenden, die Sie mit der Kubernetes Engine (OKE) erstellt haben.

Hinweis

Das Upstream-Kubernetes-Projekt veraltete Podsicherheits-Policys in Kubernetes-Version 1.21 und entfernte das Feature in Kubernetes-Version 1.25. Folglich unterstützt Kubernetes Engine keine Podsicherheits-Policys und den PodSecurityPolicy-Zulassungscontroller in Clustern, auf denen Kubernetes-Version 1.25 und höher ausgeführt wird.

Wenn Sie ähnliche Funktionen benötigen, sollten Sie stattdessen Kubernetes-Podsicherheitsstandards und den Zulassungscontroller PodSecurity verwenden (zusammen mit den Policys "Berechtigt", "Baseline" und "Eingeschränkt"). Standardmäßig aktiviert Kubernetes Engine den PodSecurity-Zulassungscontroller in Clustern, auf denen Kubernetes-Version 1.23 und höher ausgeführt wird, um Podsicherheitsstandards zu unterstützen. Weitere Informationen zu Kubernetes-Podsicherheitsstandards und zum PodSecurity-Zulassungscontroller finden Sie unter Podsicherheitsstandards in der Kubernetes-Dokumentation.

Alternativ können Sie auch andere Alternativen verwenden, die im Kubernetes-Ökosystem entwickelt werden, um Richtlinien durchzusetzen.

Wenn Sie sich entscheiden, von Podsicherheits-Policys und dem PodSecurityPolicy-Zulassungscontroller zur Verwendung von Podsicherheitsstandards und dem PodSecurity-Zulassungscontroller zu wechseln, finden Sie weitere Informationen unter Von PodSecurityPolicy zum integrierten PodSecurity-Zulassungscontroller migrieren in der Kubernetes-Dokumentation. Beachten Sie, dass die Migration vor dem Erstellen eines neuen Clusters mit Kubernetes-Version 1.25 oder vor dem Upgrade eines vorhandenen Kubernetes-Clusters der Version 1.24 zur Ausführung von Kubernetes-Version 1.25 abgeschlossen werden muss. Beachten Sie außerdem, dass die Konsole eine praktische Möglichkeit bietet, die Verwendung des Zulassungscontrollers PodSecurityPolicy in vorhandenen Kubernetes-Clustern zu deaktivieren, die von der Kubernetes-Engine erstellt und verwaltet werden (siehe Zulassungscontroller PodSecurityPolicy mit der Konsole deaktivieren).

Sie können die Vorgänge steuern, die Pods für ein Cluster ausführen dürfen, das Sie mit der Kubernetes-Engine erstellt haben, indem Sie Podsicherheits-Policys für das Cluster einrichten. Mit Podsicherheits-Policys können Sie sicherstellen, dass Pods sicherheitsbezogene Bedingungen erfüllen, bevor sie von einem Cluster akzeptiert werden können. Sie können Podsicherheits-Policys beispielsweise für folgende Zwecke verwenden:

  • Für Pods verfügbare Speicheroptionen begrenzen
  • Hostnetzwerke und Ports begrenzen, auf die Pods zugreifen können
  • Verhindern, dass Pods als Root-Benutzer ausgeführt werden
  • Ausführung von Pods im privilegierten Modus verhindern

Sie können Podsicherheits-Policys auch verwenden, um Standardwerte für Pods anzugeben, indem Sie den Pod "mutieren".

Nachdem Sie eine Podsicherheits-Policy für ein Cluster definiert haben, müssen Sie den Serviceaccount des anfordernden Benutzers oder Zielpods zur Verwendung der Policy autorisieren. Dazu erstellen Sie eine Rolle (oder clusterrole) für den Zugriff auf die Podsicherheits-Policy und anschließend ein rolebinding (oder clusterrolebinding) zwischen der Rolle (oder clusterrole) und dem Serviceaccount des anfordernden Benutzers oder Zielpods. Weitere Informationen zu Rollen, Clusterrollen und Bindings finden Sie unter Zugriffskontrolle und Kubernetes-Engine (OKE).

Sie geben an, ob ein Cluster die definierten Podsicherheits-Policys durchsetzt, indem Sie den PodSecurityPolicy-Zulassungscontroller des Clusters aktivieren. Der PodSecurityPolicy-Zulassungscontroller tritt bei Erstellung und Änderung eines Pods in Kraft und bestimmt basierend auf dem angeforderten Sicherheitskontext in der Podspezifikation und den Podsicherheits-Policys des Clusters, ob der Pod zum Cluster zugelassen werden soll. Wenn mehrere Podsicherheits-Policys vorhanden sind, vergleicht der PodSecurityPolicy-Zulassungscontroller zuerst den Pod mit nicht mutierenden Policys in alphabetischer Reihenfolge und verwendet die erste Policy, die den Pod erfolgreich validiert. Wenn keine nicht mutierenden Pods den Pod validieren, vergleicht der PodSecurityPolicy-Zulassungscontroller den Pod mit mutierenden Policys in alphabetischer Reihenfolge und verwendet die erste Policy, die den Pod erfolgreich validiert.

Achtung

Achtung 1:

Beachten Sie unbedingt Folgendes, wenn Sie den PodSecurityPolicy-Zulassungscontroller eines Clusters aktivieren: Es können nur dann Anwendungspods im Cluster gestartet werden, wenn geeignete Podsicherheits-Policys vorhanden sind, zusammen mit Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings), um Pods mit Policys zu verknüpfen. Sie können nur dann Anwendungspods in einem Cluster mit einem aktivierten PodSecurityPolicy-Zulassungscontroller ausführen, wenn diese Voraussetzungen erfüllt sind.

Es wird dringend empfohlen, PodSecurityPolicy-Zulassungscontroller wie folgt zu verwenden:

  • Wenn Sie ein neues Cluster erstellen, aktivieren Sie den Podsicherheits-Zulassungscontroller.
  • Unmittelbar nach Erstellen eines neuen Clusters erstellen Sie Podsicherheits-Policys zusammen mit Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings).

Achtung 2:

Sie müssen Podsicherheits-Policys erstellen, bevor Sie den PodSecurityPolicy-Zulassungscontroller eines vorhandenen Clusters aktivieren, das bereits in Produktion ist. Wenn Sie den PodSecurityPolicy-Zulassungscontroller eines vorhandenen Clusters aktivieren möchten, wird dringend empfohlen, zuerst die Podsicherheits-Policys des Clusters in einer Entwicklungs- oder Testumgebung zu überprüfen. So können Sie sicher sein, dass die Podsicherheits-Policys in der erwarteten Weise funktionieren und dass Pods ordnungsgemäß im Cluster gestartet (oder abgelehnt) werden.

Wenn Sie den PodSecurityPolicy-Aufnahmecontroller eines Clusters aktivieren, das Sie mit der Kubernetes-Engine erstellt haben, wird automatisch eine Podsicherheits-Policy für privilegierte Pods des Kubernetes-Systems erstellt (zusammen mit clusterrole und clusterrolebinding). Diese Podsicherheits-Policy sowie clusterrole and clusterrolebinding ermöglichen die Ausführung der Kubernetes-Systempods. Podsicherheits-Policy, clusterrole und clusterrolebinding sind in der Datei kube-system.yaml definiert (siehe Referenz zu kube-system.yaml).

Beachten Sie, dass Sie Podsicherheits-Policys für ein Cluster erstellen können, bevor Sie den PodSecurityPolicy-Zulassungscontroller des Clusters aktivieren. Beachten Sie auch, dass Sie den PodSecurityPolicy-Zulassungscontroller eines Clusters, der zuvor aktiviert wurde, deaktivieren können. In diesem Fall werden zuvor erstellte Podsicherheits-Policys, Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings) nicht gelöscht. Die Podsicherheits-Policys werden einfach nicht durchgesetzt. Jeder Anwendungspod kann auf dem Cluster ausgeführt werden.

Weitere Informationen zu Podsicherheits-Policys und zum PodSecurityPolicy-Zulassungscontroller finden Sie in der Kubernetes-Dokumentation.

Podsicherheits-Policy für Anwendungspods erstellen

Um eine Podsicherheits-Policy für Anwendungspods zu erstellen, erstellen Sie eine Rolle für den Zugriff auf die Podsicherheits-Policy und anschließend ein rolebinding, damit die Anwendungspods die Podsicherheits-Policy verwenden können:

  1. Erstellen Sie die Podsicherheits-Policy für die Anwendungspods:
    1. Definieren und speichern Sie die Podsicherheits-Policy in einer Datei. Beispiel: In acme-app-psp.yaml.

      Beispiel: Diese Policy (aus der Kubernetes-Dokumentation) verhindert einfach das Erstellen privilegierter Pods:

      
      apiVersion: policy/v1beta1
      kind: PodSecurityPolicy
      metadata:
        name: acme-app-psp
      spec:
        privileged: false  # Don't allow privileged pods!
        # The rest fills in some required fields.
        seLinux:
          rule: RunAsAny
        supplementalGroups:
          rule: RunAsAny
        runAsUser:
          rule: RunAsAny
        fsGroup:
          rule: RunAsAny
        volumes:
        - '*'
    2. Geben Sie den folgenden Befehl ein, um die Podsicherheits-Policy zu erstellen:

      kubectl create -f <filename>.yaml

      Beispiel:

      kubectl create -f acme-app-psp.yaml
  2. Erstellen Sie die Rolle (oder clusterrole), um auf die Podsicherheits-Policy zuzugreifen:
    1. Definieren und speichern Sie eine Rolle (oder clusterrole) in einer Datei. Beispiel: In acme-app-psp-crole.yaml.

      Beispiel:

      # Cluster role which grants access to the app pod security policy
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: acme-app-psp-crole
      rules:
      - apiGroups:
        - policy
        resourceNames:
        - acme-app-psp
        resources:
        - podsecuritypolicies
        verbs:
        - use
      
    2. Geben Sie den folgenden Befehl ein, um die Rolle (oder clusterrole) zu erstellen:

      kubectl create -f <filename>.yaml

      Beispiel:

      kubectl create -f acme-app-psp-crole.yaml
  3. Erstellen Sie das rolebinding (oder clusterrolebinding), um die Anwendungspods zur Verwendung der Podsicherheits-Policy zu autorisieren:
    1. Definieren und speichern Sie das rolebinding (oder clusterrolebinding) in einer Datei. Beispiel: In acme-app-psp-crole-bind.yaml.

      Beispiel:

      
      # Role binding which grants access to the app pod security policy
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: acme-app-psp-binding
        namespace: acme-namespace
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: acme-app-psp-crole
      subjects:
      # For all service accounts in acme-namespace
      - apiGroup: rbac.authorization.k8s.io
        kind: Group
        name: system:serviceaccounts:acme-namespace
    2. Geben Sie den folgenden Befehl ein, um das rolebinding (oder clusterrolebinding) zu erstellen:

      kubectl create -f <filename>.yaml

      Beispiel:

      kubectl create -f acme-app-psp-crole-bind.yaml

Wenn Sie eine Podsicherheits-Policy definiert und Anwendungspods zu deren Verwendung autorisiert haben, indem Sie eine Rolle und ein rolebinding (oder eine clusterrole und ein clusterrolebinding) erstellt haben, können Sie den PodSecurityPolicy-Zulassungscontroller aktivieren, um die Podsicherheits-Policy durchzusetzen (sofern noch nicht aktiviert).

PodSecurityPolicy-Zulassungscontroller mit der Konsole aktivieren

So aktivieren Sie den PodSecurityPolicy-Zulassungscontroller beim Erstellen neuer Cluster mit der Konsole:

  1. Melden Sie sich in der Konsole an.
  2. Befolgen Sie die Anweisungen zum Erstellen eines neuen Clusters unter Cluster mit explizit definierten Einstellungen im Workflow "Benutzerdefinierte Erstellung" mit der Konsole erstellen, und wählen Sie die Option Erweiterte Optionen anzeigen aus. Wählen Sie dann die Option Podsicherheits-Policys - Durchgesetzt aus. Diese Option aktiviert den PodSecurityPolicy-Zulassungscontroller.

    Wenn keine geeigneten Podsicherheits-Policys zusammen mit Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings) vorhanden sind, um Pods mit Policys zu verknüpfen, werden keine Anwendungspods im neuen Cluster akzeptiert.

  3. Befolgen Sie die Anweisungen zum Festlegen der verbleibenden Clusterdetails, und wählen Sie Cluster erstellen aus, um das neue Cluster zu erstellen.
  4. Befolgen Sie die Anweisungen unter Podsicherheits-Policy für Anwendungspods erstellen, um Podsicherheits-Policys für den PodSecurityPolicy-Zulassungscontroller zu erstellen, die beim Akzeptieren von Pods im neuen Cluster durchgesetzt werden sollen.

So aktivieren Sie den PodSecurityPolicy-Zulassungscontroller in vorhandenen Clustern mit der Konsole:

  1. Befolgen Sie die Anweisungen unter Podsicherheits-Policy für Anwendungspods erstellen, um Podsicherheits-Policys für den PodSecurityPolicy-Zulassungscontroller zu erstellen, die beim Akzeptieren von Pods im vorhandenen Cluster durchgesetzt werden sollen.

    Es wird dringend empfohlen, zunächst die Podsicherheits-Policys des Clusters in einer Entwicklungs- oder Testumgebung zu überprüfen. So können Sie sicher sein, dass die Podsicherheits-Policys in der erwarteten Weise funktionieren und dass Pods ordnungsgemäß im Cluster gestartet (oder abgelehnt) werden.

  2. Öffnen Sie das Navigationsmenü , und wählen Sie Entwicklerservices aus. Wählen Sie unter Container und Artefakte die Option Kubernetes-Cluster (OKE) aus.
  3. Wählen Sie ein Compartment aus, für das Sie eine Berechtigung besitzen.
  4. Wählen Sie auf der Seite Clusterliste den Namen des Clusters, das Sie ändern möchten.
  5. Wählen Sie auf der Registerkarte "Clusterdetails" neben Podsicherheits-Policys die Option Nicht durchgesetzt aus.
  6. Wählen Sie im Fenster Podsicherheits-Policys die Option Durchgesetzt aus.

    Ab jetzt werden nur dann neue Anwendungspods im Cluster akzeptiert, wenn geeignete Podsicherheits-Policys zusammen mit Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings) vorhanden sind, um Pods mit Policys zu verknüpfen. Beachten Sie, dass alle derzeit ausgeführten Pods unabhängig davon weiter ausgeführt werden.

  7. Wählen Sie Änderungen speichern aus.

Zulassungscontroller PodSecurityPolicy mit der Konsole deaktivieren

So deaktivieren Sie den Zulassungscontroller PodSecurityPolicy in Clustern, in denen er zuvor aktiviert war:

  1. Öffnen Sie das Navigationsmenü , und wählen Sie Entwicklerservices aus. Wählen Sie unter Container und Artefakte die Option Kubernetes-Cluster (OKE) aus.
  2. Wählen Sie ein Compartment aus, für das Sie eine Berechtigung besitzen.
  3. Wählen Sie auf der Seite Clusterliste den Namen des Clusters, das Sie ändern möchten.
  4. Wählen Sie auf der Registerkarte "Clusterdetails" neben Podsicherheits-Policys die Option Erzwungen aus.
  5. Wählen Sie im Fenster Podsicherheits-Policys die Option Nicht durchgesetzt aus.

    Ab jetzt werden neue Anwendungspods im Cluster akzeptiert, ohne dass Podsicherheits-Policys, Rollen (oder clusterroles) und rolebindings (oder clusterrolebindings) erforderlich sind. Beachten Sie, dass alle derzeit ausgeführten Pods unabhängig davon weiter ausgeführt werden.

  6. Wählen Sie Änderungen speichern aus.

kube-system.yaml-Referenz

Die Podsicherheits-Policy sowie clusterrole und clusterrolebinding für privilegierte Pods des Kubernetes-Systems werden automatisch erstellt, wenn Sie den PodSecurityPolicy-Zulassungscontroller eines Clusters aktivieren. Sie ermöglichen die Ausführung jedes Pods im Namespace "kube-system". Sie werden aus Definitionen in kube-system.yaml erstellt, wie unten dargestellt:


apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  annotations:
    # See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  name: oke-privileged
spec:
  allowedCapabilities:
  - '*'
  allowPrivilegeEscalation: true
  fsGroup:
    rule: 'RunAsAny'
  hostIPC: true
  hostNetwork: true
  hostPID: true
  hostPorts:
  - min: 0
    max: 65535
  privileged: true
  readOnlyRootFilesystem: false
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  volumes:
  - '*'
  
---
  
# Cluster role which grants access to the privileged pod security policy
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: oke-privileged-psp
rules:
- apiGroups:
  - policy
  resourceNames:
  - oke-privileged
  resources:
  - podsecuritypolicies
  verbs:
  - use
  
---
  
# Role binding for kube-system - allow kube-system service accounts - should take care of CNI i.e. flannel running in the kube-system namespace
# Assumes access to the kube-system is restricted
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-system-psp
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: oke-privileged-psp
subjects:
# For all service accounts in the kube-system namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-system