Schreibgeschützten Port für Kubelet in GKE-Clustern deaktivieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie den unsicheren schreibgeschützten Kubelet-Port in GKE-Clustern (Google Kubernetes Engine) deaktivieren, um das Risiko eines nicht autorisierten Zugriffs auf das Kubelet zu reduzieren und Anwendungen zu einem sichereren Port zu migrieren.

In Kubernetes-Clustern, einschließlich GKE, stellt der auf Knoten ausgeführte kubelet-Prozess eine schreibgeschützte API mit dem unsicheren Port 10255 bereit. Kubernetes führt an diesem Port keine Authentifizierungs- oder Autorisierungsprüfungen durch. Kubelet stellt dieselben Endpunkte auf dem sichereren, authentifizierten Port 10250 bereit.

Deaktivieren Sie den schreibgeschützten Port von Kubelet und wechseln Sie alle Arbeitslasten, die Port 10255 verwenden, um stattdessen den sichereren Port 10250 zu verwenden.

Hinweis :Der schreibgeschützte Kubelet-Port ist in neuen Clustern mit Version 1.32 oder höher standardmäßig deaktiviert.

Hinweise

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

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

• Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Voraussetzungen

• Sie können den unsicheren schreibgeschützten Kubelet-Port nur in GKE-Version 1.26.4-gke.500 oder höher deaktivieren.

Prüfen, ob unsichere Ports verwendet werden, und Anwendungen migrieren

Bevor Sie den unsicheren schreibgeschützten Port deaktivieren, müssen Sie alle laufenden Anwendungen, die den Port verwenden, zum sichereren schreibgeschützten Port migrieren. Zu den Arbeitslasten, die möglicherweise migriert werden müssen, gehören Pipelines für benutzerdefinierte Messwerte und Arbeitslasten, die auf kubelet-Endpunkte zugreifen.

• Verwenden Sie für Arbeitslasten, die Zugriff auf die von der kubelet API auf dem Knoten bereitgestellten Informationen benötigen, z. B. Messwerte, den Port 10250.
• Verwenden Sie für Arbeitslasten, die Kubernetes-Informationen über die kubelet API auf dem Knoten abrufen, z. B. zum Auflisten von Pods auf dem Knoten, stattdessen die Kubernetes API.

Prüfen, ob Anwendungen den unsicheren schreibgeschützten Kubelet-Port verwenden

In diesem Abschnitt erfahren Sie, wie Sie in Ihrem Cluster nach der Verwendung unsicherer Ports suchen.

Portnutzung im Autopilot-Modus prüfen

Wenn Sie die Portnutzung in einem Autopilot-Cluster prüfen möchten, muss mindestens eine Arbeitslast, die kein DaemonSet ist, im Cluster ausgeführt werden. Wenn Sie die folgenden Schritte in einem leeren Autopilot-Cluster ausführen, sind die Ergebnisse möglicherweise ungültig.

1. Speichern Sie das folgende Manifest als read-only-port-metrics.yaml:

   # Create a namespace for the DaemonSet that checks for port usage.
   apiVersion: v1
   kind: Namespace
   metadata:
     name: node-metrics-printer-namespace
   ---
   # Grant access to read node metrics in the cluster.
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: node-metrics-printer-role
   rules:
   - apiGroups:
     - ""
     resources:
     - nodes/metrics
     verbs:
     - get
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: node-metrics-printer-binding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: node-metrics-printer-role
   # Bind the ClusterRole to the ServiceAccount that the DaemonSet will use.
   subjects:
   - kind: ServiceAccount
     name: node-metrics-printer-sa
     namespace: node-metrics-printer-namespace
   ---
   # Create a ServiceAccount for the DaemonSet.
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: node-metrics-printer-sa
     namespace: node-metrics-printer-namespace
   ---
   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: node-metrics-printer
     namespace: node-metrics-printer-namespace
   spec:
     selector:
       matchLabels:
         app: node-metrics-printer
     template:
       metadata:
         labels:
           app: node-metrics-printer
       spec:
         # Assign the ServiceAccount to the DaemonSet.
         serviceAccountName: node-metrics-printer-sa
         containers:
         - name: metrics-printer
           image: us-docker.pkg.dev/cloud-builders/ga/v1/curl:latest
           command: ["sh", "-c"]
           # Call the /metrics endpoint using the insecure kubelet read-only
           # port.
           args:
           - 'while true; do curl -s --cacert "${CA_CERT}" -H "Authorization: Bearer $(cat ${TOKEN_FILE})" "https://${NODE_ADDRESS}:10250/metrics"|grep kubelet_http_requests_total; sleep 20; done'
           env:
           # Provide credentials and the IP address for the command.
           - name: CA_CERT
             value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
           - name: TOKEN_FILE
             value: /var/run/secrets/kubernetes.io/serviceaccount/token
           - name: NODE_ADDRESS
             valueFrom:
               fieldRef:
                 fieldPath: status.hostIP
   

   Das Manifest tut Folgendes:

   1. Erstellt einen Namespace und richtet RBAC-Rollen ein, um das Lesen von Knotenmesswerten zu ermöglichen.
   2. Stellt ein DaemonSet bereit, das die Kubelet-Messwerte für den unsicheren schreibgeschützten Port prüft.

2. Stellen Sie das Manifest bereit:

   kubectl create -f read-only-port-metrics.yaml
   

3. Prüfen Sie die DaemonSet-Logs:

   kubectl logs --namespace=node-metrics-printer-namespace \
       --all-containers --prefix \
       --selector=app=node-metrics-printer
   

   Wenn die Ausgabe Ergebnisse enthält, die den String server_type=readonly enthalten, verwendet eine Anwendung den unsicheren schreibgeschützten Port.

Portnutzung im Standardmodus prüfen

Führen Sie den folgenden Befehl auf mindestens einem Knoten in jedem Knotenpool in Ihrem Cluster aus:

kubectl get --raw /api/v1/nodes/NODE_NAME/proxy/metrics | grep http_requests_total | grep readonly

Ersetzen Sie NODE_NAME durch den Namen des Knotens.

Wenn die Ausgabe Einträge mit dem String server_type="readonly" enthält, können die folgenden Szenarien eintreten:

• Arbeitslasten auf dem Knoten verwenden den unsicheren schreibgeschützten Kubelet-Port.
• Nachdem Sie den unsicheren Port deaktiviert haben, gibt der Befehl weiterhin den String server_type="readonly" zurück. Das liegt daran, dass der Messwert kubelet_http_requests_total die kumulative Anzahl der HTTP-Anfragen darstellt, die der Kubelet-Server seit dem letzten Neustart empfangen hat. Diese Nummer wird nicht zurückgesetzt, wenn der unsichere Port deaktiviert wird. Diese Zahl wird zurückgesetzt, nachdem GKE den Kubelet-Server neu gestartet hat, z. B. bei einem Knotenupgrade. Weitere Informationen finden Sie in der Kubernetes-Messwertreferenz.

Wenn die Ausgabe leer ist, verwenden keine Arbeitslasten auf diesem Knoten den unsicheren schreibgeschützten Port.

Arbeitslasten identifizieren, die den unsicheren schreibgeschützten Kubelet-Port verwenden

Wenn Sie die Arbeitslasten ermitteln möchten, die den unsicheren Port verwenden, prüfen Sie die Konfigurationsdateien der Arbeitslast, z. B. ConfigMaps und Pods.

Führen Sie folgende Befehle aus:

kubectl get pods --all-namespaces -o yaml | grep 10255
kubectl get configmaps --all-namespaces -o yaml | grep 10255

Wenn die Ausgabe des Befehls nicht leer ist, verwenden Sie das folgende Skript, um die Namen der ConfigMaps oder Pods zu ermitteln, die den unsicheren Port verwenden:

# This function checks if a Kubernetes resource is using the insecure port 10255.
#
# Arguments:
#  $1 - Resource type (e.g., pod, configmap, )
#  $2 - Resource name
#  $3 - Namespace
#
# Output:
#  Prints a message indicating whether the resource is using the insecure port.
isUsingInsecurePort() {
  resource_type=$1
  resource_name=$2
  namespace=$3

  config=$(kubectl get $resource_type $resource_name -n $namespace -o yaml)

  # Check if kubectl output is empty
  if [[ -z "$config" ]]; then
    echo "No configuration file detected for $resource_type: $resource_name (Namespace: $namespace)"
    return
  fi

  if echo "$config" | grep -q "10255"; then
    echo "Warning: The configuration file ($resource_type: $namespace/$resource_name) is using insecure port 10255. It is recommended to migrate to port 10250 for enhanced security."
  else
    echo "Info: The configuration file ($resource_type: $namespace/$resource_name) is not using insecure port 10255."
  fi
}

# Get the list of ConfigMaps with their namespaces
configmaps=$(kubectl get configmaps -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name | tail -n +2 | awk '{print $1"/"$2}')

# Iterate over each ConfigMap
for configmap in $configmaps; do
  namespace=$(echo $configmap | cut -d/ -f1)
  configmap_name=$(echo $configmap | cut -d/ -f2)
  isUsingInsecurePort "configmap" "$configmap_name" "$namespace"
done

# Get the list of Pods with their namespaces
pods=$(kubectl get pods -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name | tail -n +2 | awk '{print $1"/"$2}')

# Iterate over each Pod
for pod in $pods; do
  namespace=$(echo $pod | cut -d/ -f1)
  pod_name=$(echo $pod | cut -d/ -f2)
  isUsingInsecurePort "pod" "$pod_name" "$namespace"
done

Nachdem Sie die relevanten Arbeitslasten identifiziert haben, migrieren Sie sie zur Verwendung des sicheren Ports 10250. Führen Sie dazu die Schritte im folgenden Abschnitt aus.

Migration vom unsicheren schreibgeschützten Port für kubelet

Die Migration einer Anwendung zum sicheren Port umfasst in der Regel die folgenden Schritte:

1. Aktualisieren Sie URLs oder Endpunkte, die auf den unsicheren schreibgeschützten Port verweisen, sodass stattdessen der sichere schreibgeschützte Port verwendet wird. Ändern Sie beispielsweise http://203.0.113.104:10255 in http://203.0.113.104:10250.

2. Legen Sie das CA-Zertifikat des HTTP-Clients auf das Cluster-CA-Zertifikat fest. Führen Sie den folgenden Befehl aus, um dieses Zertifikat zu finden:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format="value(masterAuth.clusterCaCertificate)"
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name Ihres Clusters.
   • LOCATION: Der Standort Ihres Clusters.

Für den authentifizierten Port 10250 müssen Sie dem Subjekt die entsprechenden RBAC-Rollen gewähren, damit es auf die spezifischen Ressourcen zugreifen kann. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Kubelet-Autorisierung.

Wenn Ihre Arbeitslast den Endpunkt /pods auf dem unsicheren schreibgeschützten Kubelet-Port verwendet, müssen Sie die RBAC-Berechtigung nodes/proxy für den Zugriff auf den Endpunkt auf dem sicheren Kubelet-Port erteilen. nodes/proxy ist eine leistungsstarke Berechtigung, die Sie in GKE Autopilot-Clustern nicht erteilen können und die Sie auch in GKE-Standardclustern nicht erteilen sollten. Verwenden Sie stattdessen die Kubernetes API mit einem fieldSelector für den Knotennamen.

Wenn Sie Drittanbieteranwendungen verwenden, die vom unsicheren schreibgeschützten Kubelet-Port abhängen, wenden Sie sich an den Anwendungsanbieter, um eine Anleitung zur Migration zum sicheren Port 10250 zu erhalten.

Beispiel für die Migration

Stellen Sie sich einen Pod vor, der Messwerte aus dem unsicheren schreibgeschützten Kubelet-Port abfragt.

apiVersion: v1
kind: Pod
metadata:
  name: kubelet-readonly-example
spec:
  restartPolicy: Never
  containers:
  - name: kubelet-readonly-example
    image: us-docker.pkg.dev/cloud-builders/ga/v1/curl:latest
    command:
      - curl
      - http://${NODE_ADDRESS}:10255/metrics
    env:
    - name: NODE_ADDRESS
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP

Diese Anwendung führt Folgendes aus:

• Verwendet das ServiceAccount default im Namespace default
• Führt den Befehl curl für den /metrics-Endpunkt auf dem Knoten aus.

So aktualisieren Sie diesen Pod, damit er den sicheren Port 10250 verwendet:

1. Erstellen Sie eine ClusterRole mit Zugriff zum Abrufen von Knotenmesswerten:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: curl-authenticated-role
   rules:
   # Grant access to read node metrics in the cluster.
   - apiGroups:
     - ""
     resources:
     - nodes/metrics
     verbs:
     - get
   

2. Binden Sie die ClusterRole an die Identität Ihrer Anwendung:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: curl-authenticated-role-binding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: curl-authenticated-role
   # Bind the ClusterRole to the default ServiceAccount in the default
   # namespace.
   subjects:
   - kind: ServiceAccount
     name: default
     namespace: default
   

3. Aktualisieren Sie den curl-Befehl, damit der sichere Portendpunkt mit den entsprechenden Autorisierungsheadern verwendet wird:

   apiVersion: v1
   kind: Pod
   metadata:
     name: kubelet-authenticated-example
   spec:
     restartPolicy: Never
     containers:
     - name: kubelet-readonly-example
       image: us-docker.pkg.dev/cloud-builders/ga/v1/curl:latest
       env:
       - name: NODE_ADDRESS
         valueFrom:
           fieldRef:
             fieldPath: status.hostIP
       # Update the command to send a request with the ServiceAccount
       # credentials in the header.
       command:
       - sh
       - -c
       - 'curl -s --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization:
         Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://${NODE_ADDRESS}:10250/metrics'
   

VPC-Firewallregeln ändern

Wenn Sie Arbeitslasten aktualisieren, um den Port 10250 zu verwenden, erstellen Sie Firewallregeln, damit Pods im Cluster den Port in Ihren Knoten-IP-Adressbereichen erreichen können. Die Firewallregeln sollten Folgendes tun:

• Eingehenden Traffic an TCP-Port 10250 in Ihren Knoten-IP-Adressbereichen aus internen Pod-IP-Adressbereichen zulassen
• Eingehender Traffic an den TCP-Port 10250 in Ihren Knoten-IP-Adressbereichen aus dem öffentlichen Internet wird abgelehnt.

Achtung :Ändern Sie nicht die Standard-Firewallregeln, die GKE in Ihren Clustern erstellt. Erstellen Sie neue Regeln für den sicheren Port. Das Ändern der Standardregeln kann zu unerwartetem Verhalten in Ihren Arbeitslasten führen.

Sie können die folgenden Standard-GKE-Firewallregeln als Vorlage für die Parameter verwenden, die Sie in Ihren neuen Regeln angeben müssen:

• gke-[cluster-name]-[cluster-hash]-inkubelet
• gke-[cluster-name]-[cluster-hash]-exkubelet

Unsicheren schreibgeschützten Port für Autopilot-Cluster deaktivieren

Sie können den unsicheren schreibgeschützten Kubelet-Port für neue und vorhandene Autopilot-Cluster deaktivieren.

Wenn Sie den unsicheren schreibgeschützten Kubelet-Port in einem Autopilot-Cluster deaktivieren möchten, verwenden Sie das Flag --no-autoprovisioning-enable-insecure-kubelet-readonly-port, wie im folgenden Befehl. Alle neuen und vorhandenen Knoten im Cluster verwenden den Port nicht mehr.

Achtung: Mit diesem Befehl wird ein Rolling Update aller Knoten in Ihrem Cluster gestartet. Dies kann zu Unterbrechungen bei laufenden Arbeitslasten führen.

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-autoprovisioning-enable-insecure-kubelet-readonly-port

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
• LOCATION: Der Standort Ihres vorhandenen Clusters.

Sie können das Flag --no-autoprovisioning-enable-insecure-kubelet-readonly-port auch verwenden, wenn Sie einen neuen Cluster mit dem Befehl gcloud container clusters create-auto erstellen.

Unsicheren schreibgeschützten Port in Standardclustern deaktivieren

Sie können den unsicheren schreibgeschützten Kubelet-Port für ganze Standardcluster oder für einzelne Knotenpools deaktivieren. Wir empfehlen, den Port für den gesamten Cluster zu deaktivieren.

Wenn Sie die automatische Knotenbereitstellung verwenden, übernehmen automatisch bereitgestellte Knotenpools die Porteinstellung, die Sie auf Clusterebene angeben. Optional können Sie eine andere Einstellung für automatisch bereitgestellte Knotenpools angeben. Wir empfehlen jedoch, den Port auf allen Knoten in Ihrem Cluster zu deaktivieren.

Sie können auch eine Konfigurationsdatei des Knotensystems verwenden, um den unsicheren schreibgeschützten kubelet-Port deklarativ zu deaktivieren. Wenn Sie diese Datei verwenden, können Sie die Befehle in den folgenden Abschnitten nicht verwenden, um die kubelet-Einstellung zu steuern.

Unsicheren schreibgeschützten Port in vorhandenen Standardclustern deaktivieren

Wenn Sie den unsicheren schreibgeschützten Kubelet-Port für einen vorhandenen Standardcluster deaktivieren möchten, verwenden Sie das Flag --no-enable-insecure-kubelet-readonly-port wie im folgenden Befehl. Neue Knotenpools verwenden den unsicheren Port nicht. GKE aktualisiert vorhandene Knotenpools nicht automatisch.

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-insecure-kubelet-readonly-port

Ersetzen Sie Folgendes:

• CLUSTER_NAME: Der Name Ihres vorhandenen Standardclusters.
• LOCATION: Der Standort Ihres vorhandenen Standardclusters.

Sie können das Flag --no-autoprovisioning-enable-insecure-kubelet-readonly-port auch verwenden, wenn Sie einen neuen Cluster mit dem Befehl gcloud container clusters create erstellen.

Unsicheren schreibgeschützten Port in Standardknotenpools deaktivieren

Wir empfehlen, die Einstellung für den schreibgeschützten Port in jedem Fall auf Clusterebene festzulegen. Wenn Sie den schreibgeschützten Port in einem vorhandenen Cluster deaktiviert haben, in dem bereits Knotenpools ausgeführt wurden, verwenden Sie den folgenden Befehl, um den Port in diesen Knotenpools zu deaktivieren.

Achtung: Mit diesem Befehl wird ein Rolling Update der Knoten in diesem Knotenpool gestartet. Dies kann zu Unterbrechungen bei den laufenden Arbeitslasten führen.

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-insecure-kubelet-readonly-port

Ersetzen Sie Folgendes:

• NODE_POOL_NAME: Der Name des Knotenpools.
• CLUSTER_NAME ist der Name des Clusters.
• LOCATION: Der Standort des Clusters.

Prüfen Sie, ob der Port deaktiviert ist

Wenn Sie prüfen möchten, ob der unsichere schreibgeschützte Port für kubelet deaktiviert ist, beschreiben Sie die GKE-Ressource.

Portstatus in Autopilot-Clustern prüfen

Führen Sie dazu diesen Befehl aus:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodePoolAutoConfig \
    --format="value(nodeKubeletConfig)"

Ersetzen Sie Folgendes:

• CLUSTER_NAME: Der Name Ihres Autopilot-Clusters.
• LOCATION: Der Standort Ihres Autopilot-Clusters.

Wenn der Port deaktiviert ist, sieht die Ausgabe so aus:

insecureKubeletReadonlyPortEnabled: false

Portstatus in Standardclustern prüfen

Der Portstatus ist im Feld nodePoolDefaults.nodeConfigDefaults.nodeKubeletConfig verfügbar, wenn Sie Ihren Cluster mit der GKE API beschreiben.

In Standardclustern sehen Sie auch das Feld nodeConfig, in dem ein Wert für den Status des schreibgeschützten Kubelet-Ports festgelegt wird. Das Feld nodeConfig ist veraltet und gilt nur für den Standardknotenpool, den GKE beim Erstellen eines neuen Clusters im Standardmodus erstellt. Der Status des Ports im eingestellten Feld nodeConfig gilt nicht für andere Knotenpools im Cluster.

Führen Sie dazu diesen Befehl aus:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodePoolDefaults.nodeConfigDefaults \
    --format="value(nodeKubeletConfig)"

Ersetzen Sie Folgendes:

• CLUSTER_NAME: Der Name Ihres Standardclusters.
• LOCATION: Der Standort Ihres Standardclusters.

Wenn der Port deaktiviert ist, sieht die Ausgabe so aus:

insecureKubeletReadonlyPortEnabled: false

Wenn die Ausgabe dieses Befehls leer ist, ist der unsichere schreibgeschützte Port kubelet möglicherweise noch aktiviert. Führen Sie den Befehl im Abschnitt Unsicheren schreibgeschützten Port in vorhandenen Standardclustern deaktivieren aus, um den Port zu deaktivieren.

Portstatus in Standard-Knotenpools prüfen

Führen Sie dazu diesen Befehl aus:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --flatten=config \
    --format="value(kubeletConfig)"

Ersetzen Sie Folgendes:

• NODE_POOL_NAME: Der Name des Knotenpools.
• CLUSTER_NAME ist der Name des Clusters.
• LOCATION: Der Standort des Clusters.

Wenn der Port deaktiviert ist, sieht die Ausgabe so aus:

insecureKubeletReadonlyPortEnabled: false

Verwendung unsicherer Ports mit einer Organisationsrichtlinie verhindern

Mit dem Organization Policy Service können Sie erzwingen, dass in Clustern in Ihrer Organisation, Ihrem Ordner oder Ihrem Projekt der unsichere schreibgeschützte Port kubelet deaktiviert werden muss. Um diese Anforderung zu erzwingen, erstellen Sie eine benutzerdefinierte Einschränkung und verweisen dann in einer Organisationsrichtlinie auf diese Einschränkung. Wenn Sie Erstellungs- oder Aktualisierungsvorgänge ablehnen möchten, wenn der unsichere schreibgeschützte Port kubelet aktiviert ist, sehen Sie sich die folgenden Beispiele an:

• Die folgende benutzerdefinierte Einschränkung lehnt Clustererstellungs- oder ‑aktualisierungsvorgänge ab, wenn der unsichere schreibgeschützte Port kubelet aktiviert ist:

  name: organizations/ORGANIZATION_ID/customConstraints/custom.disableClusterInsecureKubeletReadOnlyPort
  resourceTypes:
  - container.googleapis.com/Cluster
  methodTypes:
  - CREATE
  - UPDATE
  condition:
    "resource.NodeKubeletConfig.insecureKubeletReadonlyPortEnabled == true ||
    resource.AutoprovisioningNodePoolDefaults.insecureKubeletReadonlyPortEnabled == true ||
    resource.NodePoolAutoConfig.NodeKubeletConfig.insecureKubeletReadonlyPortEnabled == true"
  actionType: DENY
  displayName: Disable insecure kubelet read-only port
  description: All new and existing clusters must disable the insecure kubelet read-only port.
  

  Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.

• Die folgende benutzerdefinierte Einschränkung lehnt Vorgänge zum Erstellen oder Aktualisieren von Knotenpools ab, wenn der unsichere schreibgeschützte Port kubelet aktiviert ist:

  name: organizations/ORGANIZATION_ID/customConstraints/custom.disableNodePoolInsecureKubeletReadOnlyPort
  resourceTypes:
  - container.googleapis.com/NodePool
  methodTypes:
  - CREATE
  - UPDATE
  condition: "resource.NodeConfig.NodeKubeletConfig.insecureKubeletReadonlyPortEnabled == true"
  actionType: DENY
  displayName: Disable insecure kubelet read-only port
  description: All new and existing node pools must disable the insecure kubelet read-only port.
  

  Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.

Weitere Informationen zum Erstellen einer benutzerdefinierten Einschränkung und zum Erzwingen der Einschränkung in einer Organisationsrichtlinie finden Sie unter Aktionen für GKE-Ressourcen mithilfe von benutzerdefinierten Organisationsrichtlinien einschränken.