17. プロジェクトの署名と検証¶

17.1. 前提条件¶

• RHEL ノードは、以下を適切にサブスクライブする必要があります。

  • RHEL サブスクリプションと、有効な baseos および appstream リポジトリー

  • Ansible Automation Platform サブスクリプションと適切で有効な Ansible Automation Platform チャネル:

  ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms for RHEL 8
  ansible-automation-platform-2.3-for-rhel-9-x86_64-rpms for RHEL 9
  

• コンテンツの署名には、有効な GPG 公開鍵/秘密鍵のペア必要です。詳細は、How to create GPG keypairs を参照してください。

GPG キーの詳細は、GnuPG documentation を参照してください。

次のコマンドを使用して、有効な GPG キーペアがあり、デフォルトの GnuPG キーリングにあることを確認できます。

$ gpg --list-secret-keys

上記のコマンドで出力や trustdb was created を示す 1 行の出力が生成されない場合は、デフォルトのキーリングに秘密鍵がありません。この場合、How to create GPG keypairs を参照して、続行する前に新しいキーペアを作成する方法を確認してください。それ以外の出力が生成された場合は有効な秘密鍵があり、続行して ansible-sign を使用できます。

17.2. Ansible 自動コントローラーへの GPG キーの追加¶

コントローラーでコンテンツの署名と検証に GPG キーを使用するには、CLI で次のコマンドを実行して追加する必要があります。

$ gpg --list-keys
$ gpg --export --armour <key fingerprint> > my_public_key.asc

1. コントローラーのユーザーインターフェイスで、左側のナビゲーションメニューから 認証情報 をクリックし、追加 ボタンをクリックします。

2. 新しい認証情報にわかりやすい名前を付けます (たとえば、インフラストラクチャーチームの公開 GPG キー)。

3. 「認証情報タイプ」フィールドで、GPG 公開鍵 を選択します。

4. 参照 をクリックして、公開鍵ファイルを見つけて選択します (例: my_public_key.asc)。

5. 完了したら 保存 をクリックします。

これで、この認証情報は:ref:projects <ug_projects_add> 選択可能になり、コンテンツの検証は今後のプロジェクト同期で自動的に行われます。

注釈

プロジェクトキャッシュの SCM タイムアウトを使用して、コントローラーが署名済みコンテンツを再検証する頻度を制御します。プロジェクトが起動時に更新するように設定されている場合 (そのプロジェクトを使用するように設定されたジョブテンプレート)、キャッシュタイムアウト設定を有効にできます。これにより、最後の更新から N 秒が経過した後に更新するように指示されます。検証の実行頻度が高すぎる場合は、プロジェクトの「オプションの詳細」ペインの キャッシュタイムアウト フィールドに時間を指定して、プロジェクトの更新頻度を下げることができます。

17.3. ansible-sign CLI ユーティリティーへのアクセス¶

``ansible-sign``ユーティリティーは、ユーザーが署名し、プロジェクトが署名されているかどうかを確認するためのオプションを提供します。

1. 以下のコマンドを実行して ansible-sign をインストールします。

$ dnf install ansible-sign

2. ansible-sign が正常にインストールされたことを確認します。

$ ansible-sign --version

以下のような出力が表示されます (バージョン番号が異なる場合があります)。

ansible-sign 0.1

これは、ansible-sign が正常にインストールされたことを示します。

17.4. プロジェクトの同期¶

名前が示すように、プロジェクトへの署名には Ansible プロジェクトディレクトリーが関わります。プロジェクトディレクトリー構造のより洗練された例については、.`Ansible documentation <https://docs.ansible.com/ansible/latest/user_guide/sample_setup.html>`_ を参照してください。

次のサンプルプロジェクトの構造は非常に単純で、インベントリーファイルと、playbooks ディレクトリーの下の 2 つの小さな Playbook で構成されています。

$ cd sample-project/
$ tree -a .
.
├── inventory
└── playbooks
    └── get_uptime.yml
    └── hello.yml

1 directory, 3 files

ansible-sign は、プロジェクト内にあるすべてのセキュアなファイルのチェックサム (SHA256) を取得し、それらをチェックサムマニフェストファイルにコンパイルしてから、最後にそのマニフェストファイルに署名することで、コンテンツを改ざんから保護します。

コンテンツに署名する最初のステップは、ansible-sign に保護するファイルを示すファイルを作成します。このファイルは MANIFEST.in という名前で、プロジェクトの root ディレクトリーに置く必要があります。

内部的には、ansible-sign は Python の distlib ライブラリーの distlib.manifest モジュールを使用するため、MANIFEST.in はこのライブラリーが指定する構文に従う必要があります。MANIFEST.in ファイルディレクティブについては、Python Packaging User Guide を参照してください。

サンプルプロジェクトには 2 つのディレクティブが含まれており、以下のような MANIFEST.in ファイルが作成されます。

include inventory
recursive-include playbooks *.yml

このファイルを配置したら、チェックサムマニフェストファイルを生成して署名します。両方の手順は、1 つの ansible-sign コマンドで達成されます。

$ ansible-sign project gpg-sign .
[OK   ] GPG signing successful!
[NOTE ] Checksum manifest: ./.ansible-sign/sha256sum.txt
[NOTE ] GPG summary: signature created

これで、プロジェクトが署名されました。

gpg-sign サブコマンドは project サブコマンドの下にあることに注意してください。プロジェクトコンテンツに署名する場合、すべてのコマンドは ansible-sign project で始まります。前述したとおり、原則としてすべての ansible-sign project コマンドは、プロジェクトの root ディレクトリーを最終的な引数とします。

前述のように、デフォルトでは ansible-sign はデフォルトのキーリングを使用し、最初に見つけられる秘密鍵を検索し、プロジェクトに署名します。--fingerprint オプションで使用する特定の秘密鍵を指定するか、--gnupg-home オプションで完全に独立した GPG ホームディレクトリーを指定することもできます。

プロジェクトディレクトリーの構造を表示すると、新しい .ansible-sign ディレクトリーが作成されたことが分かります。このディレクトリーには、チェックサムマニフェストと、そのディレクトリー用の分離 GPG 署名が含まれています。

$ tree -a .
.
├── .ansible-sign
│   ├── sha256sum.txt
│   └── sha256sum.txt.sig
├── inventory
├── MANIFEST.in
└── playbooks
    ├── get_uptime.yml
    └── hello.yml

17.5. プロジェクトの検証¶

署名済みの Ansible プロジェクトが変更されていないことを確認する場合、ansible-sign を使用して、署名が有効かどうか、ファイルのチェックサムがチェックサムマニフェストが示すものと一致するかどうかを確認できます。特に、ansible-sign project gpg-verify コマンドを使用して、これらの両方の条件を自動的に検証できます。

$ ansible-sign project gpg-verify .
[OK   ] GPG signature verification succeeded.
[OK   ] Checksum validation succeeded.

何らかの理由で検証に失敗した場合は、原因のデバッグに役立つ情報が表示されます。コマンドで ansible-sign 直後にグローバル --debug フラグを渡すことで、より詳細な情報を有効にできます。

17.6. 自動署名¶

信頼性の高い CI 環境 (OpenShift、Jenkins など) を使用する環境では、署名プロセスを自動化できます。たとえば、選択した CI プラットフォームに GPG 秘密鍵をシークレットとして保存し、それを CI 環境の GnuPG にインポートできます。次に、通常の CI ワークフロー/コンテナー/環境内で上記の署名ワークフローを実行できます。

GPG を使用してプロジェクトに署名する場合、環境変数 ANSIBLE_SIGN_GPG_PASSPHRASE を署名キーのパスフレーズに設定できます。これは CI パイプラインに注入 (およびマスク/保護) できます。

直面したシナリオに応じて、署名中および検証中に異なる異なる終了コードで ansible-sign が返されます。CI 環境は障害に基づいて動作が異なる可能性があるため、これは CI と自動化のコンテキストでも役立ちます (たとえば、一部のエラーに対してアラートを送信し、他のエラーに対してはサイレントに失敗するなど)。

以下は、現在 ansible-sign で使用され、安定しているとみなされる終了コードです。