※2022/2/1 追記
OpenShift4.8以降のdefaultCNIプロバイダーがOVN-kubernetesという記述について、マニュアル(4.8-4.9)ではまだOpenShift SDNがデフォルトとありましたので、修正しました。
経緯・課題
OpenShiftは機能の追加削除が頻繁にあり、versionによって利用可能な機能などが様変わりしています。コンテナ間のクラスタ内部ネットワークの制御においては、利用中のネットワークモジュールがどれかによってサポートされる機能(Egressのネットワークポリシーなど)が異なるため、ネットワークモジュールであるKubernetes CNIの確認方法を整理しました。
前提・環境など
・クラスタ環境 OpenShift4.8 (IBM Cloud Managed / クラシックネットワーク)
・作業環境 Mac OSX Big Sur 11.6
・calicoctl version3.20.3
参考
[Red Hat OpenShift Networking](https://www.ibm.com/cloud/architecture/articles/ibmaot-redhat-openshift/02-solutions-guide-networking-openshift-sdn)
(抜粋) ・Revision Note: The contents below is based on OpenShift 4.6 which has OpenShift SDN as the default CNI provider. From OpenShift 4.8, the default CNI provider has been changed to OVN-Kubernetes. The contents are to be updated in future revision.[OpenShiftでOVNを使ってみる](https://rheb.hatenablog.com/entry/openshift42ovn)
(要点) ・OpenShift v4.2から、OpenShift-SDNに加えて「OVN(Open Virtual Networking)」という仕組みを使った「ovn-kubernetes」というCNIプラグインも利用可能になった。 ・Network Policyの機能(IngressやEgressルールでの制御含む)も多くのCNIプラグインではiptablesで実現しており、ルールが増えるごとにパフォーマンス劣化が懸念されていたが、OVNを使った場合はOVSのFlowとして処理するため、iptablesのルールが増えることはない。[Installing a cluster on AWS with network customizations ](https://docs.openshift.com/container-platform/4.1/installing/installing_aws/installing-aws-network-customizations.html#nw-operator-cr_installing-aws-network-customizations)
・Network CRDの設定例[IBM Cloud:クラシック: ネットワーク・ポリシーによるトラフィックの制御(ポッド間のトラフィックの制御) ](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies&locale=ja#isolate_services)
・IBM Cloud Managed OpenShift(クラシックネットワーク)環境では、CNIはCalicoになります。Kubernetes CNI
OpenShiftでは、NetworkはKubernetes CNIが管理を行います。このKubernetes CNIにはさまざまなプラグインが利用可能ですが、主要なところは以下です。
・OpenShift SDN (OpenShift 4.6 標準)
・OVN-Kubernetes (OpenShift 4.8 標準)
・CNI Plugins(Calico など...)
・other 3rd Party Plugins
最初の２つは、ユーザが手動でinstallを実施した場合の標準になります。サポートされる機能の違いは、公式ガイド(表15.1 デフォルトの CNI ネットワークプロバイダー機能の比較)を参照ください。気をつけるべき違いは、ネットワークポリシー設定におけるegress(コンテナを出る通信の制御ルール)のサポート有無などがあります。
実行中のCNIプラグインの確認方法
Networkという名前のCustom Resource Diffinitionを探します。
CRD(カスタムリソース定義) のNetwork (operator.openshift.io API グループの方)を確認します。
Network リソースには、clusterというインスタンスが存在するので、選択してYAMLを確認します。
spec以下の設定に、defaultNetworkという項目があり、こちらに利用しているCNIプラグインが記載されています。今回はIBM ManagedのOpenShift4.8環境のため、"Calico"になっています。ここが、ベアメタルやVMにユーザー管理でインストールした場合、デフォルトだと4.6はOpenShiftSDN、4.8はOVN-Kubernetes*となります。
ちなみに、clusterNetworkやserviceNetworkのサブネットもここで確認ができます。
*OVN-kubernetesには近い将来移行するという情報がありますが、現状マニュアルではデフォルトはOpenShift SDNのままになっています。(2022/2/1修正)
IBM Cloud Managed OpeShift(クラシックネットワーク) の場合のCNIはCalico
IBM Cloud:クラシック: ネットワーク・ポリシーによるトラフィックの制御を参照すると、以下のように記載があります。
Calico は、Kubernetes ワーカー・ノードで Linux Iptables 規則をセットアップすることにより、Calico ポリシーに自動的に変換される Kubernetes ネットワーク・ポリシーを含め、これらのポリシーを実施します。 iptables 規則はワーカー・ノードのファイアウォールとして機能し、ネットワーク・トラフィックがターゲット・リソースに転送されるために満たさなければならない特性を定義します。
Calicoは基本的にOpenShift SDNと同じくiptablesのルールに基づいたネットワーク制御を実現していると読めます。Kubernetes Network Policyは、OpenShift SDNでもOVN-Kubernetesでもcalicoでも利用可能です。Egress Firewall(Egress Network Poclicy)など、デフォルトCNIで利用できるがcalicoでは利用できない機能が一部あります。
IBM Cloud Managed OpeShift(クラシックネットワーク) で構成中のネットワークポリシーを確認する。
上述のIBM Cloud公式に手順の記載がありますが、calicoctlというモジュールを作業端末にDLしてクラウド上のcalicoネットワークポリシーの情報にアクセスできます。
calicoctlをコマンドプロンプトなどで初めて使用する際、Macだと開発元を検証できないため開けない、とエラーになるので、以下のように「システム環境設定」の「セキュリテイとプライバシー」から許可します。
適用中のネットワークポリシーとグローバルネットワークポリシーを取得してみると、以下のようになります。
ネットワークポリシーは、Kubernetes Network Policy、calico Network Policyそれぞれの参照コマンドを実施しました。
あらかじめ検証のためtesta ネームスペースにoc applyで登録しているkubernetesネットワークポリシーは、oc getで想定どおり取得できています。
calicoctl get では、そもそもcalico network policyはデフォルトでも登録されておらず空で返ってきます。(calicoのネットワークポリシーは、projectcalico.org APIグループによる管理になります。kubernetesのネットワークポリシーはnetworking.k8s.io APIグループによる管理でそれぞれコマンドが異なります)
グローバルネットワークポリシーは、クラスタ構成時に自動で作成されているものが取得できています。allow-icmp(ping許可)などのルールが確認できます。
■ネットワークポリシー
■グローバルネットワークポリシー
終わりに
OpenShiftクラスタのネットワークセキュリティ周りに関しては、オンプレであれば今後OVN-Kubernetesが標準になっていくので、ネットワークのegressルールも含めて設計が可能ですが、クラウドベンダーのManaged OpenShiftでアーキテクチャ検討している場合は、一旦ベンダーで提供しているOpenShiftクラスタのCNIとネットワークポリシーなどの実装方針については公式ドキュメントで確認しておいた方が良いでしょう。