Apigee mTLS の概要

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

アーキテクチャの概要

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

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

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

上の図からわかるように、Apigee mTLS は、次のようなクラスタ内のほとんどのコンポーネント間の接続にセキュリティを追加します。

ソース 宛先
管理サーバー Router、MP、QPid、LDAP、Postgres、Zookeeper、Cassandra ノード
ルーター ループバック、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 サービスで構成されます。

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

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

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

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

要件

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

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

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

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

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

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

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 の CentOS x と y で Apigee mTLS がサポートされているとは限りません。

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

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-service ユーティリティと apigee-setup ユーティリティをダウンロードしてインストールします。
  • scp/ssh を使用して、管理マシンからクラスタ内のすべてのノードにアクセスできることを確認します。これは、構成ファイルと認証情報を配布するために必要です。

ポートの使用と割り当て

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

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

apigee-mtls サービスを使用するクラスタ内のすべてのノードで、localhost(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 接続を処理します。

このポートはリモート通信や調整には使用されず、localhost でのみリッスンします。

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 10,700 ~ 10,799 1
Cassandra 10100 ~ 10199 2
Message Processor 10500 ~ 10599 2
OpenLDAP 10,200 ~ 10,299 1
Postgres 10300 ~ 10399 3
Qpid 10,400 ~ 10,499 2
ルーター 10,600 ~ 10,699 2
ZooKeeper 10001 ~ 10099 3

Consul はシンプルな線形方式でポートを割り当てます。たとえば、クラスタに 2 つの Postgres ノードがある場合、最初のノードは 2 つのポートを使用するため、Consul はポート 10300 と 10301 を割り当てます。2 番目のノードも 2 つのポートを使用するため、Consol はそのノードに 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 構成を変更するをご覧ください。

用語

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

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