Von OpenShift zu GKE Enterprise migrieren: OpenShift-SCCs zu GKE Enterprise migrieren

Last reviewed 2022-01-24 UTC

Mit diesem Dokument können Sie die Migration von Sicherheitsrichtlinien aus OpenShift-SCCs (Security Context Constraints, Sicherheitskontextbeschränkungen) planen, die in einem OpenShift-Quellcluster zu einem GKE Enterprise-Zielcluster definiert sind. Die Implementierung verwendet die Einschränkungen von Policy Controller, um die migrierten Richtlinien für den Zielcluster zu definieren.

In diesem Dokument wird davon ausgegangen, dass Sie mit Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren vertraut sind. Es wird davon ausgegangen, dass Sie mit OpenShift- und Sicherheitskontextbeschränkungen vertraut sind und Zugriff auf einen OpenShift-Quellcluster und einen GKE Enterprise-Zielcluster haben.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration zu Google Cloud. Eine Übersicht über die Reihe finden Sie unter Migration zu Google Cloud: Migrationspfad auswählen.

Dieses Dokument ist Teil einer Reihe zur Migration von Containern zu Google Cloud:

Dieses Dokument ist nützlich, wenn Sie OpenShift SCCs zu GKE Enterprise migrieren möchten. Dieses Dokument ist auch hilfreich, wenn Sie die Möglichkeit zur Migration in Betracht ziehen und sich ein Bild davon machen möchten.

Dieses Dokument basiert auf Konzepten, die in Migration zu Google Cloud: Einstieg, inContainer zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren, in Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren und in Best Practices für GKE-Netzwerke beschrieben werden. Es enthält wo passend Links zu diesen Dokumenten.

OpenShift-SCCs

SCCs sind OpenShift-spezifische Ressourcen, mit denen Richtlinien für Pods definiert werden, die die Aktionen angeben, die ein Pod ausführen kann, und auf welche Ressourcen er auf Knoten zugreifen kann. Wenn Sie eine API-Anfrage zum Erstellen eines Pods stellen, werten SCCs Pod-Anfragen mit Blick auf Prozessberechtigungen anhand einer Reihe von Richtlinien aus, die über die SCC definiert werden. Die SCCs evaluieren die Anfragen, um die Ausführung der Pods gemäß konfigurierten Richtlinien zuzulassen oder zu verweigern. Weitere Informationen zu OpenShift-SCCs finden Sie unter Sicherheitskontext-Einschränkungen verwalten.

Standard-OpenShift-SCCs

OpenShift 4.x-Cluster enthalten eine Reihe von Standard-SCCs, die im Blogpost Managing SCCs in OpenShift von Red Hat beschrieben werden.

Config Sync und Policy Controller.

In diesem Abschnitt werden Config Sync und Policy Controller beschrieben. Dieser Abschnitt enthält Links zu der entsprechenden Dokumentation und Anleitung zum Einrichten des Policy Controllers, um Migrationsaufgaben auszuführen, die weiter unten in diesem Dokument beschrieben werden.

Config Sync

Mit Config Sync können Sie ein gemeinsames Git-kompatibles Repository verwenden, um die Konfiguration einer Ressource, die für einen von GKE Enterprise verwalteten Kubernetes-Cluster gilt, zentral zu definieren. Sie wenden diese Konfiguration auf mehrere Cluster an.

Policy Controller

Policy Controller ist ein dynamischer Admission-Controller von Kubernetes, der die Compliance Ihrer Cluster in Bezug auf zentral definierte Richtlinien kontrolliert, auditiert und erzwingt. “ Richtlinien Controller basiert auf dem Open-Source-Projekt Open Policy Agent (OPA) Gatekeeper.

Config Sync und Policy Controller einrichten

Zum Implementieren der Sicherheitsrichtlinien, die die OpenShift-SCCs widerspiegeln, aktivieren Sie die Komponenten Config Sync und Policy Controller für jeden Ihrer Zielcluster. In diesem Abschnitt wird beschrieben, wie Sie diese Komponenten einrichten. Im Abschnitt OpenShift-SCCs migrieren weiter unten in diesem Dokument wird beschrieben, wie Sie Sicherheitsrichtlinien mit Einschränkungsvorlagen von Policy Controller implementieren.

Bei der Einrichtung von Policy Controller empfiehlt es sich, systembezogene Namespaces, die keine Anwendungs-Pods ausführen, in das Feld Ausgenommene Namespaces einzufügen. Durch die Ausnahme systembezogener Namespaces können Sie das Risiko vermeiden, jeden System-Pod zu blockieren, für den erhöhte Berechtigungen erforderlich sind. Systembezogene Namespaces in einem GKE Enterprise-Cluster können Folgendes enthalten:

  • kube-system
  • kube-public
  • gke-connect
  • gke-system
  • config-management-system
  • config-management-monitoring
  • gatekeeper-system
  • istio-system
  • cnrm-system
  • knative-serving
  • monitoring-system

Nachdem Sie Policy Controller mit den vorherigen Ausnahmen eingerichtet haben, schließen Sie die Namespaces aus der Anwendung von Einschränkungen aus. Fügen Sie dazu jedem Namespace das Label admission.gatekeeper.sh/ignore=true hinzu. Wenn Sie das Label nicht jedem Namespace hinzufügen, können System-Pods (und damit der gesamter Cluster) von restriktiven Richtlinien betroffen sein.

OpenShift-SCCs zu Richtlinien-Controller-Einschränkungen migrieren

In diesem Abschnitt wird beschrieben, wie Sie SCCs aus Ihrem OpenShift-Cluster exportieren und GKE Enterprise Policy Controller-Zieleinschränkungen so konfigurieren, dass sie den erforderlichen Richtlinien entsprechen. In diesem Abschnitt werden auch einige Unterschiede zwischen SCCs und Policy Controller-Einschränkungen beschrieben, damit Sie die Migration entsprechend planen können.

OpenShift-SCCs bewerten

Zum Exportieren einer Liste von den und der Konfiguration der in Ihrem OpenShift-Cluster installierten SCCs können Sie die folgenden Befehle verwenden:

  1. Rufen Sie eine Liste aller SCCs ab:

    oc get scc

  2. Exportieren Sie die Konfiguration jeder SCC:

    oc get scc SCC_NAME > SCC_NAME.yaml

    Ersetzen Sie SCC_NAME durch den Namen der SCC, für den Sie die Konfiguration exportieren möchten.

Nachdem Sie die Konfiguration exportiert haben, können Sie sie analysieren und die Tabelle im folgenden Abschnitt OpenShift-SCCs zuordnen verwenden, um Richtlinien-Controller-Einschränkungen zu konfigurieren, die Ihren Anforderungen zur Anwendungssicherheit entsprechen.

OpenShift-SCCs zu Richtlinien-Controller-Einschränkungsvorlagen zuordnen

In der folgenden Tabelle sind die Einschränkungen und Einstellungen für Policy Controller aufgeführt, die den Open-Source-SCC-Feldern und ihren möglichen Werten entsprechen. Verwenden Sie die Tabelle, um Einschränkungen für Target Policy Controller zu konfigurieren, die den Sicherheitsanforderungen der Anwendung entsprechen, die über OpenShift-SCCs in der Quellumgebung implementiert wurden. Der Abschnitt Beispiel für eine End-to-End-Migration weiter unten in diesem Dokument enthält ein Beispiel für die Verwendung der Informationen in der Tabelle.

OpenShift-SCC-Feld Typ/mögliche Werte Einschränkungsvorlage für Policy Controller Spezifikation der Policy Controller-Einschränkung
allowPrivilegedContainer: Boolesch K8sPSPPrivilegedContainer Verhindert privilegierte Container, wenn angewendet.
allowHostIPC: Boolesch K8sPSPHostNamespace Verhindert den Zugriff auf den Host pid und den Namespace ipc, falls angewendet.
allowHostPID: Boolesch K8sPSPHostNamespace Verhindert den Zugriff auf den Host pid und den Namespace ipc, falls angewendet.
allowHostNetwork: Boolesch K8sPSPHostNetworkingPorts Hat einen booleschen Parameter, um den Zugriff auf das Hostnetzwerk zu verhindern, und kann einen Bereich für zugängliche Hostports definieren.
allowHostPorts: Boolesch K8sPSPHostNetworkingPorts Hat einen booleschen Parameter, um den Zugriff auf das Hostnetzwerk zu verhindern, und kann einen Bereich für zugängliche Hostports definieren.
readOnlyRootFilesystem: Boolesch K8sPSPReadOnlyRootFilesystem Ermöglicht das Bereitstellen des Container-Stamm-Dateisystems als nur schreibgeschützt, wenn angewendet.
allowPrivilegeEscalation: true Boolesch K8sPSPAllowPrivilegeEscalationContainer Verhindert Pods mit dem Sicherheitskontext AllowPrivilegeEscalation auf „true“ gesetzt, wenn angewendet.
allowHostDirVolumePlugin: Boolesch K8sPSPVolumeTypes Hat einen Parameter, um die Liste der zulässigen Volume-Typen (wie im SCC) zu definieren, einschließlich des Hostverzeichnisses.
volumes: Arrayliste mit zulässigen Volume-Typen K8sPSPVolumeTypes Hat einen Parameter, um die Liste der zulässigen Volume-Typen (wie im SCC) zu definieren, einschließlich des Hostverzeichnisses.
allowedCapabilities: Arrayliste der Linux-Funktionen, die angefordert werden können. K8sPSPCapabilities Enthält Parameter zum Definieren von Linux-Funktionen, die angefordert werden können (allowedCapabilities) und die unzulässig sind (requiredDropCapabilites).

Kann nicht zum direkten Hinzufügen oder Löschen der aufgelisteten Funktionen verwendet werden, wie in defaultAddCapabilities: und requiredDropCapabilities: in OpenShift-SCCs möglich.
defaultAddCapabilities: Arrayliste von Linux-Funktionen, die jedem Container hinzugefügt werden müssen. K8sPSPCapabilities Enthält Parameter zum Definieren von Linux-Funktionen, die angefordert werden können (allowedCapabilities) und die unzulässig sind (requiredDropCapabilites).

Kann nicht zum direkten Hinzufügen oder Löschen der aufgelisteten Funktionen verwendet werden, wie in defaultAddCapabilities: und requiredDropCapabilities: in OpenShift-SCCs möglich.
requiredDropCapabilities: Arrayliste von Linux-Funktionen, die automatisch aus dem Pod oder Container entfernt werden. K8sPSPCapabilities Enthält Parameter zum Definieren von Linux-Funktionen, die angefordert werden können (allowedCapabilities) und die unzulässig sind (requiredDropCapabilites).

Kann nicht zum direkten Hinzufügen oder Löschen der aufgelisteten Funktionen verwendet werden, wie in defaultAddCapabilities: und requiredDropCapabilities: in OpenShift-SCCs möglich.
fsGroup: Enthält einen type: key mit einem der folgenden Werte:
  • MustRunAs: Erfordert die Angabe von mindestens einem Bereich, wenn keine vorab zugeordneten Werte verwendet werden.
  • RunAsAny: Ermöglicht die Angabe einer beliebigen fsGroup-ID.
 K8sPSPAllowedUsers Hiermit können Sie Regeln definieren, die eine ähnliche Funktion wie type: key in SCC haben sowie die id-Bereiche für die Parameter runAsUser, runAsGroup, supplementalGroups und fsGroup.

Kann verwendet werden, um zulässige Bereiche für Nutzer, Gruppen, SupplementalGroups oder FS-Gruppen zu definieren, aber nicht um die Nutzer-ID direkt im Pod festzulegen, wie das in OpenShift-SCCs erfolgen kann.
runAsUser: Enthält einen type: key mit einem der folgenden Werte:
  • MustRunAs: Erfordert die Konfigurationen eines runAsUser.
  • MustRunAsRange: Erfordert, dass Mindest- und Höchstwerte definiert werden, wenn keine vorab zugewiesenen Werte aus dem Namespace verwendet werden.
  • MustRunAsNonRoot: Erfordert, dass Der Pod mit einem runAsUser ungleich null gesendet wird oder die Anweisung USER im Image definiert hat.
  • RunAsAny: Ermöglicht die Angabe von beliebigem runAsUser.
 K8sPSPAllowedUsers Hiermit können Sie Regeln definieren, die eine ähnliche Funktion wie type: key in SCC haben sowie die id-Bereiche für die Parameter runAsUser, runAsGroup, supplementalGroups und fsGroup.

Kann verwendet werden, um zulässige Bereiche für Nutzer, Gruppen, SupplementalGroups oder FS-Gruppen zu definieren, aber nicht um die Nutzer-ID direkt im Pod festzulegen, wie das in OpenShift-SCCs erfolgen kann.
supplementalGroups: Enthält einen type: key mit einem der folgenden Werte:
  • MustRunAs: Erfordert die Angabe von mindestens einem Bereich, wenn keine vorab zugewiesenen Werte aus dem Namespace verwendet werden
  • RunAsAny: Ermöglicht die Angabe beliebiger supplementalGroups.
 K8sPSPAllowedUsers Hiermit können Sie Regeln definieren, die eine ähnliche Funktion wie type: key in SCC haben sowie die id-Bereiche für die Parameter runAsUser, runAsGroup, supplementalGroups und fsGroup.

Kann verwendet werden, um zulässige Bereiche für Nutzer, Gruppen, SupplementalGroups oder FS-Gruppen zu definieren, aber nicht um die Nutzer-ID direkt im Pod festzulegen, wie das in OpenShift-SCCs erfolgen kann.
seLinuxContext: Enthält einen type: key mit einem der folgenden Werte:
  • MustRunAs: seLinuxOptions muss konfiguriert werden, wenn keine vorab zugewiesenen Werte aus dem Namespace verwendet werden.
  • RunAsAny: Ermöglicht die Angabe von beliebigem seLinuxOptions.
 K8sPSPSELinuxV2 Hat einen Parameter allowedSELinuxOptions, wo Sie die Ebene, die Rolle, den Typ und den Nutzer festlegen können, die seLinuxOptions erlaubt

Unterschiede zwischen OpenShift-SCCs und Richtlinien-Controller-Einschränkungen

In diesem Abschnitt werden einige Unterschiede zwischen Policy Controller-Einschränkungen und OpenShift-SCCs beschrieben. Berücksichtigen Sie diese Unterschiede, bevor Sie mithilfe der vorherigen Tabelle Einschränkungen für Ihre Zielumgebung implementieren.

So werden Einschränkungen auf Ressourcen angewendet

Sie können Nutzern und Gruppen mithilfe der Spezifikation users: oder group:, die im SCC-Objekt vorhanden ist, OpenShift-SCCs zuweisen. Mit OpenShift 4.x und höheren Versionen können Sie Nutzern oder Gruppen auch mithilfe von rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) SCCs zuweisen. SCCs haben auch ein priority:-Feld, das zum Sortieren der SCCs verwendet wird, die auf einen Pod angewendet werden.

Policy Controller-Einschränkungen werden auf Zielcluster, -Namespaces oder -Pods angewendet, die bestimmte Ressourcenselektoren in der Einschränkung verwenden, anstatt auf den Nutzer oder das Dienstkonto abzuzielen. Weitere Informationen finden Sie in der Dokumentation zu Richtlinien-Controller. Mithilfe der spezifischen Ressourcenselektoren wird sichergestellt, dass sich der Pod gleich verhält, unabhängig davon, ob er von einem Nutzer mit geringer Berechtigung über ein Deployment-Tool ausgeführt oder von einem Clusteradministrator über die Befehlszeile gestartet wird.

Policy Controller-Einschränkungen unterstützen auch einen Probelaufmodus, mit dem Sie Richtlinien testen und Verstöße vor der tatsächlichen Erzwingung prüfen können. Mit diesem Modus können Sie Auswirkungen auf vorhandene Arbeitslasten verhindern, während SCCs immer erzwungen werden, sofern für den Nutzer zutreffend.

SCC-Pod-Mutation mit vorab zugewiesenen Werten in OpenShift-Namespaces

In OpenShift-SCCs können Sie den zugehörigen Sicherheitskontext jedes Pods ändern, auf den der SCC mit einer bestimmten ID aus einem vorab zugewiesenen Bereich angewendet wird, der von Annotationen in Namespaces bereitgestellt wird. Dazu verwenden Sie die Felder RunAsUser, fsGroup, supplementalGroups und seLinuxContext mit dem Strategietyp MustRunAs oder MustRunAsRange.

Betrachten Sie beispielsweise eine restricted-SCC, die ein RunAsUser-Feld mit einem Strategietyp MustRunAsRange ohne in der SCC definierten Bereich enthält. In diesem Szenario erhält jeder Pod, auf den die SCC angewendet wird, eine RunAsUser-ID aus dem Bereich, der in der Annotation openshift.io/sa.scc.uid-range im Namespace des Pods angegeben ist.

Einschränkungen von Policy Controller bieten zusammen mit Mutationsfunktionen sowohl Pod-Validierung als auch Mutation. Die Einschränkungen verwenden jedoch keine Annotationen in Namespaces, um Werte für Pod-Sicherheitskontexte bereitzustellen. Der nächste Abschnitt Beispiel für eine End-to-End-Migration enthält ein Beispiel dafür, wie Ihre Anwendungsbereitstellungsteams Sicherheitskontexte auf Pods explizit konfigurieren müssen, damit sie Einschränkungen befolgen, die den zuvor aufgeführten ähnlich sind.

Beispiel für End-to-End-Migration

Dieser Abschnitt enthält eine Beispielzielmanifestdatei, die alle Einschränkungen und Mutatoren von Policy Controller enthält, die Sie brauchen, um die folgenden OpenShift-Standard-SCCs auf Ihrem GKE Enterprise-Zielcluster zuordnen zu können:

  • privileged
  • anyuid
  • nonroot
  • restricted

Abhängig vom Namespace, in dem ein Pod ausgeführt wird, erhält der Pod unterschiedliche Einschränkunge für Richtlinien-Controller, wenn Sie die SCC-Richtlinien zuordnen, die in einer OpenShift-Quellumgebung definiert sind:

  • Arbeitslasten, die den höchsten privilegierten Zugriff benötigen, z. B. die Möglichkeit, im privilegierten Modus ausgeführt oder auf eine Hostressource zuzugreifen, sollten in einem der ausgenommenen Namespaces ausgeführt werden, die in der Policy Controller-Konfiguration definiert sind.

    Auf ausgenommene Namespaces werden keine Einschränkungen angewendet. Arbeitslasten mit diesem höchsten privilegierten Zugriff sind in der Regel Systemkomponenten oder Arbeitslasten, auf die die privilegierte SCC in der OpenShift-Quellumgebung angewendet wurde.

  • Für alle Pods, die in einem nicht ausgenommenen Namespace erstellt werden, gelten die restriktivsten Einschränkungen. Diese Einschränkungen verweigern den Zugriff auf alle Hostfeatures und erfordern, dass die Pods mit einer UID ausgeführt werden, die Teil eines bestimmten Bereichs ist. Diese Konfiguration entspricht den Richtlinien, die von OpenShift-restricted-SCC angewendet werden. Zu dieser Konfiguration gehören unter anderem:

    • Pods, die in einem Namespace mit dem Label security=anyuid erstellt werden, erhalten die oben genannten Einschränkungen, dürfen jedoch mit jeder UID und jeder GID ausgeführt werden. Dies entspricht den Einschränkungen der OpenShift-SCC anyuid.
    • Pods, die in einem Namespace mit dem Label security=nonroot erstellt werden, erhalten die oben genannten Einschränkungen. Die Pods können jedoch mit jeder Nicht-Root-UID ausgeführt werden. Dies entspricht den Einschränkungen der OpenShift-SCC nonroot.

Beispiel für Zielmanifest

Das folgende Beispiel zeigt ein einzelnes Manifest, das eine Reihe von Policy Controller-Einschränkungen und -Mutatoren enthält, die dem im vorherigen End-to-End-Migrationsbeispiel beschriebenen Verhalten entsprechen. Wir empfehlen Ihnen, die Einschränkungen oder ihren Umfang in diesem Beispiel anhand der Anforderungen Ihrer Organisation zu prüfen und anzupassen.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNamespace
metadata:
  name: psp-host-namespace
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNetworkingPorts
metadata:
  name: psp-host-network-ports
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    hostNetwork: false
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: restricted-capabilities
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid"]
  location: "spec.containers[name:*].securityContext.capabilities.drop"
  parameters:
    assign:
      value: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: restricted-capabilities
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid"]
  parameters:
    requiredDropCapabilities: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: anyuid-capabilities
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["anyuid"]
  location: "spec.containers[name:*].securityContext.capabilities.drop"
  parameters:
    assign:
      value: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: anyuid-capabilities
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["anyuid"]
  parameters:
    requiredDropCapabilities: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: restricted-users-and-groups
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid","nonroot"]
  parameters:
    runAsUser:
      rule: MustRunAs # MustRunAsNonRoot # RunAsAny
      ranges:
        - min: 1000
          max: 2000
    fsGroup:
      rule: MustRunAs # MayRunAs # RunAsAny
      ranges:
        - min: 1000
          max: 2000
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: nonroot-users-and-groups
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["nonroot"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot
    fsGroup:
      rule: MustRunAsNonRoot
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: psp-volume-types
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    volumes:
      - configMap
      - downwardAPI
      - emptyDir
      - nfs
      - persistentVolumeClaim
      - projected
      - secret

Die Einschränkung restricted-users-and-groups im Beispielmanifest verwendet die Vorlage K8sPSPAllowedUsers, um einen Beispielbereich von 1.000 bis 2.000 für runAsUser:- und fsGroup:-Parameter explizit festzulegen. Jeder Pod, der nicht für die Verwendung einer ID in diesem Bereich für runAsUser: und fsGroup: festgelegt ist, wird blockiert.

GKE Enterprise und Kubernetes verwenden keine Namespace-Annotationen, um Pods automatisch mit einer bestimmten Nutzer- oder Gruppen-ID zu mutieren. Wenn Sie den UID-Bereich wie im vorherigen Beispiel begrenzen möchten, müssen Ihre Anwendungsbereitstellungsteams daher explizit eine konforme UID für den erstellten Pod festlegen oder die Einschränkung vollständig entfernen, um alle IDs zuzulassen.

Das folgende Beispiel zeigt ein Pod-Manifest, das die vorherigen Einschränkungen in jedem Namespace erfüllt, in dem Sie es erstellen. Das Manifest ist konform mit dem SCC restricted:

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod-example
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 1100
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo

Nächste Schritte

  • Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center