管理者は、Kubernetes ネットワーク内で HTTPS を適用する必要がありますか、それとも外部トラフィック (イングレス経由) のみに適用する必要がありますか?

管理者は、Kubernetes ネットワーク内で HTTPS を適用する必要がありますか、それとも外部トラフィック (イングレス経由) のみに適用する必要がありますか?

マイクロサービス シナリオでは、各 Web API コンテナーは HTTPS 経由で自身を提供する必要がありますか、それとも内部的に HTTP 経由で動作し、すべてのイングレスを証明書で構成してコンテナーのポート 80 にリダイレクトしても問題ありませんか?

最も簡単な方法は、外部トラフィックのみを保護することだと思います。なぜなら、Asp.Net Core WebAPI を HTTPS 経由で自分自身 (kestrel) に提供するように構成するには、ボリュームに証明書をマウントし、証明書のパスワードを提供する必要があるためです。これは少し複雑です。

ベストプラクティスは何ですか?

答え1

要件とリソース、オンプレミスかベアメタルかなどによって異なります。

トラフィックを保護する要件はありません

クラスター内のクライアント トラフィックのセキュリティ保護に関する要件がない場合は、クライアントSSL接続を終了してPod 間でingress-controller使用できます。HTTP

安全な要件

宛先ポッドへのクライアント トラフィックを保護する必要がある場合は、2 つの方法で取得できます。

  • L3 LoadBalancerノードポート、構成SSL パススルーの上Ingress
  • トラフィックが使用する必要があるが、指定された場所に直接SSL配信する必要がない場合は、設定することで実装が簡単になります。SSLPodイスティオメッシュmTLS。このオプションを使用すると、HTTPヘッダーを使用してトラフィックをルーティングでき、証明書を手動で管理する必要がなくなります。チェックしてくださいこれ詳細については。

ベスト プラクティスでは、常に可能な限りのセキュリティを確保する傾向があるため、安全な接続を使用することが常に推奨されます。ただし、一部のシナリオでは、それは必要ありません。

答え2

クラスターがクラウド上で実行されており、外部クラウドバランサーイングレスとポッドは異なるマシンまたはデータセンターに配置されている可能性があります。この場合、イングレスからポッドへの TLS を適用する必要があります。

いずれにしても、ロードバランサーとクラスターは同じ (できれば制限された) VPC 内にある必要があります。

答え3

また、保護する攻撃ベクトルによっても異なります。

Kubernetes ノード間のトラフィックを誰かが盗聴するのではないかと心配な場合は、WeaveNet などの暗号化をサポートするネットワーク プラグイン (CNI) の使用を検討するか、Wireguard または OpenVPN を使用してすべてのノードを VPN ネットワークに配置することができます。

クラスター上のサービスを相互に保護したい場合は、ポッド間のトラフィックを暗号化する Istio のようなものを検討する必要があります。

関連情報