Red Hat Summit2.2. インストール
Ansible Automation Platform のセキュリティー体制に影響を与えるインストール時の決定がいくつかあります。インストールプロセスには多数の変数の設定が含まれます。その一部は Ansible Automation Platform インフラストラクチャーのハードニングに関連します。Ansible Automation Platform をインストールする前に、このガイドのインストールセクションのガイダンスを考慮してください。
2.2.1. 専用のインストールホストからのインストール
Ansible Automation Platform のインストールプログラムは、Automation Controller などのインフラストラクチャーサーバーの 1 つから、または Ansible Automation Platform のインフラストラクチャーサーバーに SSH アクセスできる外部システムから実行できます。Ansible Automation Platform のインストールプログラムは、インストールだけでなく、バックアップや復元、アップグレードなどのその後の Day 2 オペレーションにも使用されます。インストールと Day 2 オペレーションは、専用の外部サーバー (以降、インストールホストと呼びます) から実行することを推奨します。そうすることで、これらの機能を実行するためにインフラストラクチャーサーバーの 1 つにログインする必要がなくなります。インストールホストは、Ansible Automation Platform の管理にのみ使用してください。インストールホストで他のサービスやソフトウェアを実行しないでください。
インストールホストは、Red Hat Enterprise Linux セキュリティー強化 および組織に関連するセキュリティープロファイル要件 (CIS、STIG など) に従ってインストールおよび設定された Red Hat Enterprise Linux サーバーである必要があります。インストール計画 の説明に従って Ansible Automation Platform インストーラーを入手し、Red Hat Ansible Automation Platform インストーラーのインベントリーファイルの編集 の説明に従ってインストーラーインベントリーファイルを作成します。このインベントリーファイルは、インストールプログラムによるアップグレード、インフラストラクチャーコンポーネントの追加、および Day 2 オペレーションに使用します。そのため、今後の運用に使用できるようにインストール後にファイルを保存してください。
インストールホストへのアクセスは、Ansible Automation Platform インフラストラクチャーの管理を担当する担当者のみに制限する必要があります。インストールホストには、時間の経過とともに、インストールインベントリー (これには Ansible Automation Platform の初期ログイン認証情報が含まれます)、ユーザーが提供した PKI 鍵と証明書のコピー、バックアップファイルなどの機密情報が格納されます。インストールホストは、インフラストラクチャーの管理と保守に必要な場合、SSH 経由で Ansible Automation Platform インフラストラクチャーサーバーにログインするときにも使用する必要があります。
2.2.2. インストールインベントリー内のセキュリティー関連の変数
インストールインベントリーファイルは、Ansible Automation Platform インフラストラクチャーのアーキテクチャーを定義し、インフラストラクチャーコンポーネントの初期設定を変更するために使用できる多数の変数を提供します。インストーラーインベントリーの詳細は、インストーラーインベントリーファイルについて を参照してください。
次の表に、RPM ベースのデプロイメントにおけるセキュリティー関連の変数とその推奨値をいくつか示します。
| RPM デプロイメントの変数 | 推奨値 | 詳細 |
|---|---|---|
|
| true | この変数を設定すると、インストールプログラムにより、インストーラーによって管理される Postgres データベースが SSL ベースの接続を受け入れるように設定されます。 この変数のデフォルトは false です。これは PostgreSQL 接続に SSL/TLS を使用しないことを意味します。 true に設定すると、プラットフォームは SSL/TLS を使用して PostgreSQL に接続します。 |
|
| verify-full | これらの変数は、データベースへの相互 TLS (mTLS) 認証を制御します。デフォルトでは、各サービスがデータベースに接続するときに暗号化された接続を試行しますが、強制はしません。
この変数を 注記: インストーラーによって管理されるデータベースの代わりにサードパーティーのデータベースを使用する場合は、mTLS 接続を受け入れるようにサードパーティーのデータベースを個別にセットアップする必要があります。 |
|
| false |
デフォルトは |
次の表に、コンテナーベースのデプロイメントにおけるセキュリティー関連の変数とその推奨値をいくつか示します。
| コンテナーデプロイメントの変数 | 推奨値 | 詳細 |
|---|---|---|
|
| false |
デフォルトは
この変数がインストーラーインベントリーに存在しない場合は、変数を |
|
| verify-full | これらの変数は、データベースへの相互 TLS (mTLS) 認証を制御します。
デフォルトでは、各サービスがデータベースに接続するときに暗号化された接続を試行しますが、強制はしません。この変数を 注記 インストーラーによって管理されるデータベースの代わりにサードパーティーのデータベースを使用する場合は、mTLS 接続を受け入れるようにサードパーティーのデータベースを個別にセットアップする必要があります。 |
|
|
|
デフォルトは
これらの変数がインストーラーインベントリーに存在しない場合は、変数を |
|
|
| これらの変数を 'true' に設定すると、各コンポーネントの Web サービスへの HTTPS Strict Transport Security (HSTS) 接続が無効になります。
デフォルトは
これらの変数がインストーラーインベントリーに存在しない場合は、変数を |
複数のプラットフォームゲートウェイの手前でロードバランサーを使用するエンタープライズアーキテクチャーでは、SSL クライアント接続をロードバランサーで終端することも、個々の AAP サーバーにパススルーすることもできます。SSL をロードバランサーで終端する場合は、ロードバランサーから個々の Ansible Automation Platform サーバーへのトラフィックを再暗号化することを推奨します。これにより、エンドツーエンドの暗号化が確実に使用されます。このような場合、上記の *_disable_https 変数は、デフォルト値の false に設定します。
2.2.3. ユーザー提供の PKI 証明書を使用したインストール
デフォルトでは、Ansible Automation Platform は、プラットフォームのインフラストラクチャーコンポーネント用に、自己署名 公開鍵基盤 (PKI) 証明書を作成します。既存の PKI インフラストラクチャーが利用可能な場合は、Automation Controller、Private Automation Hub、Event-Driven Ansible Controller、および postgres データベースサーバー用の証明書を生成する必要があります。証明書ファイルと関連する鍵ファイルを、証明書の検証に使用する CA 証明書とともにインストールプログラムディレクトリーにコピーしてください。
次のインベントリー変数を使用し、新しい証明書を使用してインフラストラクチャーコンポーネントを設定します。
| RPM インストールの変数 | コンテナーインストールの変数 | 詳細 |
|
|
| カスタム CA 証明書ファイルへのパス。 設定されている場合、カスタム CA 証明書がシステムトラストストアにインストールされます。 |
|
|
| インストーラーディレクトリーにある Automation Controller の PKI 証明書のファイル名。 |
|
|
| インストールプログラムディレクトリーにある Automation Controller の PKI 鍵のファイル名。 |
|
|
| インストールプログラムディレクトリーにある Private Automation Hub の PKI 証明書のファイル名。 |
|
|
| インストールプログラムディレクトリーにある Private Automation Hub の PKI 鍵のファイル名。 |
|
|
| インストールプログラムディレクトリーにあるデータベースサーバーの PKI 証明書のファイル名。この変数は、インストーラーによって管理されるデータベースサーバーにのみ必要です。サードパーティーのデータベースを使用する場合は不要です。 |
|
|
| インストールプログラムディレクトリーにあるデータベースサーバーの PKI 鍵のファイル名。この変数は、インストーラーによって管理されるデータベースサーバーにのみ必要です。サードパーティーのデータベースを使用する場合は不要です。 |
|
|
| インストールプログラムディレクトリーにある Event-Driven Ansible Controller の PKI 証明書のファイル名。 |
|
|
| インストールプログラムディレクトリーにある Event-Driven Ansible Controller の PKI 鍵のファイル名。 |
| - |
| インストールプログラムディレクトリーにあるプラットフォームゲートウェイの PKI 証明書のファイル名。 |
| - |
| インストールプログラムディレクトリーにあるプラットフォームゲートウェイの PKI 鍵のファイル名。 |
複数のプラットフォームゲートウェイがロードバランサーを使用してデプロイされている場合、gateway_tls_cert と gateway_tls_key は、各プラットフォームゲートウェイによって共有されます。ホスト名の不一致を防ぐには、証明書の共通名 (CN) がロードバランサーで使用する DNS FQDN と一致する必要があります。組織のポリシーでサービスごとに固有の証明書が必要な場合、各証明書には、負荷分散サービスで使用する DNS FQDN と一致する サブジェクト代替名 (SAN) が必要です。各プラットフォームゲートウェイに固有の証明書とキーをインストールするには、インストールインベントリーファイル内の証明書と鍵の変数を、[all:vars] セクションではなく、ホストごとの変数として定義する必要があります。以下に例を示します。
[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1
[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2
[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key22.2.4. Ansible Vault を使用した機密変数の保護
Ansible Automation Platform のインストールインベントリーファイルには、デフォルトの管理者パスワードやデータベースパスワードなど、多数の機密変数が含まれています。デフォルトでは、これらはプレーンテキストで保存されます。Ansible Vault を使用して機密性の高い値を保護することにより、Ansible Automation Platform の RPM ベースおよびコンテナー化されたインストール環境で、セキュリティー、パスワードハイジーン、保守性が向上するという利点が得られます。
Ansible Vault ファイルを作成するには、次の手順を使用します。
手順
次のコマンドを使用してインストールディレクトリーに移動します。
cd /path/to/ansible-automation-platform-setup-bundle-2.5-<version>次のコマンドを使用して、Vault ファイルを作成します。
ansible-vault create vault.ymlプロンプトが表示されたら、Vault のパスワードを入力します。このパスワードは、Vault へのアクセスや変更に必要です。バックアップや再設定などの Day 2 オペレーションにも必要です。
重要特殊文字を含むパスワードは二重引用符で囲む必要があります。
- パスワードマネージャーや Vault サービスなどを使用して、組織のセキュリティーポリシーに従って Vault パスワードをセキュアに保存します。
- 機密変数を Vault に追加し、それらがインベントリーファイルで定義されていないことを確認します。
Vault ファイルを編集するには、次のコマンドを使用します。
ansible-vault edit <file>
2.2.4.1. RPM ベースの Ansible Automation Platform デプロイメントで外部 Vault ファイルを使用する
RPM ベースのインストールの場合、セットアップスクリプトを実行するときに、実行時に Ansible vault を提供できます。
次の機密変数を Vault ファイルに追加します。
admin_password: <secure_password>
pg_password: <secure_password>
automationgateway_admin_password: <secure_password>
automationgateway_pg_password: <secure_password>
automationhub_admin_password: <secure_password>
automationhub_pg_password: <secure_password>
automationedacontroller_admin_password: <secure_password>
automationedacontroller_pg_password: <secure_password>
*In the case of a connected installation:
registry_password: <secure_cdn_password>インストール中に Vault を使用するには、次の手順を使用します。
手順
-
Vault ファイル (例:
vault.yml) に、必要な機密変数がすべて含まれていることを確認します。 次のコマンドを使用してインストールを実行します。
./setup.sh -e @vault.yml –ask-vault-pass
この手順を使用すると、インストーラーが Vault から暗号化された変数を読み取り、Vault パスワードの入力を求めるようになります。
2.2.4.2. コンテナー化されたインストール環境で外部 Vault ファイルを使用する
Ansible Automation Platform のコンテナー化されたインストール環境の場合は、外部 Vault ファイルとともに提供されている自動化実行 Playbook を使用します。
次の機密変数を Vault ファイルに追加します。
postgresql_admin_password: <secure_password>
gateway_admin_password: <secure_password>
gateway_pg_password: <secure_password>
controller_admin_password: <secure_password>
controller_pg_password: <secure_password>
hub_admin_password: <secure_password>c
hub_pg_password: <secure_password>
eda_admin_password: <secure_password>
eda_pg_password: <secure_password>
*In the case of a connected installation:
registry_password: <secure_cdn_password>インストールプログラムで新しい Ansible Vault を使用するには、次の手順を使用します。
手順
-
Vault ファイル (例:
vault.yml) に、必要な機密変数がすべて含まれていることを確認します。 次のコマンドを使用してコンテナーインストーラーを実行します。
ansible-playbook ansible.containerized_installer.install -e @vault.yml –ask-become-pass
Vault ファイルが作業ディレクトリーにあることを確認するか、フルパスを指定します。plaintext インベントリーファイル内の暗号化された変数を複製しないでください。
2.2.5. コンプライアンスプロファイルに関する考慮事項
多くの環境では、セキュリティー制御が適用されている Red Hat Enterprise Linux システムに Ansible Automation Platform をインストールする必要があります。その目的は、CIS Critical Security Controls、Payment Card Industry/Data Security Standard (PCI/DSS)、DISA STIG などのコンプライアンスプロファイルの要件を満たすためです。このような環境では、Ansible Automation Platform を適切に実行するために、特定のセキュリティー制御セットを変更する必要がある場合があります。インストール前に、Ansible Automation Platform に使用されている Red Hat Enterprise Linux サーバーにコンプライアンスプロファイルの制御を適用してください。その後、必要に応じて以下のセキュリティー制御を変更します。
これらの制御が必要な環境では、セキュリティー監査担当者と制御の免除を検討してください。
2.2.5.1. fapolicyd
コンプライアンスポリシーによっては、fapolicyd デーモンの実行が要求されます。しかし、これは Ansible Automation Platform では現在サポートされていません。fapolicyd がポリシーを適用すると、Ansible Automation Platform のインストールおよび動作中に障害が発生するためです。このため、インストールプログラムは、fapolicyd がポリシーを適用していることを検出した場合にインストールを停止する事前チェックを実行します。このガイドでは、次の手順を使用して、Ansible Automation Platform で fapolicyd を permissive モードに設定することを推奨します。
-
ファイル
/etc/fapolicyd/fapolicyd.confを編集し、"permissive = 1" を設定します。 次のコマンドでサービスを再起動します。
sudo systemctl restart fapolicyd.service
このセキュリティー制御がインストールホストにも適用されている場合、デフォルトの fapolicyd 設定により、Ansible Automation Platform のインストールプログラムが失敗します。この場合、インストールホストで fapolicyd を permissive モードに設定することを推奨します。
2.2.5.2. "noexec" でマウントするファイルシステム
コンプライアンスプロファイルによっては、特定のファイルシステムを noexec オプションでして、そのファイルシステムにあるバイナリーの実行を防ぐことが要求されます。Ansible Automation Platform の RPM ベースのインストールプログラムは、次のファイルシステムのいずれかが noexec オプションでマウントされている場合に失敗する事前チェックを実行します。
-
/tmp -
/var -
/var/tmp
Ansible Automation Platform をインストールするには、noexec オプションを削除してこれらのファイルシステムを再マウントする必要があります。インストールが完了したら、次の手順に進みます。
-
noexecオプションを/tmpおよび/var/tmpファイルシステムに再適用します。 -
Automation Controller ジョブの実行パスを
/tmpから、noexecオプションが有効になっていない代替ディレクトリーに変更します。 - この変更を行うには、Automation Controller UI に管理者としてログインし、Settings に移動して Jobs settings を選択します。
- "Job execution path" 設定を代替ディレクトリーに変更します。
通常の運用中は、/var/lib/awx サブディレクトリー (通常は /var) を含むファイルシステムを noexec オプションを使用してマウントしないでください。使用すると、Automation Controller が実行環境で自動化ジョブを実行できません。
STIG コントロールが定期的に監査される環境では、ファイルシステム noexec に関連する STIG コントロールの免除についてセキュリティー監査者と相談してください。
2.2.5.3. ユーザー名前空間
コンプライアンスプロファイルによっては、Linux コンテナーの起動を防ぐために、カーネル設定 user.max_user_namespaces を "0" に設定することが要求されます。たとえば、DISA STIG ではこの制御が明確に要求されます。ただし、要求されるのは Linux コンテナーが不要な場合だけです。Ansible Automation Platform はコンテナーにインストールして運用することができ、また実行環境機能の一部としてコンテナーを使用します。そのため、Linux コンテナーが必要であり、この制御を無効にする必要があります。
user.max_user_namespaces カーネル設定を確認するには、インストールインベントリー内の各 Ansible Automation Platform コンポーネントに対して次の手順を実行します。
- コマンドラインで Automation Controller にログインします。
-
コマンド
sudo sysctl user.max_user_namespacesを実行します。 -
値がゼロであることが出力に示された場合は、ファイル
/etc/sysctl.confの内容と/etc/sysctl.d/の下のすべてのファイルを確認し、user.max_user_namespaces設定を含むファイルを編集して、値を "65535" に設定します。 -
この新しい値を適用するために、コマンド
sudo sysctl -p <file>を実行します。<file>は直前に変更したファイルです。 -
コマンド
sudo sysctl user.max_user_namespacesを再実行し、値が "65535" に設定されていることを確認します。
2.2.5.4. 対話型セッションのタイムアウト
コンプライアンスプロファイルによっては、対話型セッションのタイムアウトの適用が要求されます。たとえば、DISA STIG では、15 分間操作がないすべてのユーザーを自動的にログアウトさせることが要求されます。インストールプロセスは完了するまでに 1 時間以上かかることが多いため、このコントロールにより、インストールが完了する前にインストールプロセスが停止し、ユーザーがログアウトさせられる場合があります。同じことが、バックアップや復元などの Day 2 オペレーションにも当てはまります。実稼働環境では、このような操作は対話型セッションの推奨タイムアウト期間よりも長くかかることがよくあります。このような操作の実行時には、操作が確実に成功するように、対話型セッションのタイムアウトを増やしてください。
この制御を適用するには、複数の方法があります。たとえば、シェルのタイムアウト変数、systemd-logind のアイドルセッションタイムアウトの設定、SSH 接続タイムアウトの設定などです。各コンプライアンスプロファイルは、これらの方法を複数使用している場合があります。インストールや Day 2 オペレーションの妨げとなることが最も多いのは、systemd-logind のアイドルセッションタイムアウトです。これは、DISA STIG バージョン V2R1 (Red Hat Enterprise Linux 8) および V2R2 (Red Hat Enterprise Linux 9) で導入されました。systemd-logind のアイドルセッションタイムアウトを増やすには、root ユーザーとして次の手順を実行します。
-
ファイル
/etc/systemd/logind.confを編集します。 -
StopIdleSessionSec設定がゼロに設定されている場合、変更は必要ありません。 StopIdleSessionSec設定が 0 以外の場合、その秒数の経過後にセッションが終了します。StopIdleSessionSec=7200に変更してタイムアウトを増やし、systemctl restart systemd-logindを実行して変更を適用します。- 対話型セッションから完全にログアウトし、再度ログインして、新しい設定が現在のログインセッションに適用されていることを確認します。
この変更は、インストールホストでのみ行う必要があります。インストールホストが使用されていない場合は、Ansible Automation Platform のインストールプログラムが実行されるホストでのみ行う必要があります。
2.2.5.5. sudo と NOPASSWD
コンプライアンスプロファイルによっては、sudo 権限を持つすべてのユーザーがパスワードを入力することが要求されます (つまり、sudoers ファイルで NOPASSWD ディレクティブを使用することはできません)。Ansible Automation Platform のインストールプログラムは、特権ユーザーとして多くのタスクを実行し、パスワードなしで特権を昇格できることをデフォルトで想定しています。権限を昇格するためにインストールプログラムにパスワードを提供するには、RPM インストーラースクリプトの起動時に次のオプションを追加します。
./setup.sh <setup options> --ask-become-pass.
コンテナーベースのインストールプログラムの場合:
ansible-playbook ansible.containerized_installer.install --ask-become-pass
インストールプログラムを実行すると、権限を昇格するためにユーザーのパスワードの入力を求められます。
--ask-become-pass オプションの使用は、バックアップや復元などの Day 2 オペレーションのためにインストールプログラムを実行する場合にも当てはまります。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}