Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第36章 IPsec を使用したノード間のトラフィックの暗号化

36.1. 概要
リンクのコピー

IPsec は、インターネットプロトコル (IP) を使用して通信するすべてのマスターとノードホスト間の通信を暗号化することによって OpenShift Container Platform クラスターのトラフィックを保護します。

このトピックでは、すべてのクラスター管理および Pod データトラフィックを含め、OpenShift Container Platform ホストが IP アドレスを受信する IP サブセット全体の通信のセキュリティーを保護する方法について説明します。

注記

OpenShift Container Platform 管理トラフィックは HTTPS を使用するため、IPsec の有効化により 2 度目の管理トラフィックの暗号化が実行されることになります。

重要

この手順はクラスターの各マスターホストで繰り返し、その後にノードホストで実行される必要があります。IPsec が有効にされていないホストは、これが有効にされているホストと通信することができません。

36.2. ホストの暗号化
リンクのコピー

前提条件

  • 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
Copy to Clipboard Toggle word wrap

36.2.1. 証明書での IPsec の設定
リンクのコピー

デフォルトで、OpenShift Container Platform は手動で相互に認証された HTTPS 通信でクラスター管理通信のセキュリティーを保護します。つまり、クライアント (例: OpenShift Container Platform ノード) およびサーバー (例: OpenShift Container Platform API サーバー) は相互にそれぞれの証明書を送信し、それは既知の認証局 (CA) に対してチェックされます。これらの証明書はクラスターの設定時に生成され、通常は各ホストに存在します。また、これらの証明書を使用して IPsec での Pod 通信のセキュリティーを保護することもできます。

この手順は、各ホストに以下があることを前提とします。

  • クラスター CA ファイル
  • ホストのクライアント証明書ファイル

  • ホストのプライベートキーファイル

    1. libreswan 証明書データベースへのインポート後に証明書のニックネームが何であるかを判別します。ニックネームは証明書のサブジェクトの共通名 (CN) から直接取られます。 

      # openssl x509 \
  -in /path/to/client-certificate -subject -noout | \
  sed -n 's/.*CN=\(.*\)/\1/p'
      Copy to Clipboard Toggle word wrap

    2. 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
      Copy to Clipboard Toggle word wrap

    3. PKCS#12 ファイルを libreswan 証明書データベースにインポートします。-W オプションは、パスワードが一時的で PKCS#12 ファイルに割り当てられないため、空のままになります。 

      # ipsec initnss
# pk12util -i certs.p12 -d sql:/etc/ipsec.d -W ""
# rm certs.p12
      Copy to Clipboard Toggle word wrap

36.2.2. libreswan IPsec ポリシーの作成
リンクのコピー

必要な証明書が libreswan 証明書データベースにインポートされた後に、それらを使用してクラスター内のホスト間の通信をセキュリティー保護するポリシーを作成します。

libreswan 3.19 以降を使用している場合、便宜的なグループ (opportunistic group) 設定が推奨されます。これ以外の場合は、明示的な接続が必要になります。

36.2.2.1. 便宜的なグループ (opportunistic group) の設定
リンクのコピー

以下の設定は 2 つの libreswan 接続を作成します。最初の設定は OpenShift Container Platform 証明書を使用してトラフィックを暗号化し、2 つ目の設定はクラスターの外部トラフィック用に暗号化に対する例外を作成します。

  1. 以下を /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
    Copy to Clipboard Toggle word wrap
    1
    <cert_nickname> を、手順 1 の証明書ニックネームに置き換えます。

  2. 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 が使用されることになります。

  3. トラフィックがクラスターに出入りすることを確認するためにすべてのホストとサブネットゲートウェイ間の通信の暗号化を解除します。ゲートウェイを /etc/ipsec.d/policies/clear ファイルに追加します。 

    172.16.0.1/32
    Copy to Clipboard Toggle word wrap

    追加のホストおよびサブネットをこのファイルに追加できます。これにより、これらのホストおよびサブネットへのすべてのトラフィックの暗号が解除されます。

36.2.2.2. 明示的な接続の設定
リンクのコピー

この設定では、各 IPSec ノード設定がクラスター内の他のすべてのノードの設定を明示的に一覧表示する必要があります。各ノードで Ansible などの設定管理ツールを使用してこのファイルを生成することが推奨されます。

注記

node-config.yaml ファイルを手動で編集できません。クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。

また、この設定では各ノードの完全な証明書サブジェクトをその他のノードの設定に配置する必要があります。

  1. openssl を使用して、このサブジェクトをノードの証明書から読み取ります。 

    # openssl x509 \
  -in /path/to/client-certificate -text | \
  grep "Subject:" | \
  sed 's/[[:blank:]]*Subject: //'
    Copy to Clipboard Toggle word wrap

  2. 以下の行を、クラスター内のその他のノード用に各ノードの /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
    Copy to Clipboard Toggle word wrap
    1
    <this_node_ip> をこのノードのクラスター IP アドレスに置き換えます。
    2 3
    <this_node_cert_nickname> を手順 1 のノードの証明書ニックネームに置き換えます。
    4
    <other_node_ip> を他のノードのクラスター IP アドレスに置き換えます。
    5
    <other_node_cert_full_subject> を上記の他のノードの証明書に置き換えます。たとえば、"O=system:nodes,CN=openshift-node-45.example.com" のようになります。

  3. 以下を各ノードの /etc/ipsec.d/openshift-cluster.secrets ファイルに配置します。 

    : RSA "<this_node_cert_nickname>"
    1
    Copy to Clipboard Toggle word wrap
    1
    <this_node_cert_nickname> を手順 1 のノードの証明書ニックネームに置き換えます。

36.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
Copy to Clipboard Toggle word wrap
注記

また IPSec は、NAT traversal に UDP ポート 4500 を使用します。ただし、これは通常のクラスターデプロイメントに適用することはできません。

36.4. IPSec の開始および有効化
リンクのコピー

  1. ipsec サービスを開始し、新規の設定およびポリシーを読み込み、暗号化を開始します。 

    # systemctl start ipsec
    Copy to Clipboard Toggle word wrap

  2. ipsec サービスを有効にして起動時に開始します。 

    # systemctl enable ipsec
    Copy to Clipboard Toggle word wrap

36.5. IPSec の最適化
リンクのコピー

IPSec を使用した暗号化のパフォーマンス関連の提案についての詳細は、『Scaling and Performance Guide』を参照してください。

36.6. トラブルシューティング
リンクのコピー

2 つのノード間で認証を完了できない場合、すべてのトラフィックが拒否されるため、それらの間で ping を行うことはできません。clear ポリシーが適切に設定されていない場合も、クラスター内の別のホストから SSH をホストに対して実行することはできません。

ipsec status コマンドを使用して clear および private ポリシーが読み込まれていることを確認できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat