Problembehandlung bei der App Mesh-Sicherheit

Wichtig

Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 werden Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen können. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag Migration von AWS App Mesh zu Amazon ECS Service Connect.

In diesem Thema werden häufig auftretende Probleme mit der App Mesh-Sicherheit beschrieben.

Es kann keine Verbindung zu einem virtuellen Backend-Dienst mit einer TLS-Client-Richtlinie hergestellt werden

Symptome

Beim Hinzufügen einer TLS-Client-Richtlinie zu einem virtuellen Service-Backend in einem virtuellen Knoten schlägt die Konnektivität zu diesem Backend fehl. Beim Versuch, Datenverkehr an den Back-End-Dienst zu senden, schlagen die Anfragen mit einem HTTP 503 Antwortcode und der Fehlermeldung fehl:. upstream connect error or disconnect/reset before headers. reset reason: connection failure

Auflösung

Um die Ursache des Problems zu ermitteln, empfehlen wir, die Envoy-Proxy-Prozessprotokolle zu verwenden, um Ihnen bei der Diagnose des Problems zu helfen. Weitere Informationen finden Sie unter Aktivieren Sie die Envoy-Debug-Protokollierung in Vorproduktionsumgebungen. Ermitteln Sie anhand der folgenden Liste die Ursache des Verbindungsfehlers:

• Stellen Sie sicher, dass die Verbindung zum Backend erfolgreich ist, indem Sie die unter genannten Fehler ausschließen. Es kann keine Verbindung zu einem virtuellen Service-Backend hergestellt werden

• Suchen Sie in den Envoy-Prozessprotokollen nach den folgenden Fehlern (die auf Debug-Ebene protokolliert wurden).

  TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

  Dieser Fehler wird durch einen oder mehrere der folgenden Gründe verursacht:

  • Das Zertifikat wurde nicht von einer der im TLS Client Policy Trust Bundle definierten Zertifizierungsstellen signiert.

  • Das Zertifikat ist nicht mehr gültig (abgelaufen).

  • Der alternative Betreffname (SAN) stimmt nicht mit dem angeforderten DNS-Hostnamen überein.

  • Stellen Sie sicher, dass das vom Back-End-Dienst angebotene Zertifikat gültig ist, dass es von einer der Zertifizierungsstellen in Ihrem Vertrauenspaket für TLS-Client-Richtlinien signiert wurde und dass es die unter definierten Kriterien erfüllt. Transport Layer Security (TLS)

  • Wenn der Fehler, den Sie erhalten, dem unten angegebenen entspricht, bedeutet dies, dass die Anfrage den Envoy-Proxy umgeht und die Anwendung direkt erreicht. Beim Senden von Traffic ändern sich die Statistiken auf Envoy nicht, was darauf hindeutet, dass Envoy nicht auf dem Weg ist, den Traffic zu entschlüsseln. Stellen Sie in der Proxykonfiguration des virtuellen Knotens sicher, dass der den richtigen Wert AppPorts enthält, den die Anwendung abhört.

    upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER

Wenn Ihr Problem immer noch nicht gelöst ist, sollten Sie erwägen, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support. Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die Richtlinien zur Meldung von AWS Sicherheitslücken.

Es kann keine Verbindung zu einem virtuellen Backend-Dienst hergestellt werden, wenn die Anwendung TLS stammt

Symptome

Wenn eine TLS-Sitzung von einer Anwendung und nicht vom Envoy-Proxy aus gestartet wird, schlägt die Konnektivität zu einem virtuellen Backend-Dienst fehl.

Auflösung

Dies ist ein bekanntes Problem. Weitere Informationen finden Sie im Abschnitt Funktionsanfrage: TLS-Aushandlung zwischen der Downstream-Anwendung und dem Upstream-Proxy GitHub . In App Mesh wird die TLS-Herkunft derzeit vom Envoy-Proxy unterstützt, jedoch nicht von der Anwendung aus. Um die TLS-Originationsunterstützung im Envoy zu verwenden, deaktivieren Sie die TLS-Originierung in der Anwendung. Dadurch kann der Envoy die Header für ausgehende Anfragen lesen und die Anfrage über eine TLS-Sitzung an das entsprechende Ziel weiterleiten. Weitere Informationen finden Sie unter Transport Layer Security (TLS).

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu eröffnen, oder wenden Sie sich an den Support. AWS Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die Richtlinien zur Meldung von AWS Sicherheitslücken.

Es kann nicht bestätigt werden, dass die Konnektivität zwischen Envoy-Proxys TLS verwendet

Symptome

Ihre Anwendung hat die TLS-Terminierung auf dem virtuellen Knoten oder dem virtuellen Gateway-Listener oder die TLS-Originierung in der Backend-TLS-Client-Richtlinie aktiviert, aber Sie können nicht behaupten, dass die Konnektivität zwischen Envoy-Proxys während einer Sitzung hergestellt wird. TLS-negotiated

Auflösung

Die in dieser Resolution definierten Schritte verwenden die Envoy-Administrationsoberfläche und die Envoy-Statistiken. Hilfe bei der Konfiguration finden Sie unter Aktivieren Sie die Envoy-Proxy-Verwaltungsschnittstelle und. Aktivieren Sie die Envoy DogStats D-Integration für das Offload von Metriken In den folgenden Statistikbeispielen wird der Einfachheit halber die Administrationsoberfläche verwendet.

• Für den Envoy-Proxy, der eine TLS-Terminierung durchführt:

  • Stellen Sie sicher, dass das TLS-Zertifikat in der Envoy-Konfiguration mit dem folgenden Befehl gebootet wurde.

    curl http://my-app.default.svc.cluster.local:9901/certs

    In der zurückgegebenen Ausgabe sollte unter mindestens ein Eintrag certificates[].cert_chain für das Zertifikat angezeigt werden, das bei der TLS-Terminierung verwendet wird.

  • Stellen Sie sicher, dass die Anzahl der erfolgreichen eingehenden Verbindungen zum Listener des Proxys genau der Anzahl der SSL-Handshakes plus der Anzahl der wiederverwendeten SSL-Sitzungen entspricht, wie aus den folgenden Beispielbefehlen und der folgenden Ausgabe hervorgeht.

    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
    listener.0.0.0.0_15000.downstream_cx_total: 11
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
    listener.0.0.0.0_15000.ssl.connection_error: 1
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
    listener.0.0.0.0_15000.ssl.handshake: 9
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
    listener.0.0.0.0_15000.ssl.session_reused: 1
    # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)

• Für den Envoy-Proxy, der die TLS-Originierung durchführt:

  • Stellen Sie sicher, dass der TLS Trust Store in der Envoy-Konfiguration mit dem folgenden Befehl gebootet wurde.

    curl http://my-app.default.svc.cluster.local:9901/certs

    Unter sollte mindestens ein Eintrag certificates[].ca_certs für die Zertifikate angezeigt werden, die bei der Validierung des Backend-Zertifikats bei der TLS-Erstellung verwendet wurden.

  • Stellen Sie sicher, dass die Anzahl der erfolgreichen ausgehenden Verbindungen zum Backend-Cluster genau der Anzahl der SSL-Handshakes plus der Anzahl der wiederverwendeten SSL-Sitzungen entspricht, wie die folgenden Beispielbefehle und -ausgaben zeigen.

    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
    # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den Support. AWS Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die Richtlinien zur Meldung von AWS Sicherheitslücken.

Fehlerbehebung bei TLS mit Elastic Load Balancing

Symptome

Beim Versuch, einen Application Load Balancer oder Network Load Balancer so zu konfigurieren, dass der Datenverkehr zu einem virtuellen Knoten verschlüsselt wird, können Konnektivitäts- und Load Balancer-Integritätsprüfungen fehlschlagen.

Auflösung

Um die Ursache des Problems zu ermitteln, müssen Sie Folgendes überprüfen:

• Für den Envoy-Proxy, der die TLS-Terminierung durchführt, müssen Sie jegliche Fehlkonfiguration ausschließen. Folgen Sie den Schritten oben in der. Es kann keine Verbindung zu einem virtuellen Backend-Dienst mit einer TLS-Client-Richtlinie hergestellt werden

• Für den Load Balancer müssen Sie sich die Konfiguration des ansehen TargetGroup:

  • Stellen Sie sicher, dass der TargetGroup Port mit dem definierten Listener-Port des virtuellen Knotens übereinstimmt.

  • Stellen Sie bei Application Load Balancern, die TLS-Verbindungen über HTTP zu Ihrem Dienst herstellen, sicher, dass das TargetGroup Protokoll auf eingestellt ist. HTTPS Wenn Systemdiagnosen verwendet werden, stellen Sie sicher, dass diese Option auf HTTPS gesetzt HealthCheckProtocol ist.

  • Stellen Sie bei Network Load Balancern, die TLS-Verbindungen über TCP zu Ihrem Dienst herstellen, sicher, dass das TargetGroup Protokoll auf TLS eingestellt ist. Wenn Systemdiagnosen verwendet werden, stellen Sie sicher, dass diese Option auf TCP gesetzt HealthCheckProtocol ist.

    Anmerkung

    Alle Updates, bei TargetGroup denen der TargetGroup Name geändert werden muss.

Wenn dies ordnungsgemäß konfiguriert ist, sollte Ihr Load Balancer mithilfe des für den Envoy-Proxy bereitgestellten Zertifikats eine sichere Verbindung zu Ihrem Dienst herstellen.

Wenn Ihr Problem immer noch nicht gelöst ist, sollten Sie erwägen, ein GitHub Problem zu eröffnen, oder wenden AWS Sie sich an den Support. Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die Richtlinien zur Meldung von AWS Sicherheitslücken.