PodSecurityPolicies verwenden

Auf dieser Seite wird erläutert, wie Sie PodSecurityPolicies in Google Kubernetes Engine verwenden.

Übersicht

Eine PodSecurityPolicy ist eine Ressource der Zugangssteuerung. Diese Ressource können Sie anlegen, um Anfragen zum Erstellen und Aktualisieren von Pods im Cluster zu validieren. Die PodSecurityPolicy definiert eine Reihe von Bedingungen, die Pods erfüllen müssen, um vom Cluster akzeptiert zu werden. Wenn eine Anfrage zum Erstellen oder Aktualisieren eines Pods die Bedingungen in der PodSecurityPolicy nicht erfüllt, wird diese Anfrage abgelehnt und ein Fehler zurückgegeben.

Wenn Sie PodSecurityPolicy verwenden möchten, müssen Sie zuerst Richtlinien definieren, denen neue und aktualisierte Pods entsprechen müssen. Anschließend aktivieren Sie den PodSecurityPolicy-Admission-Controller, der Anfragen zum Erstellen und Aktualisieren von Pods anhand der definierten Richtlinien validiert.

Wenn mehrere PodSecurityPolicies verfügbar sind, verwendet der Admission-Controller die erste erfolgreich validierte Richtlinie. Richtlinien sind alphabetisch geordnet und der Controller bevorzugt Richtlinien, die den Pod nicht ändern, gegenüber solchen, die dies tun.

PodSecurityPolicy ist in GKE-Clustern verfügbar, auf denen Kubernetes Version 1.8.6 oder höher ausgeführt wird.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

PodSecurityPolicies definieren

Sie müssen PodSecurityPolicy-Ressourcen in Ihrem Cluster definieren, bevor der PodSecurityPolicy-Controller Pods im Cluster validieren und akzeptieren kann.

PodSecurityPolicies geben eine Liste mit Einschränkungen, Anforderungen und Standardeinstellungen für Pods an, die unter der Richtlinie erstellt werden. Hierzu gehören beispielsweise die eingeschränkte Nutzung von privilegierten Containern, hostPath-Volumes und Hostnetzwerken oder die Vorgabe, dass alle Container mit einem seccomp-Profil ausgeführt werden müssen. Der PodSecurityPolicy-Admission-Controller validiert Anfragen auf Basis verfügbarer PodSecurityPolicies.

Die folgende Beispiel-PodSecurityPolicy my-psp.yaml verhindert einfach, dass privilegierte Pods erstellt werden. Die Richtlinie wirkt sich auch auf verschiedene andere Steuerungsaspekte aus. So wird dadurch etwa der Zugriff auf alle verfügbaren Volumes gewährt.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-psp
spec:
  privileged: false  # Prevents creation of privileged Pods
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Die PodSecurityPolicy-Spezifikation kann die Absicherung zahlreicher Steuerungsaspekte gewährleisten. Die im obigen Beispiel angegebenen Steuerungsaspekte seLinux, supplementalGroups, runAsUser und fsGroup sind alle auf RunAsAny festgelegt. Damit wird angegeben, dass alle gültigen Werte für diese Felder mit dieser Richtlinie verwendet werden können.

Weitere Informationen zu PodSecurityPolicies und ihren Steuerungsaspekten finden Sie unter Was ist eine Pod-Sicherheitsrichtlinie? und der Richtlinienreferenz in der Kubernetes-Dokumentation.

Sie erstellen diese Ressource mit dem kubectl-Befehlszeilentool:

kubectl apply -f my-psp.yaml

Weitere Beispiele zum Konfigurieren von PodSecurityPolicies finden Sie unter Beispiel auf der PodSecurityPolicy-Seite der Kubernetes-Dokumentation.

Richtlinien autorisieren

Konten mit der Rolle cluster-admin können mithilfe der rollenbasierten Zugriffssteuerung eine Rolle des Typs Role oder ClusterRole erstellen, die den gewünschten Dienstkonten Zugriff auf PodSecurityPolicies gewährt. ClusterRole gewährt clusterweite Berechtigungen und Role gewährt Berechtigungen in einem von Ihnen definierten Namespace.

Die folgende ClusterRole my-clusterrole.yaml gewährt beispielsweise Zugriff auf die PodSecurityPolicy my-psp, wie durch verb: use angegeben:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: my-clusterrole
rules:
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  verbs:
  - use
  resourceNames:
  - my-psp

Erstellen Sie die ClusterRole mit folgendem Befehl:

kubectl apply -f my-clusterrole.yaml

Wenn Sie eine Role oder ClusterRole erstellt haben, gewähren Sie diese den gewünschten Dienstkonten. Erstellen Sie hierfür eine Ressource vom Typ RoleBinding oder ClusterRoleBinding.

Mit der RoleBinding-Ressource my-rolebinding.yaml wird die ClusterRole my-clusterrole mit den Dienstkonten in einem bestimmten Namespace, hier my-namespace, verbunden:

# Bind the ClusterRole to the desired set of service accounts.
# Policies should typically be bound to service accounts in a namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-rolebinding
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: my-clusterrole
subjects:
# Example: All service accounts in my-namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
# Example: A specific service account in my-namespace
- kind: ServiceAccount # Omit apiGroup
  name: default
  namespace: my-namespace

In dieser RoleBinding geschieht Folgendes:

  • Das Feld subjects gibt an, an welche Konten die ClusterRole gebunden ist.
  • Das erste Element ist eine Gruppe mit dem Namen system:serviceaccounts, die alle Dienstkonten im Cluster umfasst.
  • Das zweite Element ist ein bestimmtes Dienstkonto mit dem Namen default, das das Standarddienstkonto im Namespace angibt.

Erstellen Sie die RoleBinding mit folgendem Befehl:

kubectl apply -f my-rolebinding.yaml

Weitere Informationen zu RBAC finden Sie unter RBAC-Autorisierung verwenden.

PodSecurityPolicy-Controller aktivieren

Damit Sie den PodSecurityPolicy-Admission-Controller verwenden können, müssen Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster mit dem Flag --enable-pod-security-policy aktualisieren.

Führen Sie folgenden Befehl aus, um mit PodSecurityPolicy einen neuen Cluster zu erstellen:

gcloud beta container clusters create cluster-name --enable-pod-security-policy

So aktualisieren Sie einen vorhandenen Cluster:

gcloud beta container clusters update cluster-name --enable-pod-security-policy

PodSecurityPolicy-Controller deaktivieren

Führen Sie zum Deaktivieren des PodSecurityPolicy-Controllers folgenden Befehl aus:

gcloud beta container clusters update cluster-name --no-enable-pod-security-policy

Wenn Sie den Controller deaktivieren, werden vorhandene Richtlinien vom Cluster nicht mehr validiert und deren Standardeinstellungen nicht mehr übernommen. Die Richtlinien werden allerdings nicht gelöscht. Bindungen werden ebenfalls nicht gelöscht.

Mit NetworkPolicy arbeiten

Wenn Sie eine NetworkPolicy verwenden und einen Pod haben, für den eine PodSecurityPolicy gilt, erstellen Sie eine RBAC Role oder ClusterRole, die zur Verwendung der PodSecurityPolicy berechtigt ist. Binden Sie dann die Role oder ClusterRole an das Dienstkonto des Pods. Es reicht in diesem Fall nicht aus, Berechtigungen für Nutzerkonten zu erteilen. Weitere Informationen finden Sie unter Richtlinien autorisieren.

Weitere Informationen