スーパーユーザー権限を持つ管理者の場合は、YAML/JSON などの定義を使用し、標準形式でカスタム認証情報タイプを定義し、新規の認証情報タイプをジョブやインベントリー更新に割り当てることができます。これにより、既存の認証情報タイプと同様のやり方で機能するカスタム認証情報タイプを定義することができます。たとえば、サードパーティー Web サービスの API トークンを環境変数に挿入し、Playbook やカスタムインベントリースクリプトが使用できるカスタム認証情報タイプを作成できます。
カスタム認証情報は、認証情報を挿入する以下の方法をサポートします。
環境変数
Ansible の追加変数
ファイルベースのテンプレート (認証情報の値が含まれる .ini
または .conf
ファイルの生成など)
ジョブテンプレートには、1 つの SSH と複数のクラウド認証情報を割り当てることができます。クラウド認証情報はそれぞれ異なるタイプである必要があります。つまり、1 つの AWS 認証情報、1 つの GCE 認証情報など、それぞれ 1 つずつのみ使用できます。Vault 認証情報とマシンの認証情報は別々のエンティティーになっています。
注釈
新規の認証タイプを作成する際には、extra_vars
、env
およびファイル名前空間での競合を回避する必要があります。また、ANSIBLE_
で開始する環境変数名と追加の変数名は予約されているため、この名前は使用しないようにします。認証タイプ (CredentialType
) を作成および変更し、CredentialType.injection
フィールドを表示するには、スーパーユーザーのパーミッションが必要です。
kind=galaxy
の「管理された」認証情報タイプは、プロジェクトの更新が実行した場合に、requirements.yml
で定義されたコレクションを取得するためのコンテンツソース (例: galaxy.ansible.com、cloud.redhat.com、オンプレミスのオートメーションハブ) を表します。この新しいタイプは、Ansible ドキュメントの Configuring the ansible-galaxy client で説明したように、プロジェクトの更新が ansible-galaxy collection install
を実行する際に環境変数を構築するのに必要な URL と、(任意の) 認証の詳細を表します。これには、Ansible Galaxy CLI に公開されている構成オプションに直接マップするフィールドがあります (per-server など)。API のエンドポイントは、組織レベルでこれらの認証情報の順序付きリストを反映します。
/api/v2/organizations/N/galaxy_credentials/
automation controller をインストールすると、アップグレード後に適切な認証情報が作成され、すべての組織に割り当てられるように、既存の Galaxy に合わせた設定値を移行します。最新バージョンへのアップグレード後、アップグレード前に存在していたすべての組織には、それに関連付けられた (1 つ以上の)「Galaxy」認証情報の一覧が含まれるようになりました。
また、アップグレード後、この設定は /api/v2/settings/jobs/
エンドポイントから表示 (または編集) できません。
galaxy.ansible.com は、その組織に対する一覧の最初の認証情報でなくても、automation controller は引き続き公開 Galaxy からロールを直接取得 (フェッチ) する必要があります。グローバルの「Galaxy」設定はジョブレベルで設定されなくなりましたが、ユーザーインターフェースの組織レベルで設定されるようになりました。組織の追加および編集の画面では、kind=galaxy
の認証情報に対して、任意の ** 認証情報** ルックアップフィールドがあります。
コンテンツの同期およびルックアップの優先順位は順序セットであるため、認証情報の順序を指定することが重要になります。詳細は「新しい組織の作成」を参照してください。コレクションを使用してプロジェクトを設定する方法の詳細は、「Hub でのコレクションの使用」を参照してください。
API のバージョン 2 のサポート (api/v2/
) は、ジョブテンプレートと認証情報 (マルチクラウドサポートを含む) の 1 対多の関係を意味します。認証情報は、v2 API を使用してフィルターを設定できます。
$ curl "https://controller.example.org/api/v2/credentials/?credential_type__namespace=aws"
V2 CredentialType モデルでは、リレーションシップは以下のように定義されます。
マシン |
SSH |
Vault |
Vault |
ネットワーク |
環境変数の設定 (例: |
SCM |
ソースコントロール |
クラウド |
EC2、AWS |
その他多数 |
|
Insights |
Insights |
Galaxy |
galaxy.ansible.com、cloud.redhat.com |
オンプレミスオートメーションハブ |
左のナビゲーションバーから 認証情報タイプ アイコンをクリックして認証情報にアクセスします。カスタムの認証情報タイプが作成されていない場合には、認証情報タイプのビューには何も表示されず、1 つ追加するように求められます。
認証情報タイプが作成されていると、このページには、既存および利用可能な認証情報タイプの一覧が表示されます。
認証情報タイプについての詳細を表示するには、その名前をクリックするか、または アクション 列の編集 () ボタンをクリックします。
認証情報タイプについては、それぞれの独自の設定が 入力の設定 フィールドおよび インジェクターの設定 フィールドに表示されます (該当する場合)。YAML および JSON 形式はどちらも設定フィールドでサポートされます。
新規の認証情報タイプを作成するには、以下を実行します。
認証情報タイプ 画面で 追加 ボタンをクリックします。
名前 および 説明 フィールドに詳細を入力します。
注釈
カスタムの認証タイプには無効であるため、認証タイプを新規作成する際には、INPUT 名、INJECTOR 名および ID に、ANSIBLE_
で始まる予約済変数名を使用しないでください。
入力の設定 フィールドで、該当タイプの順序付けられたフィールドのセットを定義する入力スキーマを指定します。以下のように YAML または JSON 形式を使用できます。
YAML
fields: - type: string id: username label: Username - type: string id: password label: Password secret: true required: - username - passwordYAML の他のサンプルについては http://www.yaml.org/start.html を参照してください。
JSON
{ "fields": [ { "type": "string", "id": "username", "label": "Username" }, { "secret": true, "type": "string", "id": "password", "label": "Password" } ], "required": ["username", "password"] }JSON の他のサンプルについては、www.json.org を参照してください。
以下の JSON 形式の設定は、それぞれのフィールドとそれらが使用される方法を示しています。
{ "fields": [{ "id": "api_token", # required - a unique name used to # reference the field value "label": "API Token", # required - a unique label for the # field "help_text": "User-facing short text describing the field.", "type": ("string" | "boolean") # defaults to 'string' "choices": ["A", "B", "C"] # (only applicable to `type=string`) "format": "ssh_private_key" # optional, can be used to enforce data # format validity for SSH private key # data (only applicable to `type=string`) "secret": true, # if true, the field value will be encrypted "multiline": false # if true, the field should be rendered # as multi-line for input entry # (only applicable to `type=string`) },{ # field 2... },{ # field 3... }], "required": ["api_token"] # optional; one or more fields can be marked as required },
type=string
の場合に、オプションで複数の選択オプションからフィールドを指定できます。
{ "fields": [{ "id": "api_token", # required - a unique name used to reference the field value "label": "API Token", # required - a unique label for the field "type": "string", "choices": ["A", "B", "C"] }] },
インジェクターの設定 フィールドでは、認証情報タイプが挿入できる値を指定する環境変数または追加変数を入力します。YAML または JSON 形式を使用できます (直前の手順のサンプルを参照してください)。以下の JSON 形式の設定は、それぞれのフィールドとそれらが使用される方法を示しています。
{
"file": {
"template": "[mycloud]\ntoken={{ api_token }}"
},
"env": {
"THIRD_PARTY_CLOUD_API_TOKEN": "{{ api_token }}"
},
"extra_vars": {
"some_extra_var": "{{ username }}:{{ password }}"
}
}
認証情報タイプは、.ini ファイルまたは証明書/キーデータをサポートする一時ファイルも生成します。
{
"file": {
"template": "[mycloud]\ntoken={{ api_token }}"
},
"env": {
"MY_CLOUD_INI_FILE": "{{ tower.filename }}"
}
}
この例では、automation controller は以下を含む一時ファイルを作成します。
[mycloud]\ntoken=SOME_TOKEN_VALUE
生成されるファイルへの絶対ファイルパスは、MY_CLOUD_INI_FILE
という名前の環境変数に保存されます。
カスタムの認証情報テンプレートで複数のファイルを参照する例は、以下のとおりです。
インプット
{
"fields": [{
"id": "cert",
"label": "Certificate",
"type": "string"
},{
"id": "key",
"label": "Key",
"type": "string"
}]
}
インジェクター
{
"file": {
"template.cert_file": "[mycert]\n{{ cert }}",
"template.key_file": "[mykey]\n{{ key }}"
},
"env": {
"MY_CERT_INI_FILE": "{{ tower.filename.cert_file }}",
"MY_KEY_INI_FILE": "{{ tower.filename.key_file }}"
}
}
完了したら 保存 をクリックします。
画面下部までスクロールします。新規に作成された認証情報タイプが認証情報タイプの一覧に表示されます。
をクリックして変更するか、「アクション」列にある認証タイプのオプションを削除します。
注釈
編集画面では、詳細の変更や認証情報の削除を行うことができます。削除 ボタンがグレーアウトしている場合は、その認証情報タイプがある認証情報で使用されていることを示しており、削除する前にその認証情報タイプを使用しているすべての認証情報から認証情報タイプを削除する必要があります。以下に、このようなメッセージの例を示します。
新規の認証情報の作成時に、新規に作成された認証情報タイプを 認証情報タイプ 選択ウィンドウから選択できることを確認します。
新規の認証情報の作成方法について詳しくは、認証情報 を参照してください。