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 クライアントのポリシーの信頼バンドルで定義されている認証局の 1 つによって署名されていませんでした。

    • 証明書は無効です(期限切れ)。

    • サブジェクト別名 (SAN) がリクエストされた DNS ホスト名と一致しません。

    • バックエンドサービスによって提供される証明書が有効であること、TLS クライアントポリシーの信頼バンドル内のいずれかの認証局によって署名されていること、および Transport Layer Security (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 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「AWS 脆弱性レポートガイドライン」を参照してください。

アプリケーションが TLS を発信しているときにバックエンド仮想サービスに接続できない

症状

Envoy プロキシからではなく、アプリケーションから TLS セッションを開始すると、バックエンド仮想サービスへの接続が失敗します。

解決方法

これは既知の問題です。詳細については、「機能リクエスト: ダウンストリームアプリケーションとアップストリームプロキシの問題間の TLS ネゴシ GitHub エーション」を参照してください。App Mesh では、TLS 発信は、現在 Envoy プロキシからサポートされていますが、アプリケーションからはサポートされていません。Envoy で TLS 発信 Support を使用するには、アプリケーションでの TLS 発信を無効にします。これにより、Envoy はアウトバウンドリクエストヘッダーを読み取り、TLS のセッションを介してリクエストを適切な宛先に転送できます。詳細については、「Transport Layer Security (TLS)」を参照してください。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「AWS 脆弱性レポートガイドライン」を参照してください。

Envoy プロキシ間の接続が TLS を使用していることをアサートできません

症状

アプリケーションが仮想ノードまたは仮想ゲートウェイのリスナーで TLS 終了、またはバックエンド TLS クライアントのポリシーで TLS 発信を有効にしていますが、TLS ネゴシエートされたセッションで Envoy プロキシ間の接続が発生していることをアサートできません。

解決方法

この解決法で定義されているステップは、Envoy 管理インターフェイスと Envoy 統計を使用します。これらの設定については、「Envoy プロキシ管理インターフェイスを有効にする」と「メトリクスオフロードの Envoy DogStatsD 統合を有効にする」を参照してください。次の統計例では、簡単にするために管理インターフェイスを使用しています。

  • TLS 終了を実行する Envoy プロキシの場合:

    • 次のコマンドを使用して、TLS 証明書が Envoy 設定でブートストラップされていることを確認してください。

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

      返される出力には、TLSターミネーションで使用される証明書の certificates[].cert_chain の下に少なくとも1つのエントリが表示されます。

    • 次のコマンドと出力の例に示すように、プロキシのリスナーへの正常なインバウンド接続の数が、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 プロキシの場合:

    • 次のコマンドを使用して、TLS 信頼ストアが Envoy 設定でブートストラップされていることを確認してください。

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

      TLS の発信中にバックエンドの証明書を検証する際に使用される証明書について、certificates[].ca_certs の下に少なくとも1つのエントリが表示されます。

    • 次のコマンドと出力の例に示すように、バックエンドのクラスターへの正常なアウトバウンド接続の数が、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 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「AWS 脆弱性レポートガイドライン」を参照してください。

Elastic Load Balancing を使用した TLS のトラブルシューティング

症状

仮想ノードへのトラフィックを暗号化するように Application Load Balancer または Network Load Balancer を設定しようとすると、接続とロードバランサーのヘルスチェックが失敗することがあります。

解決方法

問題の根本原因を特定するには、次の点をチェックする必要があります。

  • TLS 終了を実行する Envoy プロキシでは、設定ミスを除外する必要があります。上記の「TLS クライアントのポリシーを使用してバックエンド仮想サービスに接続できない」の手順に従います。

  • ロードバランサーの場合は、TargetGroup: 設定を確認する必要がある

    • TargetGroup ポートが仮想ノードの定義済みリスナーポートと一致していることを確認してください。

    • HTTP を介してサービスへの TLS 接続を発信しているアプリケーションロードバランサーの場合、TargetGroup プロトコルが HTTPS に設定されていることを確認してください。ヘルスチェックを利用している場合は、HealthCheckProtocolHTTPS に設定されていることを確認してください。

    • TCP を介してサービスへの TLS 接続を発信しているネットワークロードバランサーの場合、TargetGroup プロトコルが TLS に設定されていることを確認してください。ヘルスチェックを利用している場合は、HealthCheckProtocolTCP に設定されていることを確認してください。

      注記

      TargetGroup へのすべての更新では、TargetGroup 名を変更する必要があります。

これが適切に設定されている場合、ロードバランサーは、Envoy プロキシに提供された証明書を使用して、サービスへの安全な接続を提供する必要があります。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「AWS 脆弱性レポートガイドライン」を参照してください。