本ドキュメントでは、Red Hat Ansible Tower がシークレットと接続を安全に処理する方法について説明します。
Ansible Tower は、以下の 3 組のシークレットを管理します。
ローカルの Ansible Tower ユーザー用のユーザーパスワード
Ansible Tower の操作に使用するシークレット (データベースパスワード、メッセージバスパスワードなど)
自動化で使用するシークレット (SSH キー、クラウド認証情報、外部パスワードボールト認証情報など)
Ansible Tower は、SHA256 ハッシュを使用した PBKDF2 アルゴリズムで、ローカルのユーザーパスワードをハッシュ化します。外部アカウントメカニズム (LDAP、SAML、OAuth など) で認証を行うユーザーの場合には、パスワードやシークレットは保存されません。
Ansible Tower には、操作に使用する以下のシークレットがあります。
/etc/tower/SECRET_KEY
データベース内の自動化シークレットの暗号化に使用されるシークレットキー (以下を参照)。SECRET_KEY が変更されるか不明な場合、データベース内の暗号化されたフィールドにはアクセスできません。
/etc/tower/tower.{cert,key}
Ansible Tower の Web サービス用の SSL 証明書とキー。自己署名証明書/キーはデフォルトでインストールされていますが、適切な証明書とキーをローカルで指定できます。
/etc/tower/conf.d/postgres.py 内のデータベースパスワードおよび /etc/tower/conf.d/channels.py 内のメッセージバスのパスワード
Ansible Tower コンポーネントサービスへ接続するためのパスワード
このようなシークレットは、 Ansible Tower サービスが始動時に自動化された方法で読み取る必要があるため、すべて暗号化されずに Ansible Tower サーバーに保存されます。シークレットはすべて Unix の権限で保護され、root および Ansible Tower サービスのユーザー awx に制限されます。
これらのシークレットを非表示にする必要がある場合は、シークレットの読み取り元であるファイルを Python が解釈します。このようなファイルは、サービスの開始時に利用できる場合に限り、他のメカニズムを使用して、これらのシークレットを取得するように調節できます。この設定は、お客様が指定した変更内容であるため、アップグレードごとに再適用する必要があります。Red Hat サポートおよび Red Hat コンサルティングは、このような変更のサンプルを用意しています。
If, for any reason you believe the SECRET_KEY Tower generated for you has been compromised and needs to be regenerated, you can run a tool from the installer that behaves much like the Tower backup and restore tool. To generate a new secret key:
Backup your Tower database before you do anything else! Follow the procedure described in the Backing Up and Restoring Tower section of this guide.
Using the inventory from your install (same inventory with which you run backups/restores), run setup.sh -k.
A backup copy of the prior key is saved in /etc/tower/.
Ansible Tower は自動化に使用されるか、自動化の結果であるさまざまなシークレットをデータベースに保存します。これらのシークレットには以下のようなものがあります。
すべての資格情報タイプの全シークレットフィールド (パスワード、シークレットキー、認証トークン、シークレットクラウド認証情報)
Ansible Tower の設定で定義された外部サービスのシークレットトークンとパスワード
「パスワード」タイプの Survey フィールドエントリー
シークレットフィールドを暗号化するために、Tower は 暗号化用の 256 ビットキーを備えた CBC モードの AES、PKCS7 パディング、および認証に SHA256 を使用する HMAC を使用します。この暗号化/復号化プロセスでは AES-256 ビット暗号化キーを、前述の SECRET_KEY、モデルフィールドのフィールド名、データベースが割り当てられた自動増分レコード ID から引き出します。したがって、キーの生成プロセスで使用された何らかの属性が変更されると、Tower はシークレットを正しく復号することができません。Ansible Tower は、Ansible Tower が起動する Playbook から SECRET_KEY が絶対に読み取られることがなく、これらのシークレットが Tower のユーザーによって絶対に読み取られることがなく、シークレットフィールドの値がいずれも Ansible Tower REST API によって使用されないように設計されています。シークレットの値を Playbook で使用する場合は、この値が意図せず記録されないように、タスクで no_log を使用することをお勧めします。
Ansible Tower は内部操作の一環として、以下のサービスに接続します。
ローカルの memcached
PostgreSQL データベース
RabbitMQ メッセージバス
memcached への接続は、ローカルの UNIX ソケットを介して行われ、awx サービスユーザーに制限されます。
PostgreSQL データベースには、TCP 経由のパスワード認証か、ローカルホストまたはリモート (外部データベース) を使用して接続されます。この接続では、インストーラーサポートでネイティブに設定されているので、SSL/TLS には PostgreSQL の組み込みサポートを使用できます。SSL/TLS プロトコルは、デフォルトの OpenSSL 構成で設定されます。
RabbitMQ メッセージバスへの接続は、ローカル (Tower -> ローカルの RabbitMQ) およびリモート (ローカルの RabbitMQ から他の RabbitMQ クラスターメンバー) です。この接続では、インストーラーによってネイティブに設定された TLS 1.2 を使用できます。
Ansible Tower にアクセスするには、nginx 提供の標準ポートで、標準の HTTP/HTTPS を使用します。自己署名された証明書/キーがデフォルトでインストールされており、適切な証明書およびキーをローカルで指定できます。SSL/TLS アルゴリズムのサポートは、/etc/nginx/nginx.conf 設定ファイルで設定されています。デフォルトでは「中間」プロファイルが使用されており、このプロファイルをカスタム設定できます。カスタムの変更は、更新のたびに再適用する必要があります。
Ansible Tower はまた、自動化の一環として管理対象マシンおよびサービスに接続します。全管理対象マシンには、SSH、WinRM、SSL/TLS など、仕様通りに標準のセキュリティーメカニズムを使用して接続します。管理ノードはそれぞれ、対象となる機能 (システムの OpenSSL 設定など) のシステム設定を継承します。