Sie sehen sich die Dokumentation für die ältere Service Mesh-Version 1.20 an.

Verfügbare Versionen

Cloud Service Mesh
1.22-Archiv
1.21-Archiv
1.20-Archiv
1.19-Archiv
1.18-Archiv

Diese Seite wurde von der Cloud Translation API übersetzt.

Sicherheitsprobleme in Cloud Service Mesh beheben

In diesem Abschnitt werden häufig auftretende Cloud Service Mesh-Probleme und deren Behebung erläutert. Weitere Informationen finden Sie unter Support.

In Cloud Service Mesh stellt Mesh CA oder Istiod Zertifikate für Arbeitslasten in allen Clustern im Mesh-Netzwerk aus. Authentifizierung (z. B. mTLS) und Autorisierungsrichtlinien (z. B. Zulassen/Ablehnen) werden per Push an jeden Cluster übertragen. Diese Richtlinien bestimmen, welche Arbeitslasten kommunizieren können und wie.

TLS-Probleme

In den folgenden Abschnitten wird erläutert, wie TLS-bezogene Probleme in Cloud Service Mesh behoben werden.

In den Beispielen in diesem Abschnitt wird die Variable ${CTX} verwendet. Sie dient als Kontext im Feld Standard-Kubernetes-Konfigurationsdatei mit denen Sie auf den Cluster zugreifen. Legen Sie die Variable ${CTX} wie im folgenden Beispiel fest:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

TLS-Erzwingung prüfen

Prüfen Sie, ob für einen Dienst keine Nur-Text-Anfragen zulässig sind, wenn der Dienst TLS-Verbindungen erfordert:

kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
    SOURCE_CONTAINER -- curl -v DESTINATION_URL

Wenn der Dienst TLS-Verbindungen erfordert, sollte die obige Nur-Text-Anfrage fehlschlagen. Dadurch sieht die Ausgabe in etwa so aus:

curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56

mTLS-Zertifikate prüfen

Wenn mTLS aktiviert ist, prüfen Sie das mTLS-Zertifikat der Arbeitslast anhand des Headers X-Forwarded-Client-Cert. Gehen Sie dazu so vor:

Stellen Sie den Beispieldienst httpbin bereit, der die empfangenen Header anzeigen kann.

Verwenden Sie curl, um sich den Header X-Forwarded-Client-Cert anzusehen:

kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \
grep X-Forwarded-Client-Cert

Der Header X-Forwarded-Client-Cert zeigt die mTLS-Zertifikatsinformationen an, z. B.:

X-Forwarded-Client-Cert": "By=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/httpbin;Hash=0781d68adfdab85b08b6758ed502f352464e81166f065cc6acde9433337b4494;Subject=\"OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US\";URI=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/sleep

Alternativ können Sie für die Sidecar-Datei openssl verwenden, um sich die gesamte Zertifikatskette anzusehen:
```
kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000
```
In der Ausgabe wird die Zertifikatskette angezeigt. Wenn Sie Mesh CA verwenden, prüfen Sie, ob der Root-Zertifikat-CN istio_v1_cloud_workload_root-signer-... enthält. Wenn Sie Istiod als Zertifizierungsstelle verwenden, prüfen Sie, ob für das Root-Zertifikat O = <var>YOUR_TRUST_DOMAIN</var> festgelegt ist.

TLS-`bad certificate`-Fehler in den Istiod-Logs

Wenn in den Logs TLS-Handshakefehler vom Typ bad certificate angezeigt werden, kann dies darauf hindeuten, dass Istiod keine TLS-Verbindung zu einem Dienst herstellen kann.

Sie können den String mit regulärem Ausdruck TLS handshake error.*bad certificate verwenden, um diese Fehler in den Logs zu finden.

Diese Fehler dienen normalerweise nur Informationszwecken und dies sind vorübergehende Fehler. Wenn sie jedoch weiterhin auftreten, können Sie auf ein Problem mit Ihrem System hinweisen.

Prüfen Sie, ob Ihre istio-sidecar-injector MutatingWebhookConfiguration ein CA-Bundle enthält.

Der Sidecar-Injektor-Webhook, der für die automatische Sidecar-Einfügung verwendet wird, erfordert ein CA-Bundle, um sichere Verbindungen mit dem API-Server und Istiod herzustellen. Dieses CA-Bundle wird von istiod in die Konfiguration eingefügt, kann aber manchmal überschrieben werden, beispielsweise wenn Sie die Webhook-Konfiguration neu anwenden.
Prüfen Sie, ob das CA-Bundle vorhanden ist:

Hinweis: Wenn Sie mehrere Steuerungsebenen installiert haben, geben Sie eine bestimmte Überarbeitung an.
```
kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
```
Wenn die Ausgabe nicht leer ist, ist das CA-Bundle konfiguriert. Wenn das CA-Bundle fehlt, starten Sie istiod neu, um den Webhook noch einmal zu scannen und das CA-Bundle neu zu installieren.

Logging der Verweigerung von Autorisierungsrichtlinien

Informationen zum Logging der Verweigerung von Autorisierungsrichtlinien finden Sie unter Logging der Verweigerung.

Autorisierungsrichtlinien werden nicht erzwungen

Wenn Symptome auftauchen, die dafür sprechen, dass Autorisierungsrichtlinien nicht erzwungen werden, verifizieren Sie diese mit dem folgenden Befehl:

kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
    -c SOURCE_CONTAINER -- curl DESTINATION_URL

In der Ausgabe zeigen access denied-Meldungen an, dass Autorisierungsrichtlinien ordnungsgemäß erzwungen werden. Beispiel:

RBAC: access denied

Wenn Sie feststellen, dass Autorisierungsrichtlinien nicht erzwungen werden, verweigern Sie den Zugriff auf den Namespace. Im folgenden Beispiel wird der Zugriff auf den Namespace authz-ns verweigert:

kubectl apply --context=${CTX} -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-authz-ns
  namespace: authz-ns
spec:
  {}
EOF

Fehler „customresourcedefinitions.apiextensions.k8s.io is forbidden“ in Istiod-Logs

Möglicherweise wird ein ähnlicher Fehler wie dieser angezeigt:

error failed to list CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:istio-system:istiod-service-account" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

Sie können den String mit regulärem Ausdruck /error.*cannot list resource/ verwenden, um diese Fehler in den Logs zu finden.

Dieser Fehler kann auftreten, wenn Ihre Istio-Bereitstellung nicht die richtige IAM-Bindung enthält oder keine ausreichenden RBAC-Berechtigungen zum Lesen einer benutzerdefinierten Ressource hat.

Prüfen Sie, ob in Ihrem Konto eine IAM-Bindung fehlt. Schauen Sie zuerst nach, ob Sie die Anmeldedaten und Berechtigungen korrekt festgelegt haben. Prüfen Sie dann mit dem folgenden Befehl, ob die IAM-Bindung vorhanden ist. In diesem Beispiel ist PROJECT_ID die Ausgabe von gcloud config get-value project und PROJECT_NUMBER die Ausgabe von gcloud projects list --filter="project_id=${PROJECT_ID}" --format="value(project_number)":
```
gcloud projects add-iam-policy-binding ${PROJECT_ID} --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com" --role "roles/meshdataplane.serviceAgent"
```
Prüfen Sie, ob die RBAC-Regeln korrekt installiert sind.
Wenn die RBAC-Regeln fehlen, führen Sie asmcli install noch einmal aus, um sie neu zu erstellen.
Wenn die RBAC-Regeln vorhanden sind und die Fehler bestehen bleiben, prüfen Sie, ob die ClusterRoleBindings und RoleBindings die RBAC-Regeln an das richtige Kubernetes-Dienstkonto anhängen. Prüfen Sie außerdem, ob die Istiod-Bereitstellung das angegebene Dienstkonto verwendet.

`serverca`-Prozessfehler in Istiod-Logs