Anthos Service Mesh 1.10 ist abgelaufen und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

1.20 (neueste Version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Sicherheitsprobleme in Anthos Service Mesh beheben

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

In Anthos 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 beschrieben, wie TLS-bezogene Probleme in Anthos Service Mesh behoben werden können.

In den Beispielen dieses Abschnitts wird die Variable ${CTX} verwendet. Dies ist der Kontextname in der Standard-Kubernetes-Konfigurationsdatei, mit der 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:
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.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

Die Autorisierungsrichtlinie lehnt eine Anfrage ab, wenn sie gemäß der Richtlinie nicht zulässig ist. Bei HTTP-Protokollen (einschließlich gRPC) wird die Anfrage mit dem Statuscode 403 abgewiesen. Bei Nicht-HTTP-Protokollen wird die Verbindung sofort beendet. Weitere Informationen zu Autorisierungsrichtlinien finden Sie unter Istio-Autorisierung.

Das Zugriffslog für die Beobachtbarkeit von Google Cloud enthält erforderliche Informationen, wenn die Anfrage durch eine Autorisierungsrichtlinie abgelehnt wird. Dies kann in einigen Situationen hilfreich sein. Das Log zeigt beispielsweise an, wie viele Anfragen von der Autorisierungsrichtlinie abgelehnt wurden, was Ihnen dabei helfen kann, festzustellen, welche Richtlinienregel die Ablehnung im Vergleich zu Ablehnungen von der Back-End-Anwendung verursacht hat.

Das Google Cloud-Zugriffslog für Beobachtbarkeit enthält die folgenden Labels für die Ablehnung der Autorisierung.

response_details Dafür wird AuthzDenied festgelegt, wenn die Ablehnung von der Autorisierungsrichtlinie verursacht wurden.
policy_name Beinhaltet den Namespace und den Namen der DENY-Autorisierungsrichtlinie, die zur Ablehnung führt. Der Wert hat das Format <Namespace>.<Name>. Beispiel: foo.deny-method-get steht für eine deny-method-get-Autorisierungsrichtlinie im Namespace foo.
policy_rule Beinhaltet den Index der Regel in der Autorisierungsrichtlinie, die die Ablehnung verursacht. Beispielsweise steht 0 für die erste Regel in der Richtlinie.

Weitere Informationen zum Abrufen des Zugriffslogs finden Sie unter Auf Logs in Cloud Logging zugreifen.

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 noch einmal istioctl install aus (bzw. verwenden Sie die Installationsmethode, mit der Sie Anthos Service Mesh installiert haben), um diese 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