第33章 IPsec を使用したホストの暗号化
33.1. 概要
IPsec は、インターネットプロトコル (IP) を使用して通信するすべてのマスターとノードホスト間の通信を暗号化することによって OpenShift Container Platform クラスターのトラフィックを保護します。
このトピックでは、すべてのクラスター管理および Pod データトラフィックを含め、OpenShift Container Platform ホストが IP アドレスを受信する IP サブセット全体の通信のセキュリティーを保護する方法について説明します。
OpenShift Container Platform 管理トラフィックは HTTPS を使用するため、IPsec の有効化により 2 度目の管理トラフィックの暗号化が実行されることになります。
この手順はクラスターの各マスターホストで繰り返し、その後にノードホストで実行される必要があります。IPsec が有効にされていないホストは、これが有効にされているホストと通信することができません。
33.2. ホストの暗号化
33.2.1. 前提条件
- libreswan 3.15 以降がクラスターホストにインストールされていることを確認します。便宜的なグループ (opportunistic group) 機能が必要な場合は、libreswan バージョン 3.19 以降が必要になります。
MTU を IPSec ヘッダーのスペースを確保するように設定する方法についての詳細は、「ノードでの Pod ネットワークの設定」セクションを参照してください。このトピックでは、62 バイトを必要とする IPSec 設定について説明します。クラスターが MTU が 1500 のイーサネットワークで動作している場合、IPSec および SDN のカプセル化のオーバーヘッドに対応するために SDN MTU は 1388 にする必要があります。
OpenShift Container Platform 設定で MTU を変更した後に、SDN インターフェースを削除し、OpenShift Container Platform ノードプロセスを再起動して SDN に変更を認識させる必要があります。
# systemctl stop atomic-openshift-node # ovs-vsctl del-br br0 # systemctl start atomic-openshift-node
33.2.2. 証明書での IPsec の設定
デフォルトで、OpenShift Container Platform は手動で相互に認証された HTTPS 通信でクラスター管理通信のセキュリティーを保護します。つまり、クライアント (例: OpenShift Container Platform ノード) およびサーバー (例: OpenShift Container Platform API サーバー) は相互にそれぞれの証明書を送信し、それは既知の認証局 (CA) に対してチェックされます。これらの証明書はクラスターの設定時に生成され、通常は各ホストに存在します。また、これらの証明書を使用して IPsec での Pod 通信のセキュリティーを保護することもできます。
この手順は、各ホストに以下があることを前提とします。
- クラスター CA ファイル
- ホストのクライアント証明書ファイル
ホストのプライベートキーファイル
libreswan 証明書データベースへのインポート後に証明書のニックネームが何であるかを判別します。ニックネームは証明書のサブジェクトの共通名 (CN) から直接取られます。
# openssl x509 \ -in /path/to/client-certificate -subject -noout | \ sed -n 's/.*CN=\(.*\)/\1/p'
openssl を使用してクライアント証明書、CA 証明書、およびプライベートキーファイルを PKCS#12 ファイルに追加します。これは、複数の証明書およびキーの共通ファイル形式です。
# openssl pkcs12 -export \ -in /path/to/client-certificate \ -inkey /path/to/private-key \ -certfile /path/to/certificate-authority \ -passout pass: \ -out certs.p12
PKCS#12 ファイルを libreswan 証明書データベースにインポートします。
-Wオプションは、パスワードが一時的で PKCS#12 ファイルに割り当てられないため、空のままになります。# ipsec initnss # pk12util -i certs.p12 -d sql:/etc/ipsec.d -W "" # rm certs.p12
33.2.3. libreswan IPsec ポリシー
必要な証明書が libreswan 証明書データベースにインポートされた後に、それらを使用してクラスター内のホスト間の通信をセキュリティー保護するポリシーを作成します。
libreswan 3.19 以降を使用している場合、便宜的なグループ (opportunistic group) 設定が推奨されます。これ以外の場合は、明示的な接続が必要になります。
33.2.3.1. 便宜的なグループ (opportunistic group) 設定
以下の設定は 2 つの libreswan 接続を作成します。最初の設定は OpenShift Container Platform 証明書を使用してトラフィックを暗号化し、2 つ目の設定はクラスターの外部トラフィック用に暗号化に対する例外を作成します。
以下を /etc/ipsec.d/openshift-cluster.conf ファイルに配置します。
conn private left=%defaultroute leftid=%fromcert # our certificate leftcert="NSS Certificate DB:<cert_nickname>" 1 right=%opportunisticgroup rightid=%fromcert # their certificate transmitted via IKE rightca=%same ikev2=insist authby=rsasig failureshunt=drop negotiationshunt=hold auto=ondemand conn clear left=%defaultroute right=%group authby=never type=passthrough auto=route priority=100- 1
- <cert_nickname> を、手順 1 の証明書ニックネームに置き換えます。
libreswan に対して、/etc/ipsec.d/policies/ のポリシーファイルを使用して各ポリシーを適用する IP サブネットおよびホストを示します。このファイルでは、それぞれの設定された接続に対応するポリシーファイルが設定されます。そのため、上記の例では、
privateおよびclearの 2 つの接続のそれぞれに /etc/ipsec.d/policies/ のファイルが設定されます。/etc/ipsec.d/policies/private には、ホストの IP アドレスの受信元であるクラスターの IP サブネットが含まれる必要があります。これにより、デフォルトでは、リモートホストのクライアント証明書がローカルホストの認証局の証明書に対して認証される場合、クラスターサブネットのホスト間のすべての通信が暗号化されることになります。リモートホストの証明書が認証されない場合、2 つのホスト間のすべてのトラフィックがブロックされます。
たとえば、すべてのホストが
172.16.0.0/16アドレス空間のアドレスを使用するように設定される場合、privateポリシーファイルには172.16.0.0/16が含まれることになります。暗号化する追加サブセットの任意の数がこのファイルに追加され、それらのサブネットへのすべてのトラフィックでも IPsec が使用されることになります。トラフィックがクラスターに出入りすることを確認するためにすべてのホストとサブネットゲートウェイ間の通信の暗号化を解除します。ゲートウェイを /etc/ipsec.d/policies/clear ファイルに追加します。
172.16.0.1/32
追加のホストおよびサブネットをこのファイルに追加できます。これにより、これらのホストおよびサブネットへのすべてのトラフィックの暗号が解除されます。
33.2.3.2. 明示的な通信設定
この設定では、各 IPSec ノード設定がクラスター内の他のすべてのノードの設定を明示的に一覧表示する必要があります。各ノードで Ansible などの設定管理ツールを使用してこのファイルを生成することが推奨されます。
また、この設定では各ノードの完全な証明書サブジェクトをその他のノードの設定に配置する必要があります。このサブジェクトをノードの証明書から読み取るには、openssl を使用します。
# openssl x509 \ -in /path/to/client-certificate -text | \ grep "Subject:" | \ sed 's/[[:blank:]]*Subject: //'
以下の行を、クラスター内のその他のノード用に各ノードの /etc/ipsec.d/openshift-cluster.conf ファイルに配置します。
conn <other_node_hostname> left=<this_node_ip> 1 leftid="CN=<this_node_cert_nickname>" 2 leftrsasigkey=%cert leftcert=<this_node_cert_nickname> 3 right=<other_node_ip> 4 rightid="<other_node_cert_full_subject>" 5 rightrsasigkey=%cert auto=start keyingtries=%forever以下を各ノードの /etc/ipsec.d/openshift-cluster.secrets ファイルに配置します。
: RSA "<this_node_cert_nickname>" 1- 1
- <this_node_cert_nickname> を手順 1 のノードの証明書ニックネームに置き換えます。
33.3. IPSec ファイアウォール設定
クラスター内のすべてのノードは、IPSec 関連のネットワークトラフィックを許可する必要があります。これには、UDP ポート 500 だけでなく IP プロトコル番号の 50 と 51 が含まれます。
たとえば、クラスターノードがインターフェース eth0 で通信する場合、以下のようになります。
-A OS_FIREWALL_ALLOW -i eth0 -p 50 -j ACCEPT -A OS_FIREWALL_ALLOW -i eth0 -p 51 -j ACCEPT -A OS_FIREWALL_ALLOW -i eth0 -p udp --dport 500 -j ACCEPT
また IPSec は、NAT traversal に UDP ポート 4500 を使用します。ただし、これは通常のクラスターデプロイメントに適用することはできません。
33.4. IPSec の開始および終了
ipsec サービスを開始し、新規の設定およびポリシーを読み込み、暗号化を開始します。
# systemctl start ipsec
ipsec サービスを有効にして起動時に開始します。
# systemctl enable ipsec
33.5. IPSec の最適化
IPSec を使用した暗号化の場合のパフォーマンス関連の提案についての詳細は、『Scaling and Performance Guide』を参照してください。
33.6. トラブルシューティング
2 つのノード間で認証を完了できない場合、すべてのトラフィックが拒否されるため、それらの間で ping を行うことはできません。clear ポリシーが適切に設定されていない場合も、クラスター内の別のホストから SSH をホストに対して実行することはできません。
ipsec status コマンドを使用して clear および private ポリシーが読み込まれていることを確認できます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.