App Mesh 安全故障排除 - AWS App Mesh

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

App Mesh 安全故障排除

本主题详细介绍了您在使用 App Mesh 安全时可能遇到的常见问题。

无法通过 TLS 客户端策略连接到后端虚拟服务

症状

向虚拟节点中的虚拟服务后端添加 TLS 客户端策略时,与该后端的连接会失败。尝试向后端服务发送流量时,请求失败并显示 HTTP 503 响应代码和错误消息:upstream connect error or disconnect/reset before headers. reset reason: connection failure

解决方案

为确定问题的根本原因,我们建议使用 Envoy 代理进程日志来帮助您诊断问题。有关更多信息,请参阅 在预生产环境中启用 Envoy 调试日志记录。使用以下列表来确定连接失败的原因:

  • 排除 无法连接到虚拟服务后端 中提到的错误,确保与后端连接成功。

  • 在 Envoy 进程日志中,查找以下错误(记录在调试级别)。

    TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

    该错误可能是由以下一个或多个问题导致的:

    • 该证书未由 TLS 客户端策略信任包中定义的证书颁发机构之一签名。

    • 证书不再有效(已过期)。

    • 主题备用名称 (SAN) 与请求的 DNS 主机名不匹配。

    • 确保后端服务提供的证书有效,由您的 TLS 客户端策略信任包中的一个证书颁发机构签名,并且符合中定义的标准 传输层安全 (TLS)

    • 如果您收到的错误与下面的错误类似,则表示该请求正在绕过 Envoy 代理并直接到达应用程序。发送流量时,Envoy 上的统计数据不会发生变化,这表明 Envoy 不在解密流量的路上。在虚拟节点的代理配置中,确保 AppPorts 包含应用程序正在侦听的正确值。

      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

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

应用程序源自 TLS 时无法连接到后端虚拟服务

症状

从应用程序而不是从 Envoy 代理发起 TLS 会话时,与后端虚拟服务的连接会失败。

解决方案

这是一个已知问题。有关更多信息,请参阅功能请求:下游应用程序和上游代理之间的 TLS 协商 GitHub 问题。在 App Mesh 中,目前支持 Envoy 代理发起 TLS,但不支持应用程序发起 TLS。要在 Envoy 上使用 TLS 发起支持,请在应用程序中禁用 TLS 起源。这样,Envoy 可读取出站请求标头,并通过 TLS 会话将请求转发到相应的目的地。有关更多信息,请参阅 传输层安全 (TLS)

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

无法断言 Envoy 代理之间的连接正在使用 TLS

症状

您的应用程序已在虚拟节点或虚拟网关侦听器上启用 TLS 终止,或者在后端 TLS 客户端策略上启用 TLS 启动,但是您无法断言 Envoy 代理之间的连接是通过 TLS 协商的会话进行的。

解决方案

本解析中定义的步骤使用了 Envoy 管理界面和 Envoy 统计信息。有关配置这些内容的帮助,请参阅 启用 Envoy 代理管理界面启用 Envoy DogStats D 集成以进行指标卸载。为简单起见,以下统计示例使用了管理界面。

  • 对于执行 TLS 终止的 Envoy 代理:

    • 使用以下命令确保已在 Envoy 配置中引导 TLS 证书。

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

      在返回的输出中,您应看到至少一个条目 certificates[].cert_chain 指定 TLS 端点。

    • 确保代理侦听器的成功入站连接数与 SSL 握手次数加上重复使用的 SSL 会话数完全相同,如以下示例命令和输出所示。

      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)
  • 对于执行 TLS 发起的 Envoy 代理:

    • 使用以下命令确保已在 Envoy 配置中引导 TLS 信任库。

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

      您应该在 certificates[].ca_certs 下方看到至少一个条目,显示在发起 TLS 期间用于验证后端证书的证书。

    • 确保成功连接到后端集群的出站连接数与 SSL 握手次数加上重复使用的 SSL 会话数完全相同,如以下示例命令和输出所示。

      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)

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

使用 Elastic Load Balancing 排除

症状

尝试配置应用程序负载均衡器或网络负载均衡器以加密虚拟节点的流量时,连接和负载均衡器运行状况检查可能会失败。

解决方案

为确定问题的根本原因,您需要检查以下内容:

  • 对于执行 TLS 终止的 Envoy 代理,您需要排除任何配置错误。然后,遵循 无法通过 TLS 客户端策略连接到后端虚拟服务 中的步骤。

  • 对于负载均衡器,您需要查看负载均衡器的配置 TargetGroup:

    • 确保该 TargetGroup 端口与虚拟节点定义的侦听器端口相匹配。

    • 对于通过 HTTP 向您的服务发起 TLS 连接的应用程序负载均衡器,请确保将 TargetGroup 协议设置为 HTTPS。如果正在使用运行状况检查,请确保将 HealthCheckProtocol 设置为 HTTPS

    • 对于通过 TCP 向您的服务发起 TLS 连接的网络负载均衡器,请确保将 TargetGroup 协议设置为 TLS。如果正在使用运行状况检查,请确保将 HealthCheckProtocol 设置为 TCP

      注意

      任何更新 TargetGroup 都需要更改 TargetGroup 名称。

正确配置后,您的负载均衡器应使用提供给 Envoy 代理的证书为您的服务提供安全连接。

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南