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

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).

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. Wählen Sie auf der Listenseite Cluster den Namen des Clusters, das Sie ändern möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
3. Wählen Sie auf der Registerkarte Clusterdetails neben Podsicherheits-Policys die Option Nicht durchgesetzt aus.

4. 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.

5. Wählen Sie Änderungen speichern aus.

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

1. Wählen Sie auf der Listenseite Cluster den Namen des Clusters, das Sie ändern möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
2. Wählen Sie auf der Registerkarte Clusterdetails neben Podsicherheits-Policys die Option Durchgesetzt aus.

3. 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.

4. Wählen Sie Änderungen speichern aus.

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.

Verwenden Sie die folgenden Vorgänge, um den PodSecurityPolicy-Zulassungscontroller zu aktivieren:

• CreateCluster beim Erstellen neuer Cluster
• Cluster aktualisieren beim Ändern vorhandener Cluster

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