NodePort を使用してインターネット経由で Kubernetes サービスにアクセスできるようにする方法しか知らない場合、Kubernetes クラスターのセットアップ中に問題が発生する可能性があります。 NodePort サービス タイプを使用する場合、高いポート番号が割り当てられるため、ファイアウォール ルールでこれらのポートへの接続を許可する必要があります。サーバーがオープンなインターネット経由でアクセスできる場合は特に、インフラストラクチャに悪影響を及ぼします。クラスター内のサービスにトラフィックを送信できるクラスター管理者として、クラスター外の IP アドレスのブロックを割り当てることができます。これはまさにこの記事で説明することです: Kubernetes で拒否サービスの外部 IP を構成する方法に関するすべての重要な情報を見つけることです。
外部 IP サービスとは何ですか?
サービス エンドポイントの 1 つは、外部 IP (宛先 IP として) とサービス ポートを使用してクラスターに入るトラフィックを受信します。 Kubernetes は外部 IP の管理を担当しません。
この状況では、どの IP が Kubernetes クラスターへのアクセスに使用されているかを確認することが重要です。外部 IP サービス タイプを使用して、クラスタへのアクセスに使用される IP アドレスにサービスをバインドできます。
この状況を理解するには、Kubernetes ネットワークがオーバーレイ ネットワークと対話するという事実が重要です。これは、いずれかのノード (マスターまたはワーカー ノード) に到達すると、クラスター内の実質的にすべてのノードにアクセスできることを意味します。
ネットワークは次のように表示されます。
図のノード 1 と 2 は両方とも 1 つの IP アドレスを共有しています。実際のポッドはノード 1 に存在しますが、IP アドレス 1.2.3.6 はノード 1 の Nginx サービスにバインドされています。ノード 1 の IP アドレス 1.2.3.4 は httpd サービスにバインドされており、ノード 2 の実際のポッドはそこにあります。
これは、オーバーレイ ネットワークの基盤によって可能になります。 IP アドレス 1.2.3.4 を curl すると、httpd サービスが応答するはずです。 1.2.3.5 をカールすると、Nginx サービスが応答するはずです。
外部IPのメリットとデメリット
外部 IP の長所と短所は次のとおりです。
次の理由から、外部 IP を使用すると有利です。
-
- あなたの IP は完全にあなたの管理下にあります。クラウド プロバイダーの ASN を使用する代わりに、独自の ASN に属する IP を利用できます。
外部 IP の欠点には、次のようなものがあります。
-
- これから説明する簡単なセットアップは、すぐには利用できません。これは、ノードに障害が発生した場合、サービスにアクセスできなくなり、問題を手動で修正する必要があることを意味します。
- IP を扱うには、かなりの人手が必要です。 IP は動的に割り当てられないため、手動で行う必要があります。
デフォルトの拒否/許可動作とは何ですか?
「 デフォルトで許可 」 デフォルトですべてのトラフィックが許可されることを示します。特に許可されていない限り、「」という用語を使用すると、すべてのトラフィックがデフォルトで拒否されます デフォルトの拒否 」ただし、ネットワーク ポリシーが指定されている場合を除きます。
-
- Pod に対して有効なネットワーク ポリシーがない場合、Pod との間のすべてのトラフィックが許可されます。
- Ingress タイプの Pod に 1 つ以上のネットワーク ポリシーが適用されている場合、それらのポリシーによって明示的に許可されている Ingress トラフィックのみが許可されます。
- 1 つ以上のネットワーク ポリシーが egress タイプの Pod に適用される場合、それらのポリシーによって許可された egress トラフィックのみが許可されます。
他のエンドポイント タイプ (VM、ホスト インターフェイス) の既定の設定は、トラフィックをブロックすることです。エンドポイントに適用されるネットワーク ポリシーがない場合でも、ネットワーク ポリシーによって明示的に許可されたトラフィックのみが許可されます。
ベスト プラクティス: 暗黙のデフォルト拒否ポリシー
Kubernetes ポッド用に作成された暗黙的なデフォルトの拒否ポリシーを構成する必要があります。これにより、不要なトラフィックが自動的にブロックされます。暗黙のデフォルト拒否ポリシーは常に最後に有効になることに注意してください。他のポリシーがトラフィックを許可する場合、拒否は適用されません。拒否は、他のすべてのポリシーが考慮された後にのみ実装されます。
Kubernetes ポッドのデフォルトの拒否ポリシーを作成する方法は?
次のルールのいずれかを使用して Kubernetes ポッドのデフォルトの拒否ポリシーを構築できる場合でも、グローバル ネットワーク ポリシーを利用することをお勧めします。グローバル ネットワーク ポリシーは、すべての名前空間とホストのすべてのワークロード (VM とコンテナー) に適用されます。グローバル ネットワーク ポリシーは、リソースを保護しながらセキュリティへの慎重なアプローチを奨励しています。
-
- デフォルトを有効にして、名前空間なしのグローバル ネットワーク ポリシーを拒否します
- デフォルトを有効にしてネットワーク ポリシーを拒否し、名前空間を指定
- デフォルトを有効にして、名前空間付きの Kubernetes ポリシーを拒否します
IPブロックとは？
これにより、特定の IP CIDR 範囲が選択され、入力ソースまたは出力宛先として許可されます。 Pod IP は一時的で予測不可能であるため、これらはクラスター外部 IP にする必要があります。
クラスターの入口と出口の方法を使用する場合、パケットの送信元または宛先 IP を頻繁に書き換える必要があります。使用する特定のネットワーク プラグイン (クラウド サービス プロバイダー、サービスの実装など) によっては、動作が変わる場合があります。
これはイングレスに当てはまり、場合によっては、実際の送信元 IP に基づいて着信パケットをフィルタリングする必要があることを意味します。一方、NetworkPolicy が機能する「ソース IP」は、LoadBalancer または Pod のノードなどの IP である場合があります。
これは、クラスター外部 IP に書き換えられたポッドとサービス IP 間の接続が、エグレスに関して ipBlock ベースの制限を受ける可能性があることを示しています。
デフォルト ポリシーとは何ですか?
その名前空間に制御が設定されていない場合、名前空間内のポッドとの間のすべてのイングレスおよびエグレス トラフィックは、デフォルトで許可されます。次の例を使用して、名前空間のデフォルトの動作を変更できます。
デフォルトですべての入力トラフィックを拒否
すべてのポッドを選択するが、それらのポッドへの着信トラフィックを含まないネットワーク ポリシーを作成する場合、名前空間用の「デフォルト」のイングレス分離ポリシーを作成できます。
これにより、他の NetworkPolicy がポッドを選択するかどうかに関係なく、すべてのポッドがイングレスに対して分離されます。このルールは、ポッドを終了するための分離には適用されません。
デフォルトですべての送信トラフィックを拒否
すべてのポッドを選択するが、それらのポッドからのエグレス トラフィックを禁止する NetworkPolicy を作成すると、「デフォルト」のエグレス分離ポリシーを構築できます。これは名前空間にも適用されます。
結論
このガイドは、DenyServiceExternalIP の使用法に関するものでした。ユーザーが機能していることを理解できるように、図式表現も設計しました。設定例もご用意しております。