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

パブリック 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 ホスト・ポリシーを確認します。

Kubernetes ダッシュボードへのアクセスを制限するデフォルトの Kubernetes ポリシーも作成されます。 Kubernetes ポリシーはホスト・エンドポイントには適用されませんが、代わりにポッド・レベルで適用され、すべてのクラシックと VPC のクラスターに適用されます。

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

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

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

   • Kubernetes バージョン 1.19 以降:

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

        ibmcloud ks 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. 環境変数をクラスターの構成ファイルに設定します。

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/kube-config.yaml
        

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 ネットワークポリシー または グローバルネットワークポリシーを定義します。 これらの構成ファイルにはどのポッド、名前空間、またはホストにこれらのポリシーを適用するかを説明するセレクターが含まれます。

   バージョン 1.29 以降でプロビジョニングされた新しいクラスターについては、 globalnetworkpolicies.crd.projectcalico.org （gnp ）および hostendpoints.crd.projectcalico.org （hep ）の短縮名はサポートされていません。 ただし、クラスタをバージョン 1.29 以降にアップグレードした場合でも、短縮名は引き続きサポートされます。

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. Kubernetes のダッシュボードに接続を試みて、ポリシーの変更によってこれらのコンポーネントに必要な接続がブロックされていないことを確認してください。

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を参照してください。

IBM Cloud Kubernetes Service およびその他の IBM Cloud の新規ロケーションが有効になると、これらのロケーションのサブネットが Calico ポリシーに追加されます。 これらのポリシーの更新情報については、必ず GitHub リポジトリをウォッチする をご確認ください。

なお、「 パブリックネットワークポリシーの適用 」および「 プライベートネットワークポリシーの適用 」の各セクションに記載されている、allow-egress-pods-public、allow-public-services-pods、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. ポリシーを適用します。
   
   ```sh {: pre}
       kubectl apply -f <policy_name>.yaml
       ```
   

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

   • nginx ポッドに着信する新規接続は、まず Kubernetes NetworkPolicy (順序 1000) に照らして評価されます。 run=access ラベルが付いたポッドからの接続は即時に受け入れられます。つまり、他のポリシーは評価されません。
   • run=access ラベルを持たないPod（またはPod以外のもの）から接続が行われた場合、 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 ポリシーであるため、元の run == 'nginx' に加え、 projectcalico.org/orchestrator == 'k8s' を含めて、このポリシーがポリシーのネームスペース内のすべてのポッドに適用されることを明示する必要があります。

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 または外部の syslog サーバーに転送します。