Apigee mTLS の概要

Apigee mTLS 機能により、Edge for Private Cloud クラスタ内のコンポーネント間の通信のセキュリティが強化されます。業界標準の方法でサービス メッシュを構成してインストールできます。パッケージ管理と構成の自動化がサポートされています。

アーキテクチャの概要

コンポーネント間の安全な通信を提供するために、Apigee mTLS はコンポーネント間の安全な相互認証 TLS 接続を確立するサービス メッシュを使用します。

次の図は、Apigee mTLS で保護される Apigee コンポーネント間の接続を示しています(in red)。画像に示されているポートは一例です。各コンポーネントで使用できる範囲のリストについては、ポートの使用をご覧ください

(「M」で示されているポートはコンポーネントの管理に使用され、Management Server がアクセスできるようにコンポーネント上で開いている必要があります)。

上の図に示すように、Apigee mTLS により、次のようなクラスタ内のほとんどのコンポーネント間の接続のセキュリティが強化されています。

送信元 宛先
Management Server Router、MP、QPid、LDAP、Postgres、ZooKeeper、Cassandra の各ノード
Router ループバック、Qpid、ZooKeeper、Cassandra の各ノード
Message Processor ループバック、Qpid、ZooKeeper、Cassandra の各ノード
ZooKeeper と Cassandra その他の ZooKeeper ノードと Cassandra ノード
Edge UI SMTP(外部 IDP のみ)
Postgres その他の Postgres、ZooKeeper、Cassandra の各ノード

メッセージの暗号化と復号

Apigee mTLS サービス メッシュは、クラスタ内の各 ZooKeeper ノードで実行される Consul サーバーと、クラスタ内のすべてのノード上の次の Consul サービスで構成されます。

  • ホストノードで送信メッセージをインターセプトする下り(外向き)プロキシ。このサービスは、送信メッセージを宛先に送信する前に暗号化します。
  • ホストノードで受信メッセージをインターセプトする上り(内向き)プロキシ。このサービスは、受信メッセージを最終的な宛先に送信する前に復号します。

たとえば、Management Server が Router にメッセージを送信すると、下り(外向き)プロキシ サービスは送信メッセージをインターセプトして暗号化し、Router に送信します。Router のノードがメッセージを受信すると、上り(内向き)プロキシ サービスはメッセージを復号し、Router コンポーネントに渡して処理します。

これはすべて、Edge コンポーネントに対して透過的に行われます。Consul プロキシ サービスによって行われる暗号化プロセスと復号プロセスは認識されません。

さらに、Apigee mTLS は iptables ユーティリティ(トラフィックのリダイレクトを管理する Linux ファイアウォール サービス)を使用します。

要件

Apigee mTLS をインストールする前に、環境が次の要件を満たしている必要があります。

以下のセクションでは、各要件について詳しく説明します。

バージョン、プラットフォーム、トポロジ

次の表に、mTLS の要件を示します。

要件 説明
バージョン
  • 4.51.00
  • 4.50.00
  • 4.19.06
トポロジ 3 つ以上の Zookeeper ノードを含める必要があります。結果として、Apigee mTLS は 5、9、12(マルチデータ センター)または 13 のノードを使用するトポロジにのみインストールできます。詳細については、インストール トポロジをご覧ください。
プラットフォーム / オペレーティング システム

次の値を使用して、特定の OS で Apigee mTLS がサポートされているかどうかを判断します。

OS サポートされている Private Cloud のバージョン
v4.19.06 v4.50.00 v4.51.00
CentOS
RedHat Enterprise Linux(RHEL)
Oracle Linux
7.5、7.6、7.7 7.5、7.6、7.7、7.8、7.9 7.5、7.6、7.7、7.8、7.9、8.0

Apigee mTLS は、実行中の Apigee Edge for Private Cloud の対応バージョンでサポートされている OS をすべてサポートしているわけではありません。

たとえば、v4.19.06 が CentOS x と y をサポートしている場合、必ずしも v4.19.06 に対して Apigee mTLS が CentOS x および y でサポートされているわけではありません。

ユーティリティ / パッケージ

Apigee mTLS では、インストール プロセスを開始する前に、クラスタ内の各マシン(管理マシンを含む)に次のパッケージをインストールして有効にしておく必要があります。

ユーティリティ / パッケージ 説明 インストール後に削除可能か
base64 インストール スクリプト内のデータを確認します。
gnu-bash
gnu-sed
gnu-grep
インストール スクリプトやその他の一般的なツールで使用されます。
iptables デフォルトのファイアウォール firewalld を置き換えます。
iptables-services iptables ユーティリティに機能を提供します。
lsof インストール スクリプトで使用されます。
nc iptables のルートを確認します。
openssl 最初のブートストラップ プロセス中にローカルで証明書に署名します。

インストール時に、管理マシンにも Consul パッケージをインストールして、認証情報と暗号鍵を生成できるようにします。

apigee-mtls パッケージは、クラスタ内の ZooKeeper ノードに上り(内向き)プロキシと下り(外向き)プロキシを含む Consul サーバーをインストールして構成します。

ユーザー アカウント権限

インストールする前に、新しいユーザー アカウントを作成するか、昇格した権限を持つユーザー アカウントにアクセスできることを確認してください。

クラスタ内の各ノードで Apigee mTLS インストールを実行するアカウントは、次のことができる必要があります。

  • Apigee コンポーネントを起動、停止、再起動、初期化する
  • ファイアウォール ルールを設定する
  • 新しい OS / システム ユーザー アカウントを作成する
  • systemctl を使用してサービスを有効化、無効化、開始、停止、マスクする

管理マシン(推奨)

Apigee では、このドキュメントで説明する次のような管理タスクを実行できるノードをクラスタ内に配置することをおすすめします。

  1. HashiCorp Consul 1.6.2 をインストールします。
  2. 証明書 / 鍵ペアとゴシップ暗号鍵を生成して配布します。
  3. 構成ファイルを更新して配布します。

管理マシンを設定するときに、次の操作を行います。

  • ルート権限があることを確認します。
  • Edge apigee-setup ユーティリティのインストールの説明に従って、apigee-serviceapigee-setup ユーティリティをダウンロードしてインストールします。
  • scp/ssh を使用して、管理マシンからクラスタ内のすべてのノードにアクセスできることを確認します。これは、構成ファイルと認証情報を配布するために必要です。

ポートの使用と割り当て

このセクションでは、Consul と Apigee mTLS との通信をサポートするためのポート使用とポート割り当てについて説明します。

ポートの使用: apigee-mtls を実行しているすべてのノード

apigee-mtls サービスを使用するクラスタ内のすべてのノードは、ローカルホスト(127.0.0.1)上のサービスから接続できる必要があります。これにより、Consul プロキシは、受信メッセージと送信メッセージを処理するときに他のサービスと通信できます。

ポートの使用: Consul サーバーノード(ZooKeeper を実行しているノード)

クラスタ内のすべてのノードからのリクエストを受け入れるには、Consul サーバーノード(ZooKeeper を実行しているノード)で次のポートのほとんどを開く必要があります。

ノード Consul サーバーポート 説明 プロトコル 外部 mtls-agents を許可する
*
Consul サーバー(ZooKeeper ノード) 8300 クラスタ内のすべての Consul サーバーを接続します。 RPC
8301 クラスタ内のメンバーシップ メッセージとブロードキャスト メッセージを処理します。 UDP / TCP
8302 マルチデータセンター構成でメンバーシップ メッセージとブロードキャスト メッセージを処理する WAN ポート。 UDP / TCP
8500 同じノード上のプロセスから Consul Server API への HTTP 接続を処理します。

このポートはリモート通信や調整には使用されません。ローカルホストでのみリッスンします。

HTTP
8502 クラスタ内の他のノードから Consul Server API への gRPC + HTTPS 接続を処理します。 gRPC + HTTPS
8503 クラスタ内の他のノードから Consul Server API への HTTPS 接続を処理します。 HTTPS
8600 Consul サーバーの DNS を処理します。 UDP / TCP
* Apigee では、受信リクエストをクラスタ メンバー(クロス データストアを含む)のみに制限することをおすすめします。これを行うには iptables を使用します。

この表に示すように、consul-server コンポーネントを実行しているノード(ZooKeeper ノード)は、データセンター間でも、apigee-mtls サービスを実行しているクラスタのすべてのメンバーに対してポート 8301、8302、8502、8503 を開く必要があります。ZooKeeper を実行していないノードでは、これらのポートを開く必要はありません。

すべての Consul ノード(ZooKeeper を実行しているノードを含む)のポート割り当て

Consul 通信をサポートするには、次の Apigee コンポーネントを実行しているノードで、次の範囲内のポートへの外部接続が許可されている必要があります。

Apigee コンポーネント 範囲 ノードごとに必要なポートの数
Apigee mTLS 10700~10799 1
Cassandra 10100~10199 2
Message Processor 10500~10599 2
OpenLDAP 10200~10299 1
Postgres 10300~10399 3
Qpid 10400~10499 2
Router 10600~10699 2
ZooKeeper 10001~10099 3

Consul はポートを単純な直線的な方法で割り当てます。たとえば、クラスタに 2 つの Postgres ノードがある場合、最初のノードは 2 つのポートを使用するため、ポート 10300 と 10301 が割り当てられます。2 番目のノードも 2 つのポートを使用するため、そのノードに 10302 と 10303 が割り当てられます。これはすべてのコンポーネント タイプに適用されます。

ご覧のとおり、実際のポート数はトポロジによって異なります。クラスタに 2 つの Postgres ノードがある場合は、4 つのポート(2 つのノードにそれぞれ 2 つのポートを掛けた数)を開く必要があります。

次の点にご注意ください。

  • Consul プロキシは、Apigee サービスと同じポートをリッスンできません。
  • Consul のポートアドレス空間は 1 つだけです。Consul プロキシポートの割り当ては、データセンターを含むクラスタ全体で一意である必要があります。つまり、ホスト A のプロキシ A がポート 15000 をリッスンしている場合、ホスト B のプロキシ B はポート 15000 をリッスンできません。
  • 使用するポートの数は、前述のようにトポロジによって異なります。

マルチ データセンター構成では、mTLS を実行するすべてのホストでポート 8302 も開く必要があります。

Apigee mTLS が使用するデフォルトのポートをカスタマイズできます。この方法については、プロキシのポート範囲のカスタマイズをご覧ください。

制限事項

Apigee mTLS には次の制限があります。

  • Cassandra ノード間通信を暗号化しません(ポート 7000)。
  • 構成と設定はべき等ではありません。つまり、1 つのノードで 1 つの変更を行う場合、すべてのノードで同じ変更を行う必要があります。その変更内容は他のノードに適用されません。詳細については、既存の apigee-mtls 構成を変更するをご覧ください。

用語

このセクションでは、次の用語を使用します。

用語 定義
クラスタ Edge for Private Cloud インストールを構成するマシンのグループ。
Consul Apigee mTLS で使用されるサービス メッシュ。Consul が Private Cloud の通信を保護する方法については、Consul のセキュリティ モデルをご覧ください。
mTLS 相互認証 TLS。
サービス メッシュ オーバーレイ ネットワーク(またはネットワーク内のネットワーク)。
TLS トランザクション レイヤのセキュリティ。安全な通信のための業界標準の認証プロトコル。