Informationen zu Sicherheitsprofilen

Die Sicherheitsstandards für Kubernetes-Pods definieren die folgenden drei Profile.

Privilegiert

Die Standardkonfiguration für die Pod-Sicherheit erzwingt global das privileged Kubernetes-Pod-Sicherheitsprofil, das unbeschränkt ist und bekannte Berechtigungseskalationen ermöglicht, und generiert Warnungen und Prüfereignisse auf der Basis der Richtlinien, die vom restricted-Profil festgelegt werden.

Grundlegende Verpflichtungen

Das Profil baseline ist ein restriktives Profil, das bekannte Berechtigungseskalationen verhindert. Lässt die (minimal angegebene) Standardkonfiguration des Pods zu.

Eingeschränkt

Das restricted-Profil ist stark eingeschränkt und entspricht den aktuellen Best Practices für die Abschottung des Pods.

Weitere Informationen zu Pod-Sicherheitsprofilen finden Sie unter Profildetails in der Dokumentation zu Kubernetes.

Pod-Sicherheitszulassung enthält drei Modi, die definieren, welche Aktion die Steuerebene ausführt, wenn ein potenzieller Verstoß erkannt wird.

durchsetzen

Richtlinienverstöße führen dazu, dass der Pod zurückgewiesen wird.

prüfen

Richtlinienverstöße lösen das Hinzufügen einer Prüfannotation zu dem im Prüfprotokoll aufgezeichneten Ereignis aus, sind aber ansonsten zulässig.

warn

Richtlinienverstöße lösen eine dem Benutzer zugewandte Warnung aus, sind aber ansonsten zulässig.

Wenn sich die Sicherheitsstandards oder Profilimplementierungen ändern, um neue Funktionen zu adressieren, können Sie die Aufnahme der Pod-Sicherheit für die Verwendung einer bestimmten Version der Rollen konfigurieren. Die folgenden Versionen werden unterstützt.

• Eine Kubernetes major.minor-Version (z. B. v1.25)
• latest

Was ist, wenn Pod Security Admission nicht die richtige Wahl für mich ist?

Während die Zugangsberechtigung für die Pod-Sicherheit immer aktiviert ist, kann sie einer von mehreren Zugangscontrollern sein. Sie können Kubernetes-Zugangscontroller anderer Anbieter konfigurieren, um andere Sicherheitsrichtlinienmodelle zu implementieren, die Ihrem Anwendungsfall entsprechen.

Wenn Sie Pod Security Admission für die Durchsetzung, Warnung und Prüfung mithilfe des privileged-Profils konfigurieren, lässt die Steuerebene die Ausführung aller Pods zu. Anschließend können Sie weitere Zugangscontroller konfigurieren, um sie zurückzuweisen.

Sie können einen Zugangscontroller eines anderen Anbieters installieren, solange er keine der folgenden Aktionen ausführt.

• Es installiert keine eigenen Pod-Sicherheitsrichtlinien (PSPs).
• Es ist nicht darauf angewiesen, dass PSPs Teile der Richtlinie durchsetzen.

Namensbereichsbezeichnungen für Pod-Sicherheit konfigurieren

Sie können den Zugangssteuerungsmodus definieren, den Sie für die Pod-Sicherheit in jedem Namensbereich verwenden möchten. Kubernetes definiert eine Gruppe von Bezeichnungen, die Sie festlegen können, um zu definieren, welches der vordefinierten Pod-Sicherheitsstandardprofile Sie für einen Namespace verwenden wollen. Die von Ihnen ausgewählte Bezeichnung definiert, welche Aktion die Steuerebene ausführt, wenn ein potenzieller Verstoß erkannt wird.

IBM Cloud Kubernetes Service fügt den folgenden Namensbereichen standardmäßig die privileged-Pod-Sicherheitsbezeichnungen hinzu. Diese Namensbereiche sind über das Profil privileged mit enforce, audit und warn gekennzeichnet.

• kube-system
• ibm-system
• ibm-operators
• calico-system (Version 1.29 und höher)
• tigera-operator (Version 1.29 und höher)
• calico-apiserver (Version 1.31 )

Entfernen oder ändern Sie die Bezeichnungen für diese Namensbereiche nicht.

Ein Namensbereich kann beschriftet werden, um das Pod-Sicherheitsprofil für eine beliebige oder alle modes für die Pod-Sicherheit festzulegen.

Sie können beispielsweise einen Namensbereich kennzeichnen, um das privileged-Profil zusätzlich zur Verwendung von warn oder audit mithilfe des baseline-Profils durchzusetzen.

Diese Bezeichnung ermöglicht es Administratoren und Anwendungsentwicklern, Anwendungen im Trockenlauf auszuführen, indem sie nur nach Warnungen und Prüfdatensätzen für das Profil baseline suchen, ohne Pods abzulehnen. Anschließend können Sie die erforderlichen Änderungen an Ihren Workloads vornehmen, bevor Sie den Durchsetzungsmodus in baseline ändern.

Die Namensbereichsbezeichnungen für die Podsicherheitszulassung haben das Format pod-security.kubernetes.io/<MODE>: <LEVEL> und pod-security.kubernetes.io/<MODE>-version: <VERSION>.

• pod-security.kubernetes.io/enforce
• pod-security.kubernetes.io/enforce-version
• pod-security.kubernetes.io/audit
• pod-security.kubernetes.io/audit-version
• pod-security.kubernetes.io/warn
• pod-security.kubernetes.io/warn-version

Verwenden Sie die folgenden Bezeichnungen, um einen Namensbereich für die Durchsetzung des privileged-Profils zu kennzeichnen und Warnungen und Prüfereignisse für Verstöße gegen das baseline-Profil zu generieren.

• pod-security.kubernetes.io/enforce: privileged
• pod-security.kubernetes.io/enforce-version: latest
• pod-security.kubernetes.io/audit: baseline
• pod-security.kubernetes.io/audit-version: latest
• pod-security.kubernetes.io/warn: baseline
• pod-security.kubernetes.io/warn-version: latest

Standard-Plug-in-Konfiguration für Pod-Sicherheitszulassung

IBM Cloud Kubernetes Service verwendet standardmäßig die folgende PodSecurityConfiguration.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Konfiguration des Pod Security Admission-Plug-ins anpassen

Die clusterweite Konfiguration des Pod-Sicherheits-Admission-Plug-ins legt das Verhalten von enforce, audit und warn für alle Namensbereiche fest, die keine Pod-Sicherheitskennsätze oder Ausnahmen haben.

Für Kubernetes- 1.24-Cluster muss apiVersion die sein pod-security.admission.config.k8s.io/v1beta. 1.25 und höher pod-security.admission.config.k8s.io/v1 wird bevorzugt, die v1beta API-Version kann jedoch weiterhin verwendet werden.

1. Erstellen Sie eine YAML-Datei, die eine PodSecurityConfiguration-Ressource enthält. Sie können die Standardkonfiguration zum Starten verwenden.

   apiVersion: pod-security.admission.config.k8s.io/v1
   kind: PodSecurityConfiguration
   defaults:
     enforce: "privileged"
     enforce-version: "latest"
     audit: "privileged"
     audit-version: "latest"
     warn: "privileged"
     warn-version: "latest"
   exemptions:
     usernames: []
     runtimeClasses: []
     namespaces: []
   

2. Nehmen Sie die gewünschten Anpassungen vor. Lesen Sie die folgenden Informationen zu jedem Abschnitt der Konfiguration.

defaults

Der Abschnitt defaults der Konfiguration definiert clusterweite Standardwerte für Namensbereiche, die keine Pod-Sicherheitskennsätze haben. Die Felder können dieselben Werte wie die entsprechenden Namensbereichsbezeichnungen haben.

exemptions

Im Abschnitt exemptions der Konfiguration können Sie Pods erstellen, die andernfalls aufgrund der Richtlinie, die einem bestimmten Namespace zugeordnet ist, nicht zulässig sind. Zu den Ausnahmedimensionen gehören die folgenden Fälle:

  - Benutzernamen: Anforderungen von Benutzern mit einem nicht authentifizierten (oder impersonierten) Benutzernamen werden ignoriert. Benutzernamen sind in der Regel IAM-Benutzer oder Servicekonten. Beispiel: `usernames: [ "IAM#user@example.com" ]`. Sie können den Benutzernamen, der einem `admin kubeconfig`-Clientzertifikat zugeordnet ist, auch ausschließen. Wenn Sie ein `admin kubeconfig`-Zertifikat angeben wollen, ist der Benutzername die Komponente `CN` des aktuellen Clientzertifikats.

      ```sh {: pre}
      kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
      /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
      ```
      Im folgenden Beispiel lautet der Benutzername `IBMid-27000xxxxx-admin-2023-05-12`. Wenn Sie eine neue `admin kubeconfig` erhalten, kann der Benutzername abweichen.

      ```sh {: pre}
      openssl x509 -in <client-certificate> -subject -noout`
      subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
      ```
  - RuntimeClassNames: Pods und Workload-Ressourcen, die einen ausgenommenen Laufzeitklassennamen angeben, werden ignoriert.
  - Namensbereiche: Pods und Workloadressourcen in einem ausgeschlossenen Namensbereich werden ignoriert.

1. Speichern Sie Ihre YAML-Datei für Anpassungen.

2. Führen Sie den Befehl ibmcloud ks cluster master pod-security set aus.

   ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
   

Wenn Sie den Befehl ibmcloud ks cluster master pod-security set ausführen, wird die Podsicherheitszulassung auf die Standardkonfiguration zurückgesetzt, wenn Sie keine Konfigurationsdatei angeben.