Anthos Service Mesh 1.6 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 (aktuell)
1.19
1.18
1.17
1.16
1.15
1.13
1.12
1.12
1.12
1.12

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.

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

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

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Sie können den String mit regulärem Ausdruck /serverca.*Authentication failed:.*JWT/ verwenden, um diese Fehler in den Logs zu finden.

Dieser Fehler kann auftreten, wenn der JWT-Aussteller falsch konfiguriert ist, ein Client ein abgelaufenes Token nutzt oder ein anderes Sicherheitsproblem verhindert, dass eine Verbindung bei „Istiod“ richtig authentifiziert wird.