本ドキュメントでは、Red Hat Ansible Tower がシークレットと接続を安全に処理する方法について説明します。
Ansible Tower は、以下の 3 組のシークレットを管理します。
ローカルの Ansible Tower ユーザー用のユーザーパスワード
Ansible Tower の操作に使用するシークレット (データベースパスワード、メッセージバスパスワードなど)
自動化で使用するシークレット (SSH キー、クラウド認証情報、外部パスワードボールト認証情報など)
Ansible Tower は、SHA256 ハッシュを使用した PBKDF2 アルゴリズムで、ローカルの Ansible Tower ユーザーパスワードをハッシュ化します。外部アカウントメカニズム (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 コンサルティングは、このような変更のサンプルを用意しています。
注釈
シークレットシステムがダウンしている場合、Tower は情報を取得できず、サービスが復元されると回復可能な方法で失敗する可能性があります。そのシステムで冗長性を使用することを強くお勧めします。
Tower により生成された SECRET_KEY が何らかの理由で不正アクセスを受け、再生成の必要があると思われる場合には、インストーラーから Tower のバックアップおよび復元ツールのように機能するツールを実行してください。新規シークレットキーを生成するには、以下を実行します。
操作を行う前にかならず、Tower データベースをバックアップしてください! 本ガイドの「Backing Up and Restoring Tower」セクションに記載の手順に従ってください。
使用中のインストールからインベントリーを使用して (バックアップ/復元を実行するインベントリーと同じ)、setup.sh -k を実行します。
以前のキーのバックアップは /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 設定など) のシステム設定を継承します。