Auf dieser Seite erfahren Sie, wie Sie Probleme mit problematischen oder unsicheren Webhooks in Google Distributed Cloud beheben.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Arten problematischer Webhooks
Zulassungs-Webhooks oder Webhooks sind in Kubernetes eine Art von Admission-Controller, die in Kubernetes-Clustern verwendet werden können, um Anfragen an die Steuerungsebene zu validieren oder zu mutieren, bevor eine Anfrage beibehalten wird. Es ist üblich, dass Anwendungen von Drittanbietern Webhooks verwenden, die mit systemkritischen Ressourcen und Namespaces ausgeführt werden. Falsch konfigurierte Webhooks können sich auf die Leistung und Zuverlässigkeit der Steuerungsebene auswirken. Beispiel: Ein falsch konfigurierter Webhook, der von einer
Drittanbieteranwendung erstellt wurde,
könnte Google Distributed Cloud daran hindern,
Ressourcen im verwalteten Namespace kube-system
zu erstellen und zu ändern, was
die Funktionalität des Clusters beeinträchtigen kann.
Zu problematischen Webhooks gehören:
- Webhooks, die funktionieren, die aber keine Endpunkte haben. Folgen Sie der Anleitung unter Webhooks prüfen, die keine verfügbaren Endpunkte haben.
Webhooks, die als unsicher angesehen werden, da sie systemkritische Ressourcen und Namespaces bearbeiten.
Die folgenden Webhooks gelten als unsicher:
- Webhooks, die Pods und Leases im Namespace
kube-system
abfangen. - Webhooks, die Leases im Namespace
kube-node-lease
abfangen. - Webhooks, die die Ressourcen
Nodes
,TokenReviews
,SubjectAccessReviews
, undCertificateSigningRequests
. abfangen.
Folgen Sie der Anleitung zum Webhooks prüfen, die als unsicher gelten.
- Webhooks, die Pods und Leases im Namespace
Webhooks ohne verfügbare Endpunkte
Wenn ein Webhook keine verfügbaren Endpunkte hat, hat der Dienst, der den Webhook-Endpunkt unterstützt, einen oder mehrere Pods, die nicht ausgeführt werden. Um die Webhook-Endpunkte verfügbar zu machen, folgen Sie der Anleitung, um die Pods des Dienstes zu finden und Fehler zu beheben, der diesen Webhook-Endpunkt unterstützt:
Suchen Sie die Bereitstellungs-Pods für den Dienst, der dem Webhook zugeordnet ist. Führen Sie den folgenden Befehl aus, um den Dienst zu beschreiben:
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
Ersetzen Sie Folgendes:
- SERVICE_NAME durch den Namen des Dienstes.
- SERVICE_NAMESPACE durch den Namen des Namespace.
Wenn Sie den Dienstnamen im Webhook nicht finden können, könnte der nicht verfügbare Endpunkt durch eine Abweichung zwischen dem in der Konfiguration aufgelisteten Namen und dem tatsächlichen Namen des Dienstes entstanden sein. Aktualisieren Sie den Dienstnamen in der Webhook-Konfiguration mit dem richtigen Dienstobjekt, um die Endpunktverfügbarkeit zu korrigieren.
Prüfen Sie die Bereitstellungs-Pods für diesen Dienst. Ermitteln Sie, welche Pods nicht ausgeführt werden. Listen Sie dazu das Deployment auf:
kubectl get deployment -n SERVICE_NAMESPACE
Oder führen Sie den folgenden Befehl aus, um die Pods aufzulisten:
kubectl get pods -n SERVICE_NAMESPACE -o wide
Prüfen Sie für alle nicht ausgeführten Pods in den Pod-Logs, warum der Pod nicht ausgeführt wird.
Webhooks, die als unsicher gelten
Wenn ein Webhook Ressourcen in vom System verwalteten Namespaces abfängt, empfehlen wir, die Webhooks zu aktualisieren, damit diese Ressourcen nicht abgefangen werden.
Prüfen Sie die Webhook-Konfiguration. Führen Sie den folgenden
kubectl
-Befehl aus, um Rufen Sie die Webhook-Konfiguration ab:kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
Ersetzen Sie CONFIGURATION_NAME durch den Namen Webhook-Konfiguration.
Wenn bei diesem Befehl nichts zurückgegeben wird, führen Sie den Befehl noch einmal aus und ersetzen Sie dabei
validatingwebhookconfigurations
durchmutatingwebhookconfigurations
.Im Abschnitt
webhooks
der Ausgabe werden ein oder mehrere Webhooks aufgeführt.Bearbeiten Sie die Konfiguration je nachdem, warum der Webhook als unsicher gilt:
Namespaces „kube-system” und „kube-node-lease” ausschließen
Ein Webhook gilt als unsicher, wenn
scope
den Wert*
hat oder wenn der BereichNamespaced
ist und eine der folgenden Bedingungen erfüllt ist:Die
operator
-Bedingung istNotIn
undvalues
lässtkube-system
undkube-node-lease
wie im folgenden Beispiel aus:webhooks: - admissionReviewVersions: ... namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - blue-system # add 'kube-system' and 'kube-node-lease' if `NotIn` objectSelector: {} rules: - apiGroups: ... scope: '*' # 'Namespaced' sideEffects: None timeoutSeconds: 3
Achten Sie darauf, dass
scope
aufNamespaced
und nicht auf*
gesetzt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Achten Sie darauf, dass wennoperator
NotIn
ist,kube-system
undkube-node-lease
invalues
enthalten sein müssen.Die
operator
-Bedingung istIn
undvalues
enthältkube-system
undkube-node-lease
wie im folgenden Beispiel:namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - blue-system - kube-system # remove as operator is `In` - kube-node-lease # remove as operator is `In`
Achten Sie darauf, dass
scope
aufNamespaced
und nicht auf*
gesetzt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Achten Sie darauf, dasskube-system
undkube-node-lease
nicht invalues
enthalten ist, wennoperator
In
ist.
Übereinstimmende Ressourcen ausschließen
Ein Webhook gilt auch als unsicher, wenn
nodes
,tokenreviews
,subjectaccessreviews
odercertificatesigningrequests
wie im folgenden Beispiel unter Ressourcen aufgeführt sind:- admissionReviewVersions: ... resources: - 'pods' # keep, remove everything else - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3
Entfernen Sie
nodes
,tokenreviews
,subjectaccessreviews
undcertificatesigningrequests
aus dem Ressourcenabschnitt.