12. シークレット管理システム¶
ユーザーおよび管理者は、Tower がユーザーや管理者に代わってマシンや外部サービスにアクセスできるように、マシンとクラウドの認証情報を Tower にアップロードします。デフォルトでは、Tower の機密認証情報の値 (SSH パスワード、SSH 秘密鍵、クラウドサービスの API トークン) は、暗号化後にデータベースに保存されます。認証情報プラグインによりサポートされる外部認証情報では、Tower に直接指定せずに、認証情報フィールド (パスワードまたは SSH 秘密鍵) を secret management system に保存されている値にマッピングできます。Ansible Tower では、以下と統合できるシークレット管理システムが含まれています。
CyberArk の Application Identity Manager (AIM)
CyberArk Conjur
HashiCorp Vault Key-Value Store (KV)
HashiCorp Vault SSH Secrets Engine
Microsoft Azure Key Management System (KMS)
これらのシークレットの値は、Playbook で必要となるので、Playbook の実行前にフェッチされます。Tower ユーザーインターフェースでのこれらの認証情報の指定に関する情報は、「認証情報」を参照してください。
12.1. シークレットルックアップの設定およびリンク¶
Tower がサードパーティーシステムからシークレットをプルする場合は、認証情報フィールドと外部システムをリンクする必要があります。認証情報フィールドを外部システムに保存している値にリンクするには、対象のシステムに適した外部認証情報を選択し、metadata を指定して任意の値をルックアップします。メタデータの入力フィールドは、external credential type の source credential 定義に含まれます。
Tower は、開発者、インテグレーター、管理者、パワーユーザーに credential plugin インターフェースを提供し、Tower に外部の認証情報タイプを新たに追加することで、Tower を拡張して他のシークレット管理システムをサポートできるようにします。詳細は、「development docs for credential plugins」を参照してください。
サポートされているサードパーティーの各シークレット管理システムごとに設定して使用するには、Ansible Tower ユーザーインターフェースを使用します。
まず、シークレット管理システムとの認証向けの外部認証情報を作成します。最低でも、外部認証情報の名前を指定し、認証情報タイプ で以下のいずれかを選択します。
ターゲット認証情報の認証情報フォームに移動して、1 つまたは複数の入力フィールドを、外部の認証情報および外部システムのシークレットの場所を特定するメタデータとリンクします。以下の例では、Demo Credential がターゲット認証情報です。
外部認証情報にリンクする タイプの詳細 エリアの下のフィールドについては、入力フィールドの
ボタンをクリックします。使用する入力ソースを設定して、シークレット情報を取得するようにプロンプトが表示されます。
リンクする認証情報を選択して、次へ をクリックすると、入力ソースのメタデータタブに移動します。以下の例は、HashiVault Secret Lookup のメタデータのプロンプトです。
必要なメタデータは、選択した入力ソースにより異なります。
入力ソース |
メタデータ |
説明 |
|---|---|---|
** CyberArk AIM ** |
オブジェクトクエリー (必須) |
オブジェクトの検索クエリー |
オブジェクトクエリーフォーマット (必須) |
特定のシークレット名には |
|
理由 |
オブジェクトのポリシーごとに必要な場合は、CyberArk は理由のログを記録するので、シークレットをチェックアウトする理由を指定します。 |
|
CyberArk Conjur |
シークレット識別子 |
シークレットの識別子 |
シークレットのバージョン |
必要に応じてシークレットのバージョンを指定します。しない場合には、空白にしておくと、最新バージョンが使用されます。 |
|
HashiVault Secret Lookup |
シークレットバックエンドの名前 |
使用する KV バックエンドの名前を指定します。Path to Secret フィールドの最初のパスセグメントを使用する場合は空白にします。 |
シークレットへのパス (必須) |
シークレット情報が保存されているパスを指定します (例: /path/username)。 |
|
キー名 (必須) |
シークレット情報を検索するキーの名前を指定します。 |
|
シークレットのバージョン (V2 のみ) |
必要に応じてバージョンを指定します。しない場合には、空白にしておくと、最新バージョンが使用されます。 |
|
HashiCorp が署名した SSH |
未署名の公開鍵 (必須) |
署名する証明書の公開鍵を指定します。ターゲットホストの認可キーファイルに存在させておく必要があります。 |
シークレットへのパス (必須) |
シークレット情報が保存されているパスを指定します (例: /path/username)。 |
|
ロール名 (必須) |
ロールは、Hashi Vault に保存されている、SSH 設定とパラメーターのコレクションです。通常、異なる特権、タイムアウトなどが指定されたロールを 2 つ指定できます。そのため、以下のように、Root と、権限が低いユーザー向けに署名された証明書を取得できるロールを指定できます。 |
|
有効なプリンシパル |
デフォルト以外に、Vault を要求するユーザー (単数または複数) を指定して、保存したキーの証明書を認可します。Hashi Vault には、署名済みのデフォルトユーザーが含まれます (例: ec2-user)。 |
|
Azure KMS |
シークレット名 (必須) |
Azure の Key Vault アプリで参照されるとおりの、実際のシークレット名 |
シークレットのバージョン |
必要に応じてシークレットのバージョンを指定します。しない場合には、空白にしておくと、最新バージョンが使用されます。 |
テスト をクリックして、シークレット管理システムへの接続を検証します。ルックアップに失敗した場合は、以下のようなエラーメッセージが表示されます。
完了したら OK をクリックします。クリックすると、プロンプトウィンドウが閉じ、ターゲット認証情報の詳細画面に移動します。「step 3 above」以降の 手順を繰り返して ターゲット認証情報の残りの入力フィールドに値を投入します。この方法で情報をリンクすることで、Tower はユーザー名、パスワード、キー、証明書、トークンなどの機密情報を、サードパーティーの管理システムから取得して、このデータをターゲット認証情報のフォームの残りのフィールドに投入します。
必要に応じて、機密情報を取得する方法でリンクを使用しないフィールドについては、手動で情報を指定します。フィールドごとの詳細は、「認証情報タイプ」を参照してください。
完了したら 保存 をクリックします。
12.1.1. CyberArk Central Credential Provider ルックアップ¶
この統合を有効にするには、CyberArk Central Credential Provider の Web サービスを実行してシークレットを保存する必要があります。Credential Type で CyberArk AIM Credential Provider Lookup が選択されている場合は、以下のメタデータを指定して、ルックアップを正しく設定してください。
CyberArk AIM URL (必須): CyberArk AIM のシークレット管理システムとの通信に使用する URL を指定します。
アプリケーション ID (必須): CyberArk AIM サービスで提供される識別子を指定します。
クライアントキー: CyberArk から提供される場合はクライアントキーを貼り付けます。
クライアント証明書: CyberArkから提供される場合は、証明書を貼り付けるときに
BEGIN CERTIFICATEおよびEND CERTIFICATEを追加します。SSL 証明書の検証: URL が HTTPS を使用する場合は、このオプション飲みを使用できます。このオプションをチェックして、Tower がサーバーの SSL 証明書が有効で信頼されていることを検証できるようにします。内部またはプライベートの CA を使用する環境では、このオプションのチェックを解除して、検証を無効にします。
以下では、CyberArk AIM 認証情報の設定例を示します。
12.1.2. CyberArk AIM Secret Lookup¶
認証情報タイプ に CyberArk Conjur Secret Lookup が選択されている場合には、以下のメタデータを指定して、ルックアップを正しく設定します。
Conjur URL (必須): CyberArk Conjur のシークレット管理システムとの通信に使用する URL を指定します。
API キー (必須): Conjur の管理者から受け取ったキーを指定します。
アカウント (必須): 組織のアカウント名
ユーザー名 (必須): このサービス用に認証するユーザー
公開鍵証明書: CyberArkから提供される場合は、公開鍵を貼り付けるときに
BEGIN CERTIFICATEおよびEND CERTIFICATEを追加します。
以下では、CyberArk Conur 認証情報の設定例を示します。
12.1.3. HashiCorp Vault Secret Lookup¶
認証情報タイプ に HashiCorp Vault Secret Lookup が選択されている場合には、以下のメタデータを指定して、ルックアップを正しく設定します。
サーバー URL (必須): HashiCorp Vault のシークレット管理システムとの通信に使用する URL を指定します。
トークン (必須): HashiCorp のサーバーの認証に使用するアクセストークンを指定します。
CA 証明書: HashiCorp のサーバーの検証に使用される CA 証明書を指定します。
Approle Role_ID: Approle 認証の ID を指定します。
Approle Secret_ID: Approle 認証に対応するシークレット ID を指定します。
Approle 認証へのパス:
/approleのデフォルトパス以外のパスを指定します。API バージョン (必須): 静的なルックアップには v1 を、バージョン化されたルックアップには v2 を選択します。
Approle およびそのフィールドの詳細は、「Vault documentation for Approle Auth Method」を参照してください。以下に、設定した HashiCorp Vault Secret Lookup 認証情報の例を示しています。
12.1.4. HashiCorp Vault 署名の SSH¶
認証情報タイプ に HashiCorp Vault 署名の SSH が選択されている場合には、以下のメタデータを指定して、ルックアップを正しく設定します。
サーバー URL (必須): HashiCorp 署名の SSH のシークレット管理システムとの通信に使用する URL を指定します。
トークン (必須): HashiCorp のサーバーの認証に使用するアクセストークンを指定します。
CA 証明書: HashiCorp のサーバーの検証に使用される CA 証明書を指定します。
Approle Role_ID: Approle 認証の ID を指定します。
Approle Secret_ID: Approle 認証に対応するシークレット ID を指定します。
Approle 認証へのパス:
/approleのデフォルトパス以外のパスを指定します。
Approle およびそのフィールドの詳細は、「Vault documentation for Approle Auth Method」を参照してください。
以下では、HashiCorp SSH Secrets Engine 認証情報の設定例を示します。
12.1.5. Microsoft Azure Key Vault¶
認証情報タイプ に Microsoft Azure Key Vault が選択されている場合には、以下のメタデータを指定して、ルックアップを正しく設定します。
Vault URL (DNS 名) (必須): HashiCorp Vault のシークレット管理システムとの通信に使用する URL を指定します。
クライアント ID (必須): Azure Active Directory が取得した通りの識別子を指定します。
クライアントシークレット (必須): Azure Active Directory が取得した通りのシークレットを指定します。
テナント ID (必須): Azure サブスクリプション内の Azure Active Directory インスタンスと関連する一意識別子を指定します。
クラウド環境: 適用するクラウド環境を選択します。
以下では、Microsoft Azure KMS 認証情報の設定例を示します。
