Arbeitslasten in dedizierten Knotenpools isolieren

In diesem Dokument wird beschrieben, wie Sie die Sicherheit und Verwaltung Ihres Kubernetes-Clusters verbessern können, indem Sie Containerarbeitslasten in dedizierten Knotenpools in Google Distributed Cloud (GDC) mit Air Gap isolieren. Durch die Isolierung Ihrer Arbeitslasten haben Sie mehr Kontrolle über Ihre Pods und verringern das Risiko von Rechteausweitung-Angriffen in Ihrem Kubernetes-Cluster. Weitere Informationen zu den Vorteilen und Einschränkungen von dedizierten Knotenpools finden Sie unter Knotenisolation – Übersicht.

Die Isolation Ihrer Containerarbeitslasten umfasst mehrere Workflows, darunter die folgenden:

  • Knotenpool markieren und mit Label versehen: Wenden Sie eine Markierung und ein Label auf einen Knotenpool an, damit Pods nicht in diesem Knotenpool ausgeführt werden, es sei denn, sie sind speziell dafür gekennzeichnet.

  • Toleranz und Knotenaffinitätsregel hinzufügen: Wenden Sie Toleranzen und Regeln auf Ihre Pods an, damit sie nur im dafür vorgesehenen Knotenpool ausgeführt werden.

  • Prüfen, ob die Trennung funktioniert: Prüfen Sie, ob in Ihren Knotenpools mit Taint nur die Pods ausgeführt werden, die Sie für die Ausführung dort gekennzeichnet haben.

Diese Workflows sind für Zielgruppen wie IT-Administratoren in der Gruppe der Plattformadministratoren, die für die Verwaltung der Knotenpools eines Kubernetes-Clusters verantwortlich sind, und Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung von Containerarbeitslasten verantwortlich sind, vorgesehen. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweis

Um die Aufgaben in diesem Dokument auszuführen, müssen Sie die erforderlichen Berechtigungen anfordern und Ihre Umgebung vorbereiten.

IAM-Rollen anfordern

Sie benötigen bestimmte Rollen, um die Berechtigungen zu erhalten, die zum Isolieren von Containerarbeitslasten in Ihrem Kubernetes-Cluster erforderlich sind. Die erforderlichen Rollen hängen davon ab, ob Sie in einem organisationsbezogenen freigegebenen Cluster oder in einem projektbezogenen Standardcluster arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Freigegebene Clusterrollen

Wenden Sie sich an den IAM-Administrator Ihrer Organisation, um die folgenden Rollen zum Markieren und Labeln eines Knotenpools in einem freigegebenen Cluster anzufordern:

  • Administrator des Nutzerclusters (user-cluster-admin): Ressourcen eines freigegebenen Clusters, der auf dem Management API-Server gehostet wird, erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die Knotenpools des gemeinsam genutzten Clusters.

  • Nutzercluster-Entwickler (user-cluster-developer): Erstellen, löschen, bearbeiten oder ansehen eines freigegebenen Clusters. Diese Rolle bietet Zugriff auf die Data Plane APIs, die im freigegebenen Cluster gehostet werden.

Diese Rollen sind nicht an einen Namespace gebunden.

Standard-Clusterrollen

Wenden Sie sich an Ihren Projekt-IAM-Administrator, um die folgenden Rollen zum Tainten und Labeln eines Knotenpools in einem Standardcluster anzufordern:

  • Clusteradministrator (cluster-admin): Kann alle Ressourcen in einem Standardcluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die APIs der Datenebene, die im Standardcluster gehostet werden und die Ressourcen des Clusters verwalten.

  • Cluster Developer (cluster-developer): Standardcluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die APIs der Datenebene, die im Standardcluster gehostet werden, der den Cluster verwaltet.

  • Standard Cluster Admin (standard-cluster-admin): Erstellen, löschen, bearbeiten oder ansehen der Ressourcen eines Standardclusters, der auf dem Management API-Server gehostet wird. Diese Rolle gewährt Zugriff auf die Knotenpools des Standardclusters.

Diese Rollen sind an Ihren Projekt-Namespace gebunden.

Umgebung vorbereiten

Wenn Sie Befehle für einen Kubernetes-Cluster über die API ausführen möchten, benötigen Sie die folgenden Ressourcen:

  • Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Kubernetes-Cluster.

  • Verwenden Sie den kubeconfig-Pfad des Kubernetes-Clusters, um KUBERNETES_CLUSTER_KUBECONFIG in dieser Anleitung zu ersetzen.

  • Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Management-API-Server.

  • Verwenden Sie den kubeconfig-Pfad des Management-API-Servers, um MANAGEMENT_API_SERVER in dieser Anleitung zu ersetzen.

  • Wählen Sie einen bestimmten Namen für die Knotenmarkierung und das Knotenlabel aus, das Sie für die dedizierten Knotenpools verwenden möchten. Beispiel: workloadType=untrusted.

Neuen Knotenpool markieren und mit Labels versehen

Wenn Sie einem neuen Knotenpool eine Markierung oder ein Label zuweisen, erhalten alle Knoten, einschließlich aller später hinzugefügten Knoten, automatisch die angegebenen Markierungen und Labels. Sie können ein Taint oder Label nicht aus einem Knotenpool entfernen, nachdem es angewendet wurde.

Führen Sie die folgenden Schritte aus, um einem neuen Knotenpool eine Markierung und ein Label hinzuzufügen:

  1. Bearbeiten Sie den Abschnitt nodePools der benutzerdefinierten Cluster-Ressource direkt beim Erstellen des Knotenpools:

    nodePools:
  # Several lines of code are omitted here.
  - machineTypeName: n2-standard-2-gdc
    name: nodepool-1
    nodeCount: 3
    taints:
    - key: "TAINT_KEY"
      value: "TAINT_VALUE"
      effect: "TAINT_EFFECT"
    labels:
      LABEL_KEY: LABEL_VALUE

    Ersetzen Sie Folgendes:

    • TAINT_KEY: Der Markierungsschlüsselteil des Schlüssel/Wert-Paares, das einem TAINT_EFFECT-Zeitplan zugeordnet ist. Beispiel: workloadType
    • TAINT_VALUE: Der Markierungswertteil des Schlüssel/Wert-Paares, das einem TAINT_EFFECT-Zeitplan zugeordnet ist. Beispiel: untrusted
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant; auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wenn er noch nicht auf dem Knoten ausgeführt wird, wird er nicht für den Knoten geplant.
    • LABEL_KEY: LABEL_VALUE: Die Schlüssel/Wert-Paare für die Knotenlabels, die den Selektoren entsprechen, die Sie in Ihren Arbeitslastmanifesten angeben.

  2. Wenden Sie die Cluster-Ressource an, um den neuen Knotenpool zu erstellen:

    kubectl apply -f cluster.yaml --kubeconfig MANAGEMENT_API_SERVER

    Ersetzen Sie MANAGEMENT_API_SERVER durch den kubeconfig-Pfad des zonalen API-Servers, auf dem der Kubernetes-Cluster gehostet wird.

Vorhandenen Knotenpool markieren und mit Labels versehen

Wenn Sie einem vorhandenen Knotenpool eine Markierung oder ein Label zuweisen möchten, müssen Sie die Änderungen auf jeden vorhandenen Knoten anwenden. Sie können Knotenpoolkonfigurationen nicht dynamisch aktualisieren.

Sie können ein Taint oder Label nicht aus einem Knotenpool entfernen, nachdem es angewendet wurde.

Führen Sie die folgenden Schritte aus, um einem vorhandenen Knotenpool eine Markierung und ein Label hinzuzufügen:

  1. Listen Sie die Knoten im dedizierten Knotenpool auf:

    kubectl get node --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG \
    -l baremetal.cluster.gke.io/node-pool=NODE_POOL_NAME

    Ersetzen Sie die folgenden Variablen:

    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.
    • NODE_POOL_NAME ist der Name des dedizierten Knotenpools.

    Notieren Sie sich aus der Ausgabe die Knoten-ID aller Knoten im Knotenpool.

  2. Wenden Sie die Taints auf jeden Knoten im Knotenpool an:

    kubectl taint nodes NODE_ID \
    TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NODE_ID: die ID des Worker-Knotens im dedizierten Knotenpool.
    • TAINT_KEY=TAINT_VALUE: ein Schlüssel/Wert-Paar, das mit einem TAINT_EFFECT-Zeitplan verknüpft ist. Beispiel: workloadType=untrusted.
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant; auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wird er noch nicht auf dem Knoten ausgeführt, wird er nicht für den Knoten geplant.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

  3. Wenden Sie für jeden Knoten im Knotenpool die Labels an, die den Selektoren entsprechen, die Sie in Ihren Containerarbeitslasten definieren:

    kubectl label NODE_ID \
    LABEL_KEY:LABEL_VALUE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NODE_ID: die ID des Worker-Knotens im dedizierten Knotenpool.
    • LABEL_KEY:LABEL_VALUE: Die Schlüssel/Wert-Paare für die Knotenlabels, die den Selektoren entsprechen, die Sie in Ihren Workload-Manifesten angeben.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

Toleranz und Knotenaffinitätsregel hinzufügen

Nachdem Sie den dedizierten Knotenpool markiert haben, können keine Arbeitslasten darin geplant werden, es sei denn, sie haben eine Toleranz, die der hinzugefügten Markierung entspricht. Fügen Sie der Spezifikation Ihrer Arbeitslasten die Toleranz hinzu, damit diese Pods im markierten Knotenpool geplant werden können.

Wenn Sie den dedizierten Knotenpool mit einem Label versehen haben, können Sie auch eine Knotenaffinitätsregel hinzufügen, um GDC anzuweisen, Ihre Arbeitslasten nur in diesem Knotenpool zu planen.

Führen Sie die folgenden Schritte aus, um Ihre Containerarbeitslast für die Ausführung im dedizierten Knotenpool zu konfigurieren:

  1. Fügen Sie .spec.template.specder Manifestdatei für die Containerarbeitslast, z. B. einer benutzerdefinierten Ressource vom Typ Deployment, die folgenden Abschnitte hinzu:

    tolerations:
- key: TAINT_KEY
  operator: Equal
  value: TAINT_VALUE
  effect: TAINT_EFFECT
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: LABEL_KEY
          operator: In
          values:
          - "LABEL_VALUE"

    Ersetzen Sie Folgendes:

    • TAINT_KEY: der Markierungsschlüssel, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • TAINT_VALUE: der Markierungswert, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant; auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wird er noch nicht auf dem Knoten ausgeführt, wird er nicht für den Knoten geplant.
    • LABEL_KEY: der Labelschlüssel, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • LABEL_VALUE: der Knotenlabelwert, den Sie auf Ihren dedizierten Knotenpool angewendet haben.

    Im folgenden Beispiel wird der Deployment-Ressource eine Toleranz für die Markierung workloadType=untrusted:NoExecute und eine Knotenaffinitätsregel für das Knotenlabel workloadType=untrusted hinzugefügt:

    kind: Deployment
apiVersion: apps/v1
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      - key: workloadType
        operator: Equal
        value: untrusted
        effect: NoExecute
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: workloadType
                operator: In
                values:
                - "untrusted"
      containers:
      - name: my-app
        image: harbor-1.org-1.zone1.google.gdc.test/harborproject/my-app
        ports:
        - containerPort: 80
      imagePullSecrets:
      - name: SECRET

  2. Containerarbeitslast aktualisieren:

    kubectl apply -f deployment.yaml -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NAMESPACE: der Namespace Ihrer Containerarbeitslast. Bei freigegebenen Clustern muss es sich um einen Projekt-Namespace handeln. Bei Standardclustern kann es sich um einen beliebigen Namespace handeln.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

GDC erstellt die betroffenen Pods neu. Die Knotenaffinitätsregel erzwingt die Pods für den von Ihnen erstellten dedizierten Knotenpool. Die Toleranz erlaubt es, nur diese Pods auf den Knoten zu platzieren.

Prüfen, ob die Trennung funktioniert

Prüfen Sie, ob die von Ihnen angegebenen Pods im Knotenpool mit dem Label ausgeführt werden.

  • Listen Sie die Pods im angegebenen Namespace auf:

    kubectl get pods -o=wide -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NAMESPACE: der Namespace Ihrer Containerarbeitslast. Bei freigegebenen Clustern muss es sich um einen Projekt-Namespace handeln. Bei Standardclustern kann es sich um einen beliebigen Namespace handeln.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

    Die Ausgabe sieht dann ungefähr so aus:

    pod/kube-abc-12tyuj
pod/kube-abc-39oplef
pod/kube-abc-95rzkap

    Prüfen Sie, ob Ihre Arbeitslasten im dedizierten Knotenpool ausgeführt werden.

Nächste Schritte