Documentation

13. シークレットの処理と接続セキュリティー

本ドキュメントでは、Ansible Tower がシークレットと接続を安全に処理する方法について説明します。

13.1. シークレットの処理

Ansible Tower は、以下の 3 組のシークレットを管理します。

  • ローカルの Ansible Tower ユーザー用のユーザーパスワード

  • Ansible Tower の操作に使用するシークレット (データベースパスワード、メッセージバスパスワードなど)

  • 自動化で使用するシークレット (SSH キー、クラウド認証情報、外部パスワードボールト認証情報など)

13.1.1. ローカルの Ansible Tower ユーザー用のユーザーパスワード

Ansible Tower は、SHA256 ハッシュを使用した PBKDF2 アルゴリズムで、ローカルの Ansible Tower ユーザーパスワードをハッシュ化します。外部アカウントメカニズム (LDAP、SAML、OAuth など) で認証を行うユーザーの場合には、パスワードやシークレットは保存されません。

13.1.2. Ansible Tower の操作に使用するシークレットの処理

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 のバックアップおよび復元ツールのように機能するツールを実行してください。新規シークレットキーを生成するには、以下を実行します。

  1. 操作を行う前にかならず、Tower データベースをバックアップしてください! 本ガイドの「Backing Up and Restoring Tower」セクションに記載の手順に従ってください。

  2. 使用中のインストールからインベントリーを使用して (バックアップ/復元を実行するインベントリーと同じ)、setup.sh -k を実行します。

以前のキーのバックアップは /etc/tower/ に保存されます。

13.1.3. 自動化で使用するシークレットの処理

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 を使用することが推奨されます。

13.2. 接続のセキュリティー

13.2.1. 内部サービス

Ansible Tower は内部操作の一環として、以下のサービスに接続します。

  • PostgreSQL データベース

  • Redis キー/値のストア

redis への接続は、ローカルの UNIX ソケットを介して行われ、awx サービスユーザーに制限されます。

PostgreSQL データベースには、TCP 経由のパスワード認証か、ローカルホストまたはリモート (外部データベース) を使用して接続されます。この接続では、インストーラーサポートでネイティブに設定されているので、SSL/TLS には PostgreSQL の組み込みサポートを使用できます。SSL/TLS プロトコルは、デフォルトの OpenSSL 構成で設定されます。

13.2.2. 外部アクセス

Ansible Tower にアクセスするには、nginx 提供の標準ポートで、標準の HTTP/HTTPS を使用します。自己署名された証明書/キーがデフォルトでインストールされており、適切な証明書およびキーをローカルで指定できます。SSL/TLS アルゴリズムのサポートは、/etc/nginx/nginx.conf 設定ファイルで設定されています。デフォルトでは「中間」プロファイルが使用されており、このプロファイルをカスタム設定できます。カスタムの変更は、更新のたびに再適用する必要があります。

13.2.3. 管理ノード

Ansible Tower はまた、自動化の一環として管理対象マシンおよびサービスに接続します。全管理対象マシンには、SSH、WinRM、SSL/TLS など、仕様通りに標準のセキュリティーメカニズムを使用して接続します。管理ノードはそれぞれ、対象となる機能 (システムの OpenSSL 設定など) のシステム設定を継承します。