Documentation

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

スーパーユーザー権限を持つ Tower 管理者の場合、YAML/JSON などの定義を使用し、標準形式でカスタム認証情報タイプを定義し、新規の認証情報タイプをジョブやインベントリー更新に割り当てることができます。これにより、既存の認証情報タイプと同様の仕方で機能するカスタム認証情報タイプを定義することができます。たとえば、サードパーティー web サービスの API トークンを環境変数に挿入し、Playbook やカスタムインベントリースクリプトが使用できるカスタム認証情報タイプを作成できます。

カスタム認証情報は、認証情報を挿入する以下の方法をサポートします。

  • 環境変数
  • Ansible の追加変数
  • ファイルベースのテンプレート (認証情報の値が含まれる .ini または .conf ファイルの生成など)

ジョブテンプレートには、1 つの SSH と複数のクラウド認証情報を割り当てることができます。クラウド認証情報はそれぞれ異なるタイプである必要があります。つまり、1 つの AWS 認証情報、1 つの GCE 認証情報など、それぞれ 1 つずつのみ使用できます。Ansible Tower 3.2 以降より、Vault 認証情報とマシンの認証情報は別々のエンティティーになっています。

注釈

新規の認証タイプを作成する際には、extra_varsenv およびファイル名前空間での競合を回避する必要があります。また、ANSIBLE_ で開始する環境変数名と追加の変数名は予約されているため、この名前は使用しないようにします。認証タイプ (CredentialType) を作成および変更し、CredentialType.injection フィールドを表示するには、スーパーユーザーのパーミッションが必要です。

11.1. 後方互換 API の留意事項

Ansible Tower version 3.2 における API バージョン 2 (V2) の新規サポートは以下を意味します。

  • ジョブテンプレートと認証情報の一対多のリレーションシップ (マルチクラウドサポートを含む)
  • カスタム認証情報は V1 API で管理されない。ユーザーがカスタム認証情報タイプを定義する場合、その認証情報は V1 API には表示されない。
  • V1 認証情報 API への Post は移行済みの CredentialTypes/認証情報と透過的に連動する。

認証情報には、以下を定める「種類」という概念があります。

  • 認証情報が使用される方法または 場所
  • ジョブテンプレートには、1 つの SSH と複数のクラウド認証情報を割り当てることができます。クラウド認証情報はそれぞれ異なるタイプである必要があります。つまり、1 つの AWS 認証情報、1 つの GCE 認証情報など、それぞれ 1 つずつのみ使用できます。

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

マシン SSH
Vault Vault
ネットワーク 環境変数の設定 (例: ANSIBLE_NET_AUTHORIZE)
SCM ソースコントロール
クラウド EC2、AWS
  その他多数
Insights Insights

カスタムタイプの作成と変更は、クラウドとネットワークの種類に制限されています。

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

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

Credential Types - home empty

認証情報タイプが作成されている場合、このページには、既存および利用可能な認証情報タイプの一覧が表示されます。さらに、名前 および 種類 で並び替え、検索することができます。

Credential Types - home with example credential types

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

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

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

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

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

Create new credential type

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

注釈

カスタムの認証タイプには無効であるため、認証タイプを新規作成する際には、INPUT 名、INJECTOR 名および ID に、ANSIBLE_ で始まる予約済変数名を使用しないでください。

  1. 入力の設定 フィールドで、該当タイプの順序付けられたフィールドのセットを定義する入力スキーマを指定します。以下のように 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"]
  }]
},
  1. インジェクターの設定 フィールドでは、認証情報タイプが挿入できる値を指定する環境変数または追加変数を入力します。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 }}"
  }
}
  1. 完了したら 保存 をクリックします。
  2. 画面下部までスクロールします。新規に作成された認証情報タイプが認証情報タイプの一覧に表示されます。

New credential type

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

注釈

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

_images/credential-types-delete-confirmation.png
  1. 新規の認証情報の作成時に、新規に作成された認証情報タイプを 認証情報タイプ 選択ウィンドウから選択できることを確認します。

Verify new credential type

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