11. カスタム認証情報タイプ¶

11.1. コレクションからのコンテンツ収集¶

3.8では、Tower は、kind=galaxy の新しい「Tower が管理する」認証情報タイプを導入しました。これは、プロジェクトの更新が実行した場合に、requirements.yml で定義されたコレクションをフェッチするためのコンテンツソース (galaxy.ansible.com、cloud.redhat.com、オンプレミスのオートメーションハブなど) を表します。この新しいタイプは、Ansible ドキュメントの Configuring the ansible-galaxy client で説明したように、プロジェクトの更新が ansible-galaxy collection install を実行する際に環境変数を構築するのに必要な URL と、(任意の) 認証の詳細を表します。これには、Ansible Galaxy CLI に公開されている構成オプションに直接マップするフィールドがあります (per-server など)。Tower APIのエンドポイントは、組織レベルでこれらの認証情報の順序付きリストを反映します。

/api/v2/organizations/N/galaxy_credentials/

Ansible Tower 3.8 をインストールすると、アップグレード後に適切な認証情報が作成され、Tower インストールのすべての組織に割り当てられるように、既存の Galaxy に合わせた設定値を移行します。3.8 へのアップグレード後、アップグレード前に存在していたすべての組織には、それに関連付けられた (1 つ以上の)「Galaxy」認証情報の一覧が含まれるようになりました。

また、アップグレード後、この設定は /api/v2/settings/jobs/ エンドポイントから表示 (または編集) できません。

galaxy.ansible.com は、その組織に対する一覧の最初の認証情報でなくても、Tower は引き続き公開 Galaxy からロールを直接フェッチする必要があります。グローバルの「Galaxy」設定はジョブレベルで設定されなくなりましたが、Tower ユーザーインターフェースの組織レベルで設定されるようになりました。組織の追加および編集ウィンドウには、kind=galaxy の認証情報に対して、任意の ** 認証情報** ルックアップフィールドがあります。

コンテンツの同期およびルックアップの優先順位は順序セットであるため、認証情報の順序を指定することが重要になります。詳細は「新しい組織の作成」を参照してください。コレクションを使用してプロジェクトを設定する方法の詳細は、「Tower でのコレクションの使用」を参照してください。

11.2. 後方互換 API の留意事項¶

API のバージョン 2 のサポート (api/v2/) は、ジョブテンプレートと認証情報 (マルチクラウドサポートを含む) の 1 対多の関係を意味します。認証情報は、v2 API を使用してフィルターを設定できます。

$ curl "https://tower.example.org/api/v2/credentials/?credential_type__namespace=aws"

V2 CredentialType モデルでは、リレーションシップは以下のように定義されます。

11.3. 認証情報タイプの使用開始¶

左のナビゲーションバーから認証情報タイプ () アイコンをクリックして認証情報にアクセスします。カスタムの認証情報タイプが作成されていない場合には、認証情報タイプのビューには何も表示されず、1 つ追加するようにプロンプトが表示されます。

認証情報タイプが作成されていると、このページには、既存および利用可能な認証情報タイプの一覧が表示されます。

認証情報タイプについての詳細を表示するには、その名前をクリックするか、または アクション 列の編集 () ボタンをクリックします。

認証情報タイプについては、それぞれの独自の設定が 入力の設定 フィールドおよび インジェクターの設定 フィールドに表示されます (該当する場合)。YAML および JSON 形式はどちらも設定フィールドでサポートされます。

11.4. 新規の認証情報タイプの作成¶

新規の認証情報タイプを作成するには、以下を実行します。

1. 認証情報タイプ 画面の右上にある ボタンをクリックします。

2. 名前 および 説明 フィールドに詳細を入力します。

3. 入力の設定 フィールドで、該当タイプの順序付けられたフィールドのセットを定義する入力スキーマを指定します。以下のように YAML または JSON 形式を使用できます。

YAML

fields:
  - type: string
    id: username
    label: Username
  - type: string
    id: password
    label: Password
    secret: true
required:
  - username
  - password

YAML の他のサンプルについては 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"]
  }]
},

4. インジェクターの設定 フィールドでは、認証情報タイプが挿入できる値を指定する環境変数または追加変数を入力します。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 }}"
  }
}

この例では、Tower は以下を含む一時ファイルを作成します。

[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 }}"
  }
}

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

6. 画面下部までスクロールします。新規に作成された認証情報タイプが認証情報タイプの一覧に表示されます。

をクリックして変更するか、または をクリックして「アクション」列にある認証タイプのオプションを削除します。

注釈

認証情報で使用した認証情報タイプを削除する場合は、使用する全認証情報から対象の認証情報タイプを削除してからでないと、削除できません。以下に、これらのメッセージ例を示します。

7. 新規の認証情報の作成時に、新規に作成された認証情報タイプを 認証情報タイプ 選択ウィンドウから選択できることを確認します。

新規の認証情報の作成方法について詳しくは、認証情報 を参照してください。