5.7. カスタム TLS 証明書の設定
Red Hat Ansible Automation Platform は、トラフィックのセキュリティーを確保するために X.509 証明書とキーペアを使用します。これらの証明書は、Ansible Automation Platform コンポーネント間の内部トラフィックと、パブリック UI および API 接続の外部トラフィックを保護します。
Ansible Automation Platform デプロイメントの TLS 証明書を管理するには、主に次の 2 つの方法があります。
- Ansible Automation Platform によって生成される証明書 (デフォルト)
- ユーザーによって提供される証明書
5.7.1. Ansible Automation Platform によって生成される証明書 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、インストールプログラムは自己署名認証局 (CA) を作成し、それを使用してすべての Ansible Automation Platform サービス用の自己署名 TLS 証明書を生成します。自己署名 CA の証明書と鍵は、1 つのノードの ~/aap/tls/ ディレクトリーに生成され、他の全ノードの同じ場所にコピーされます。この CA は最初の作成日から 10 年間有効です。
自己署名証明書は、パブリック信頼チェーンの一部ではありません。インストールプログラムは、~/aap/tls/extracted/ の下に自己署名 CA 証明書を含む証明書トラストストアを作成し、そのディレクトリーを /etc/pki/ca-trust/extracted/ の下の各 Ansible Automation Platform サービスコンテナーにバインドマウントします。これにより、各 Ansible Automation Platform コンポーネントが、他の Ansible Automation Platform サービスの自己署名証明書を検証できるようになります。必要に応じて、CA 証明書を他のシステムまたはブラウザーのトラストストアに追加することもできます。
5.7.2. ユーザーによって提供される証明書 リンクのコピーリンクがクリップボードにコピーされました!
独自の TLS 証明書および鍵を使用して、インストール中に生成された自己署名証明書の一部またはすべてを置き換える場合は、インベントリーファイルで特定の変数を設定できます。パブリック CA または組織 CA は、インストールプロセス中に使用できるように、これらの証明書とキーを事前に生成する必要があります。
5.7.2.1. カスタム CA を使用してすべての TLS 証明書を生成する リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform ですべての証明書を生成するが、デフォルトの自己署名証明書ではなくカスタム CA で署名する必要がある場合は、この方法を使用します。
手順
カスタム認証局 (CA) を使用してすべての Ansible Automation Platform サービスの TLS 証明書を生成するには、インベントリーファイルで次の変数を設定します。
ca_tls_cert=<path_to_ca_tls_certificate> ca_tls_key=<path_to_ca_tls_key>
5.7.2.2. 各サービスにカスタム TLS 証明書を提供する リンクのコピーリンクがクリップボードにコピーされました!
この方法は、組織が Ansible Automation Platform の外部で TLS 証明書を管理しており、手動でのプロビジョニングが必要な場合に使用します。
手順
各サービス (Automation Controller、Automation Hub、Event-Driven Ansible など) に TLS 証明書を手動で提供するには、インベントリーファイルで次の変数を設定します。
# Platform gateway gateway_tls_cert=<path_to_tls_certificate> gateway_tls_key=<path_to_tls_key> gateway_pg_tls_cert=<path_to_tls_certificate> gateway_pg_tls_key=<path_to_tls_key> gateway_redis_tls_cert=<path_to_tls_certificate> gateway_redis_tls_key=<path_to_tls_key> # Automation controller controller_tls_cert=<path_to_tls_certificate> controller_tls_key=<path_to_tls_key> controller_pg_tls_cert=<path_to_tls_certificate> controller_pg_tls_key=<path_to_tls_key> # Automation hub hub_tls_cert=<path_to_tls_certificate> hub_tls_key=<path_to_tls_key> hub_pg_tls_cert=<path_to_tls_certificate> hub_pg_tls_key=<path_to_tls_key> # Event-Driven Ansible eda_tls_cert=<path_to_tls_certificate> eda_tls_key=<path_to_tls_key> eda_pg_tls_cert=<path_to_tls_certificate> eda_pg_tls_key=<path_to_tls_key> eda_redis_tls_cert=<path_to_tls_certificate> eda_redis_tls_key=<path_to_tls_key> # PostgreSQL postgresql_tls_cert=<path_to_tls_certificate> postgresql_tls_key=<path_to_tls_key> # Receptor receptor_tls_cert=<path_to_tls_certificate> receptor_tls_key=<path_to_tls_key> # Redis redis_tls_cert=<path_to_tls_certificate> redis_tls_key=<path_to_tls_key>
5.7.2.3. サービスごとに証明書を提供する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
個々のサービスごとにカスタム TLS 証明書を提供する場合は、次の点を考慮してください。
-
ホストごとに固有の証明書を提供できます。これには、前述のインベントリーファイルの例に示されているように、インベントリーファイルで特定の
_tls_certおよび_tls_key変数を定義する必要があります。 - 多数のノードにまたがってデプロイされるサービスの場合 (たとえば、エンタープライズトポロジーを採用する場合)、そのサービスに提供する証明書のサブジェクト代替名 (SAN) フィールドに、関連するすべてのノードの FQDN が含まれている必要があります。
- 外部向けサービス (Automation Controller やプラットフォームゲートウェイなど) が、SSL/TLS オフロードを実行するロードバランサーの背後にデプロイされている場合、サービスの証明書の SAN フィールドに、個々のサービスノードの FQDN に加えて、ロードバランサーの FQDN が含まれている必要があります。
5.7.2.4. カスタム CA 証明書の提供 リンクのコピーリンクがクリップボードにコピーされました!
TLS 証明書を手動で提供する場合は、その証明書がカスタム CA によって署名されている可能性があります。環境内で適切な認証とセキュアな通信を確保するために、カスタム CA 証明書を提供してください。複数のカスタム CA 証明書がある場合は、それらを 1 つのファイルに結合する必要があります。
手順
手動で提供した TLS 証明書のいずれかがカスタム CA によって署名されている場合は、インベントリーファイルで次の変数を使用して CA 証明書を指定する必要があります。
custom_ca_cert=<path_to_custom_ca_certificate>複数の CA 証明書がある場合は、それらを 1 つのファイルに結合し、結合した証明書を
custom_ca_cert変数で参照します。
5.7.3. Receptor 証明書の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
Receptor ノードにカスタム証明書を使用する場合、証明書のサブジェクト代替名 (SAN) の otherName フィールドに、値 1.3.6.1.4.1.2312.19.1 が指定されている必要があります。詳細は、Above the mesh TLS を参照してください。
Receptor はワイルドカード証明書の使用をサポートしていません。さらに、TLS ホスト名検証を正しく実行するために、各 Receptor 証明書の SAN にホスト FQDN が指定されている必要があります。
5.7.4. Redis 証明書に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
Redis 関連サービスにカスタムの TLS 証明書を使用する際に、Extended Key Usage (EKU) を指定する場合は、相互 TLS (mTLS) 通信について次の点を考慮してください。
-
Redis サーバー証明書 (
redis_tls_cert) には、serverAuth(Web サーバー認証) およびclientAuth(クライアント認証) EKU が含まれている必要があります。 -
Redis クライアント証明書 (
gateway_redis_tls_cert、eda_redis_tls_cert) には、clientAuth(クライアント認証) EKU が含まれている必要があります。
5.7.5. カスタム Receptor 署名鍵の使用 リンクのコピーリンクがクリップボードにコピーされました!
receptor_disable_signing=true が設定されていない Receptor 署名がデフォルトで有効になり、インストールプログラムによって RSA 鍵ペア (公開鍵と秘密鍵) が生成されます。ただし、以下の変数を使用して、カスタムの RSA 公開鍵と秘密鍵を設定できます。
receptor_signing_private_key=<full_path_to_private_key>
receptor_signing_public_key=<full_path_to_public_key>