5.7. カスタム TLS 証明書の設定


Red Hat Ansible Automation Platform は、トラフィックのセキュリティーを確保するために X.509 証明書とキーペアを使用します。これらの証明書は、Ansible Automation Platform コンポーネント間の内部トラフィックと、パブリック UI および API 接続の外部トラフィックを保護します。

Ansible Automation Platform デプロイメントの TLS 証明書を管理するには、主に次の 2 つの方法があります。

  1. Ansible Automation Platform によって生成される証明書 (デフォルト)
  2. ユーザーによって提供される証明書

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_certeda_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>
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る