ネットワーク・ポリシーによるトラフィックの制御

デフォルトの Calico ネットワーク・ポリシー

パブリック VLAN を持つクラスターが作成されると、各ワーカー・ノードとそのパブリック・ネットワーク・インターフェースに対して、HostEndpoint ラベルを持つ ibm.role: worker_public リソースが自動的に作成されます。 この HostEndpoint により、ibm.role: worker_public ラベルを選択する Calico ポリシーによって特に許可されていない限り、パブリック・ネットワーク・インターフェースとの間のすべてのトラフィックがドロップされます。

各ワーカー・ノードとそのプライベート・ネットワーク・インターフェースに対しても、HostEndpoint ラベルを持つ ibm.role: worker_private リソースが自動的に作成されます。 プライベート・ネットワーク・インターフェースとの間のすべてのトラフィックが許可されるように、デフォルトの allow-all-private-default ポリシーが作成されます。 この HostEndpoint により、クラスター・ユーザーは、ibm.role: worker_private を選択して allow-all-private-default よりも低い順序番号を持つ Calico ポリシーを作成することで、容易にプライベート・ネットワーク・トラフィックをさらに制限できるようになります。

これらのデフォルトの Calico ホスト・ポリシーは、すべてのパブリック・アウトバウンド・ネットワーク・トラフィックを許可し、Kubernetes NodePort、LoadBalancer、Ingress サービスなどの特定のクラスター・コンポーネントへのパブリック・インバウンド・トラフィックを許可します。 デフォルトでは、すべてのプライベート・トラフィックが allow-all-private-default ポリシーによって許可されます。 デフォルト・ポリシーで指定されていない、インターネットからワーカー・ノードへのその他のインバウンド・ネットワーク・トラフィックはすべてブロックされます。 デフォルト・ポリシーはポッド間トラフィックに影響しません。

デフォルトのポリシーはクラスタから削除しないでください。次のクラスタマスターのリフレッシュまたはマスターの更新時に再作成されるためです。 トラフィックをさらに制限する場合は、下位の Calico ポリシーを適用してトラフィックをブロックします。 ブロック対象を完全に理解していること、およびブロックするトラフィックがクラスター・コンポーネントに必要ないことを確認してください。

クラスターに自動的に適用される、以下のデフォルトの Calico ホスト・ポリシーを確認します。

Calico CLI のインストールおよび構成

Calico ポリシーを表示、管理、および追加するには、Calico CLI をインストールして構成します。

1. Calico コマンドを実行するクラスターのコンテキストを設定します。

   • Red Hat OpenShift バージョン 4.6 以降:

     1. ご使用のクラスター用の kubeconfig 構成ファイルをダウンロードします。

        ibmcloud oc cluster config --cluster <cluster_name_or_ID>
        

     2. DATASTORE_TYPE 環境変数を kubernetes に設定します。

        export DATASTORE_TYPE=kubernetes
        

2. 企業ネットワーク・ポリシーがプロキシーまたはファイアウォールを使用して、ローカル・システムからパブリック・エンドポイントへのアクセスを禁止している場合は、Calico コマンドに対して TCP アクセスを許可します。

3. 手順に従って、calicoctl コマンド・ライン・ツールをインストールします。

   • Linux および OS X

     1. ご利用のオペレーティングシステムに適合する Calico CLIのバージョンをダウンロードしてください。 OS Xの場合、ダウンロードしたファイルを開き実行できるように、 システム環境設定 > セキュリティとプライバシー > 一般に移動して手動で許可する必要がある場合があります。

     2. ファイルを /usr/local/bin ディレクトリーに移動します。

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. ファイルを実行可能ファイルにします。

        chmod +x /usr/local/bin/calicoctl
        

     4. /etc/calico ディレクトリーに古い Calico 構成ファイル calicoctl.cfg がないことを確認します。 /etc/calico/calicoctl.cfg ファイルが存在する場合は、削除します。

   • Windows

     1. Calico CLIをダウンロードします。 そのファイルを保存するときに、ファイル名を calicoctl.exe に変更し、IBM Cloud CLI と同じディレクトリーに保存します。 このようにセットアップすると、後でコマンドを実行するとき、ファイル・パスの変更を行う手間がいくらか少なくなります。

     2. KUBECONFIG 環境変数に、手順 1 で見つけたネットワーク構成ファイルを設定します。

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/calicoctl.cfg
        

4. Calico 構成が正常に動作していることを確認します。

   calicoctl get nodes
   

   出力例

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

Calico のプラグイン、コンポーネント、またはデフォルトの Calico 設定の変更はサポートされていません。 例えば、新しい Calico プラグイン・バージョンをデプロイしたり、Calico コンポーネント、デフォルトの IPPool リソース、または Calico ノードのデーモン・セットまたはデプロイメントを変更したりしないでください。 代わりに、必要に応じて、Calico MTU の変更、 Calico CNI のポート・マップ・プラグインの無効化を資料の手順に従って行うことができます。

ネットワーク・ポリシーの表示

クラスターに適用される、デフォルト・ネットワーク・ポリシーおよび追加されたすべてのネットワーク・ポリシーの詳細を表示します。

始める前に、Calico CLI をインストールして構成し、Calico コマンドを実行するクラスターのコンテキストを設定します。

1. Calico ホスト・エンドポイントを表示します。

   calicoctl get hostendpoint -o yaml
   

2. クラスター用に作成されたすべての Calico ネットワーク・ポリシーを表示します。 このリストには、どのポッドまたはホストにもまだ適用されない可能性があるポリシーが含まれています。 Calico ポリシーを適用するには、Calico ネットワーク・ポリシー内のセレクターと一致する Kubernetes ポッドまたは Calico HostEndpoint が存在している必要があります。

   ネットワークポリシーは特定の名前空間に適用されます

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   グローバルネットワークポリシーは、特定の名前空間に限定されるものではありません

   calicoctl get GlobalNetworkPolicy -o wide
   

3. ネットワーク・ポリシーの詳細を表示します。

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. クラスターのすべてのグローバル・ネットワーク・ポリシーの詳細を表示します。

   calicoctl get GlobalNetworkPolicy -o yaml
   

ネットワーク・ポリシーの追加

通常、デフォルト・ポリシーを変更する必要はありません。 拡張シナリオのみ、変更が必要な場合があります。 変更が必要であるとわかった場合は、独自のネットワーク・ポリシーを作成できます。

Kubernetes ネットワークポリシーを作成するには、 Kubernetes ネットワークポリシーのドキュメントを参照してください。

Calico ポリシーを作成するには、以下の手順を実行します。 始める前に、Calico CLI をインストールして構成し、Calico コマンドを実行するクラスターのコンテキストを設定します。

1. Calico v3 ポリシー構文を使用して構成スクリプト（.yaml ）を作成し、 Calico ネットワークポリシー または グローバルネットワークポリシー を定義します。 これらの構成ファイルにはどのポッド、名前空間、またはホストにこれらのポリシーを適用するかを説明するセレクターが含まれます。

2. ポリシーをクラスターに適用します。 Windows システムを使用している場合は、 --config=<filepath>/calicoctl.cfg オプションを含めます。

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Calico および Kubernetes ネットワーク・ポリシーは、新規接続のみをブロックし、ポリシーが適用される前に存在していた接続は中断しません。 そのため、新しいポリシーまたは変更されたポリシーを適用した後、そのポリシーが正常に機能していること、および必要以上にブロックしていないことをテストするために、以下を実行します。

1. ポリシーの影響を受ける可能性があるすべてのポッドを再始動します。 さらに良いのは、セレクタが正しく設定されておらず、想定以上に影響がある場合に備えて、すべてのポッドを再起動することです。

2. ibmcloud ks cluster master refresh -c CLUSTER-ID を実行して、クラスター・マスター・ポッドを再始動します。 これにより、kubelet およびその他のコンポーネントからマスターへの既存の接続が中断され、強制的に再接続されます。 これにより、新規および変更されたポリシーがマスター・コンポーネントへの必要な接続をブロックするかどうかが示されます。

3. Red Hat OpenShift on IBM Cloud コンソールへの接続を試行して、ポリシーの変更によって、これらのコンポーネントが必要とする接続がブロックされないことを確認します。

NLB サービスまたは NodePort サービスへのインバウンド・トラフィックの制御

デフォルトで、Kubernetes NodePort サービス、および LoadBalancer サービスは、すべてのパブリック・クラスター・インターフェースとプライベート・クラスター・インターフェースでアプリを使用できるようにします。 ただし、Calico ポリシーを使用し、トラフィックのソースまたは宛先に基づいてサービスへの着信トラフィックをブロックすることができます。

Kubernetes NodePort サービスと LoadBalancer サービスに対して生成される DNAT Iptables ルールのため、これらのサービスを保護するためにデフォルトの Kubernetes ポリシーと Calico ポリシーを適用することは困難です。 しかし、Kubernetes がポッドにトラフィックを転送するために通常の DNAT を使用する前に、pre-DNAT ポリシーは Iptables 規則を生成して適用するため、指定されたトラフィックがアプリに到達することを防止します。

Calico pre-DNAT ネットワーク・ポリシーのいくつかの一般的な使用方法:

• プライベート・ネットワーク・ロード・バランサー・サービス (NLB) のパブリック・ノード・ポートへのトラフィックをブロックします。NLB サービスにより、NLB の IP アドレスとポート上でアプリが利用可能になり、サービスのノード・ポート上でアプリが利用可能になります。 ノード・ポートは、クラスター内のすべてのノードのすべての IP アドレス (パブリックとプライベート) でアクセス可能です。
• エッジ・ワーカー・ノードを実行しているクラスター上のパブリック・ノード・ポートへのトラフィックをブロックします。ノード・ポートをブロックすることにより、エッジ・ワーカー・ノードだけが着信トラフィックを扱うワーカー・ノードとなります。
• 特定のソース IP アドレスまたは CIDR からのトラフィックをブロックします
• 特定のソース IP アドレスまたは CIDR からのトラフィックのみ許可し、他のトラフィックをすべてブロックします

ソース IP アドレスを許可またはブロックする方法について確認するには、Calico ネットワーク・ポリシーを使用したトラフィックのブロックに関するチュートリアルをお試しください。

パブリック・ネットワーク・トラフィックまたはプライベート・ネットワーク・トラフィックを制限するための Calico ポリシーの例

クラスター・ワーカーのパブリック/プライベート・ネットワーク・トラフィックをさらに制限する Calico パブリック・ネットワーク・ポリシーのサンプル・セットが用意されています。 これらのポリシーは、クラスタの展開に必要なトラフィックを許可し、その他の特定のトラフィックをブロックします。

これらのポリシーは、すべてをブロックするためのものではなく、それ自体で必ずしもコンプライアンス要件を満たすものでもありません。 これらは開始点として意図されたものであり、お客様固有のユース・ケースに合わせて編集する必要があります。 詳しくは、 READMEを参照してください。

Red Hat OpenShift on IBM Cloud およびその他の IBM Cloud の新規ロケーションが有効になると、これらのロケーションのサブネットが Calico ポリシーに追加されます。 これらのポリシーに対する更新については、必ず GitHub リポジトリーをご覧ください。

以下のパブリックおよびプライベートネットワークポリシーセクションで、allow-egress-pods-public、allow-public-services-pods、allow-openshift-console、allow-kube-system-to-olm、allow-openshift-metrics、allow-egress-pods-private、またはallow-private-services-podsサンプルポリシーを使用することは推奨されなくなったことに注意してください。 これらのポリシーは、クラスタ内のすべてのポッドからのイグレスを制御した。 ポッド間のトラフィックを制御したい場合は、 Kubernetes NetworkPolicyを使用し、各ポッドを同じように扱うこれらの包括的なポリシーを使用する代わりに、特定の名前空間とポッドをターゲットにする必要があります。

ポッド間のトラフィックの制御

Kubernetes ポリシーは、内部ネットワーク・トラフィックからポッドを保護します。 単純な Kubernetes ネットワーク・ポリシー を作成して、1 つの名前空間内または複数の名前空間間でアプリ・マイクロサービスを相互に分離することができます。

デフォルトでは、すべてのポッドに、クラスター内の他のすべてのポッドへのアクセス権限があります。 さらに、ポッドは、ポッド・ネットワークによって公開されるサービス (メトリック・サービス、クラスター DNS、API サーバー、クラスター内で手動で作成するサービスなど) にアクセスできます。

拒否されたトラフィックのロギング

クラスター内の特定のポッドに対する拒否されたトラフィック要求をログに記録するには、Calico ログ・ネットワーク・ポリシーを作成します。

トラフィックをアプリ・ポッドに制限するネットワーク・ポリシーをセットアップしている場合、このポリシーで許可されないトラフィック要求は拒否され、除去されます。 一部のシナリオでは、拒否されたトラフィック要求の詳細情報が必要になる場合があります。 例えば、ネットワーク・ポリシーの 1 つによって一部の異常なトラフィックが継続的に拒否されることに気付く場合があります。 潜在的なセキュリティー脅威をモニターするには、指定されたアプリ・ポッドで試行されたアクションがポリシーで拒否されるたびに記録するようにロギングをセットアップします。

このセクションでは、Kubernetes ネットワーク・ポリシーによって拒否されたトラフィックをログに記録する方法を説明します。 Calico ネットワーク・ポリシーによって拒否されたトラフィックをログに記録するには、Calico ネットワーク・ポリシー・チュートリアルのレッスン 5 を参照してください。

始める前に、Calico CLI をインストールして構成し、Calico コマンドを実行するクラスターのコンテキストを設定します。

1. 着信トラフィックをブロックまたは制限する Kubernetes ネットワーク・ポリシーを作成するか、または既存のものを使用します。

   1. Kubernetes ネットワーク・ポリシーを作成します。 例えば、ポッド間のトラフィックを制御するには、NGINX アプリへのアクセスを制限する access-nginx という名前の以下のサンプル Kubernetes ポリシーを使用します。 「run=nginx」というラベルが付いたポッドへの着信トラフィックは、「run=access」ラベルを持つポッドからのみ許可されます。 「run=nginx」アプリ・ポッドへの他の着信トラフィックはすべてブロックされます。

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
       name: access-nginx
      spec:
       podSelector:
         matchLabels:
           run: nginx
       ingress:
         - from:
           - podSelector:
               matchLabels:
                 run: access
      

   2. ポリシーを適用します。

      oc apply -f <policy_name>.yaml
      

2. 前のステップで作成したポリシーによって拒否されたトラフィックをすべてログに記録するには、log-denied-packets という名前の Calico NetworkPolicy を作成します。 次の Calico ポリシーは、ステップ1で説明した例の access-nginx Kubernetes ポリシーと同じポッドセレクターを使用していますが、 Kubernetes NetworkPolicy ではなく Calico NetworkPolicy であるため、構文が若干異なります。 また、すべての Kubernetes NetworkPolicy が Calico によって注文 1000 として評価されるため、注文番号 3000 が追加され、 Kubernetes NetworkPolicyの後に評価されるようになっています。 これらの 2 つのポリシーを適用すると、結果は以下のようになります。

   • nginx ポッドに着信する新規接続は、まず Kubernetes NetworkPolicy (順序 1000) に照らして評価されます。 run=access ラベルが付いたポッドからの接続は即時に受け入れられます。つまり、他のポリシーは評価されません。

   • run=access ラベルのないポッド（またはポッド以外のもの）からの接続の場合、 Kubernetes NetworkPolicy は何も行わず、次に Calico が log-denied-packets ポリシーを評価します。 このポリシーは、nginx ポッドが存在するワーカー上の syslog にパケットを記録します。

   • その後、Calico は、接続に適用する他のポリシーがあるかどうかを検査し、ポリシーが見つからないため、パケットはドロップされます。 これは、明示的に許可されていないポリシーを持つポッドへのトラフィックがすべてドロップされるためです。

     apiVersion: projectcalico.org/v3
     kind: NetworkPolicy
     metadata:
       name: log-denied-packets
     spec:
       types:
       - Ingress
       ingress:
       - action: Log
         destination: {}
         source: {}
       selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
       order: 3000
     

   types

   この Ingress ポリシーは、すべての着信トラフィック要求に適用されます。 値 Ingress は、すべての着信トラフィックを表す一般用語であり、IBM Ingress ALB のみからのトラフィックを指すものではありません。 ingress

   : action: Log アクションは、このポリシーに一致するすべての要求のログ項目をワーカー・ノードの /var/log/syslog パスに書き込みます。

   destination: selector はこのポリシーを特定のラベルを持つすべてのポッドに適用するため、宛先は指定されません。

   source: このポリシーは、すべてのソースからの要求に適用されます。

   selector

   セレクターは、元の access-nginx Kubernetes NetworkPolicy と同じトラフィックをターゲットにする必要があります。 これは Calico ポリシーであるため、 projectcalico.org/orchestrator == 'k8s' を追加して、ポリシーのネームスペース内のすべてのポッドに適用されることを示す必要があります。また、元の run == 'nginx' も追加する必要があります。

   order

   Calico ポリシーには、着信要求パケットに適用されるタイミングを決定する順序があります。 1000 などの下位のポリシーが最初に適用されます。 上位ポリシーは、下位ポリシーの後に適用されます。 例えば、 3000 のように非常に高い優先順位を持つポリシーは、より優先順位の低いポリシーがすべて適用された後に、事実上最後に適用されます。 着信要求パケットには Iptables 規則チェーンが適用され、最初に下位ポリシーの規則との照合が試行されます。 パケットが任意の規則に一致した場合、そのパケットは受け入れられます。 ただし、パケットがどの規則にも一致しない場合、そのパケットは、最上位の Iptables 規則チェーン内の最後のルールに到達します。 このポリシーが確実にチェーン内の最後のポリシーになるように、ステップ 1 で作成したポリシーよりもずっと高い順序番号 (3000 など) を使用します。 Kubernetes NetworkPolicy は、 1000 の順で適用されます。

3. ポリシーを適用します。 Windows マシンを使用している場合は、 --config=<filepath>/calicoctl.cfg オプションを含めます。

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

4. ステップ 1 で作成したポリシーによって許可されない要求を送信して、ログ・エントリーを生成します。 例えば、ネットワーク・ポリシーによって保護されているポッドを、許可されていないポッドまたは IP アドレスから ping しようとします。

5. /var/log/syslog パスに作成されたログ・エントリーを確認します。 プロキシー、ネットワーク・アドレス変換 (NAT)、およびその他のネットワーキング・プロセスが原因で、ログ・エントリーの DST (宛先) または SRC (送信元) の IP アドレスが予想と異なるものになる場合があります。 ログ・エントリーは、以下のようになります。

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. オプション: /var/log/syslog のログを IBM Cloud Logs に転送します。