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

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

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 diese Aufgabe verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Achten Sie darauf, dass 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.

Nutzung des unsicheren Ports prüfen und Anwendungen migrieren

Bevor Sie den unsicheren schreibgeschützten Port deaktivieren, migrieren Sie alle laufenden Anwendungen, die den Port verwenden, zum sichereren schreibgeschützten Port. 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 stattdessen die Kubernetes API für Arbeitslasten, die Kubernetes-Informationen über die kubelet API auf dem Knoten abrufen, z. B. zum Auflisten von Pods auf dem Knoten.

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

In diesem Abschnitt wird beschrieben, wie Sie die Nutzung des unsicheren Ports in Ihrem Cluster prüfen.

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 die 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 der server_type="readonly" String enthält, können die folgenden Szenarien auftreten:

  • Arbeitslasten auf dem Knoten verwenden den unsicheren schreibgeschützten Kubelet-Port.
  • Nach dem Deaktivieren des unsicheren Ports gibt der Befehl weiterhin die server_type="readonly" String 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 erhalten hat. Diese Zahl 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

Prüfen Sie die Konfigurationsdateien der Arbeitslast, z. B. ConfigMaps und Pods, um die Arbeitslasten zu identifizieren, die den unsicheren Port verwenden.

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 so, dass sie den sicheren Port 10250 verwenden. Führen Sie dazu die Schritte im folgenden Abschnitt aus.

Vom unsicheren schreibgeschützten Kubelet-Port migrieren

Normalerweise umfasst die Migration einer Anwendung zum sicheren Port die folgenden Schritte:

  1. Aktualisieren Sie URLs oder Endpunkte, die auf den unsicheren schreibgeschützten Port verweisen, so dass sie stattdessen den sicheren schreibgeschützten Port verwenden. Ändern Sie beispielsweise http://203.0.113.104:10255 in http://203.0.113.104:10250.

  2. Legen Sie das Zertifikat der Zertifizierungsstelle (Certificate Authority, CA) 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 jeweiligen 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 gewähren können und die Sie in GKE-Standardclustern nicht gewähren sollten. Verwenden Sie die Kubernetes API mit einem fieldSelector für den Knotennamen stattdessen.

Wenn Sie Drittanbieteranwendungen verwenden, die vom unsicheren schreibgeschützten Kubelet-Port abhängig sind, fragen Sie den Anwendungsanbieter nach einer Anleitung zur Migration zum sicheren Port 10250.

Beispielmigration

Angenommen, ein Pod fragt Messwerte vom unsicheren schreibgeschützten Kubelet-Port ab.

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 tut Folgendes:

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

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

  1. Erstellen Sie eine ClusterRole mit Zugriff auf Knotenmesswerte:

    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 Befehl curl, damit er den Endpunkt des sicheren Ports mit den entsprechenden Autorisierungsheadern verwendet:

    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, damit sie Port 10250 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 zu TCP-Port 10250 in Ihren Knoten-IP-Adressbereichen aus internen Pod-IP-Adressbereichen zulassen.
  • Eingehenden Traffic zu TCP-Port 10250 in Ihren Knoten-IP-Adressbereichen aus dem öffentlichen Internet ablehnen.

Sie können die folgenden Standard-Firewallregeln von GKE 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 in Autopilot-Clustern deaktivieren

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

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

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 --no-autoprovisioning-enable-insecure-kubelet-readonly-port Flag auch verwenden, wenn Sie einen neuen Cluster mit dem gcloud container clusters create-auto Befehl erstellen.

Unsicheren schreibgeschützten Port in Standardclustern deaktivieren

Sie können den unsicheren schreibgeschützten Kubelet-Port für gesamte 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

Verwenden Sie das Flag --no-enable-insecure-kubelet-readonly-port, um den unsicheren schreibgeschützten Kubelet-Port in einem vorhandenen Standardcluster zu deaktivieren, wie im folgenden Befehl. Alle neuen 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 --no-autoprovisioning-enable-insecure-kubelet-readonly-port Flag auch verwenden, wenn Sie einen neuen Cluster mit dem gcloud container clusters create Befehl erstellen.

Unsicheren schreibgeschützten Port in Standardknotenpools deaktivieren

Wir empfehlen, die Einstellung für den schreibgeschützten Port in allen Fällen 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.

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

Beschreiben Sie die GKE-Ressource, um zu prüfen, ob der unsichere schreibgeschützte Kubelet-Port deaktiviert ist.

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 ein Feld nodeConfig, in dem ein Wert für den Status des schreibgeschützten Kubelet-Ports festgelegt ist. 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 veralteten 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 kubelet-Port 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 Standardknotenpools 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

Nutzung des unsicheren Ports mit einer Organisationsrichtlinie verhindern

Mit dem Organisationsrichtliniendienst können Sie erzwingen, dass in Clustern in Ihrer Organisation, Ihrem Ordner oder Ihrem Projekt der unsichere schreibgeschützte kubelet-Port deaktiviert werden muss. Um diese Anforderung zu erzwingen, erstellen Sie eine benutzerdefinierte Einschränkung, und verweisen dann in einer Organisationsrichtlinie auf diese Einschränkung. Informationen zum Ablehnen von Erstellungs- oder Aktualisierungsvorgängen, wenn der unsichere schreibgeschützte kubelet-Port aktiviert ist, finden Sie in diesen Beispielen:

  • Die folgende benutzerdefinierte Einschränkung lehnt Erstellungs- oder Aktualisierungsvorgänge für Cluster ab, wenn der unsichere schreibgeschützte kubelet-Port 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 Erstellungs- oder Aktualisierungsvorgänge für Knotenpools ab, wenn der unsichere schreibgeschützte kubelet-Port 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.