Documentation

10. 認証情報

認証情報は、ジョブをマシンに対して起動したり、インベントリーソースと同期したり、プロジェクトのコンテンツをバージョン管理システムからインポートしたりする際の認証に使用されます。

Tower の認証情報は Tower でインポートされ、保管され、暗号化され、ユーザーはコマンドラインのプレーンテキストで取得することはできません。パスワードまたはキーが Tower インターフェースに入力されると、それは暗号化され、Tower データベースに入力され、その後は Tower から取得できなくなります。ユーザーやチームには、ユーザーに認証情報を公開せずにこれらの認証情報を使用する権限を割り当てることができます。ユーザーを別のチームに移動したり、組織から削除する際には、認証情報が Tower で利用できたという理由だけですべてのシステムのキーを更新する必要はありません。

注釈

Tower は Tower データベースでパスワードおよびキー情報を暗号化しますが、機密情報が API で表示されることはありません。

10.1. 認証情報の機能について

Ansible Tower は SSH を使用してリモートホスト (または Windows と同等のホスト) に接続します。Tower から SSH にキーを渡すには、キーの暗号を解除してからキーが名前付きパイプに書き込まれるようにする必要があります。Tower はそのパイプを使用してキーを SSH に送信します (これにより、キーがディスクに書き込まれることはない)。

パスワードが使用されている場合、Ansible Tower はパスワードのプロンプトに直接応答し、パスワードの暗号を解除してプロンプトに書き込むことによってそれらを処理します。

暗号/暗号解除アルゴリズムは、ブロック暗号としての AES-128 の操作モードの ECB (Electronic Code Book) を使用します。128 ビット AES キーは SECRET_KEY から派生します (awx 設定を参照)。Tower の特定の機密のモデルフィールドは暗号化されており、以下が含まれます。

Credential: password, ssh_key_data, ssh_key_unlock, become_password, vault_password
UnifiedJob: start_args

データは暗号化されてからデータベースに保存され、必要に応じて Tower で暗号化の解除が行われます。暗号化/暗号解除プロセスでは、AES 128 ビット暗号化キーが <SECRET_KEY, field_name, primary_key> から派生します。ここで field_name はモデルフィールドの名前であり、primary_key はデータベースで割り当てられる自動増分するレコード ID です。キー生成プロセスで使用される属性が変更される場合、Tower はシークレット暗号の解除を正常に実行できません。

注釈

Ansible Tower の暗号化および暗号化解除のルールは、認証情報外の 1 つのフィールドである統合ジョブの start_args フィールドにも適用されます。これは、jobad_hoc_command、および system_job データタイプで使用されるものです。

10.2. 認証情報の使用開始

設定 (settings) ボタンからアクセスできる 認証情報 リンクには、利用可能なすべての認証情報の一覧が表示されます。これは、名前説明タイプ、または 所有者 で並び替え、検索できます。

Credentials - home with example credentials

チームに追加された認証情報は、チームのすべてのメンバーが使用できるようになります。ただし、ユーザーに追加される認証情報は、デフォルトではその特定ユーザーのみが使用できます。

使用を開始するには、作成済みのデモの認証情報を使用できます。

Demo Credential のリンクをクリックすると、この認証情報の 詳細 ビューに移動します。

Credentials - home with demo credential details

パーミッション をクリックすると、この認証情報および付与されたロール (所有者、管理者、監査者など) に関連付けられたユーザーおよびチームが表示されます。

Credentials - home with permissions credential details

add ボタンをクリックし、この Demo Credential を追加のユーザーまたはチームに割り当てます。

10.3. 新規認証情報の追加

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

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

Create credential

  1. 以下のセクションで説明される認証情報のタイプに応じて、適切な詳細を入力します。
  2. 完了したら 保存 をクリックします。

10.4. 認証情報タイプ

10.4.1. マシン

マシンの認証情報により、Tower は管理対象のホストで Ansible を起動できます。コマンドラインで Ansible を使用するように、SSH ユーザー名を指定し、オプションでパスワードや SSH キー、キーのパスワードを指定したり、Tower からデプロイメント時にユーザーのパスワード入力を求めるプロンプトを出したりすることができます。それらは ssh および Playbook のユーザーレベルの権限昇格のアクセスを定義し、リモートホストで Playbook を実行するためにジョブを送信する際に使用されます。

Credentials - create manual credential

マシンの認証情報には、設定可能ないくつかの属性があります。

  • ユーザー名: SSH 認証に使用されるユーザー名。

  • パスワード: SSH 認証に使用される実際のパスワード。このパスワードは、入力されている場合は Tower データベースに暗号化された状態で保存できます。または 実行時に確認しますか? を選択することで、必要な場合ユーザーにパスワードの入力を求めるよう Tower を設定できます。これらの場合、ジョブの起動時にダイアログが開き、ユーザーにパスワードの入力とパスワードの確認を求めるプロンプトが出されます。

  • 秘密鍵のパスフレーズ: SSH 秘密鍵がパスワードで保護される場合、秘密鍵の鍵パスワードを設定できます。このパスワードは、入力されている場合 Tower データベースに暗号化された状態で保存できます。または 実行時に確認しますか? を選択することで、必要な場合ユーザーにパスワードの入力を求めるよう Tower を設定できます。これらの場合、ジョブの起動時にダイアログが開き、ユーザーにパスワードの入力とパスワードの確認を求めるプロンプトが出されます。

  • 権限昇格: 特定のユーザーに割り当てる権限昇格のタイプを指定します。これは、--become-method=BECOME_METHOD パラメーターを指定することに相当します。ここで、BECOME_METHODsudo | su | pbrun | pfexec | dzdo | pmrun にすることができます。

    • none: この認証情報に権限昇格を割り当てません。
    • sudo: スーパーユーザー (root ユーザー) の権限で単一コマンドを実行します。
    • su: スーパーユーザー (root ユーザー) アカウント (または他のユーザーアカウント) に切り替えます。
    • pbrun: アプリケーションまたはコマンドが制御されたアカウントで実行されるように要求し、詳細の root 権限の委譲およびキーのロギングを可能にします。
    • pfexec: 特定のユーザーまたはグループ ID などの事前に定義されたプロセス属性を使用してコマンドを実行します。
    • DZDO: RBAC 情報を Centrify の Active Directory サービスで使用する sudo の拡張バージョンです (Centrify の DZDO についてのサイト を参照してください)。
    • pmrun: アプリケーションが制御されたアカウントで実行されるように要求します (Privilege Manager for Unix 6.0 を参照してください)。

    Credentials - create manual credential priv escalation

  • 権限昇格のユーザー名 フィールドは、権限昇格のオプションが選択されている場合にのみ表示されます。リモートシステムで権限昇格で使用するユーザー名を入力します。

  • 権限昇格のパスワード: フィールドは、権限昇格のオプションが選択されている場合にのみ表示されます。リモートシステムでの選択した権限昇格タイプでユーザーを認証するために使用される実際のパスワードを入力します。このパスワードは、入力されている場合に Tower データベースに暗号化された状態で保存できます。または 実行時に確認しますか? を選択することで、必要な場合ユーザーにパスワードの入力を求めるよう Tower を設定できます。これらの場合、ジョブの起動時にダイアログが開き、ユーザーにパスワードの入力とパスワードの確認を求めるプロンプトが出されます。

    注釈

    Tower は sudo を起動して sudo ユーザーに切り換える前にホストとの認証された SSH 接続を確立する必要があるため、Sudo パスワードは SSH パスワードまたは SSH 秘密鍵と併用する必要があります。

  • Vault パスワード: Playbook が Ansible Vault を使用する場合、Vault パスワードをここの認証情報に追加します。または、実行時に確認しますか? を選択し、必要な場合ユーザーに Vault パスワードの入力を求めるよう Tower を設定できます。これらの場合、ジョブの起動時にダイアログが開き、ユーザーにパスワードの入力とパスワードの確認を求めるプロンプトが出されます。

Ansible Vault の詳細は、http://docs.ansible.com/ansible/playbooks_vault.html を参照してください。

警告

スケジュール済みジョブ で使用される認証情報については 実行時に確認しますか? で設定することはできません。

10.4.2. ネットワーク

ネットワーク認証情報は、ネットワークデバイスへの接続およびその管理を実行するために Ansible ネットワークモジュールによって使用されます。

Credentials - create network credential

ネットワークの認証情報には、設定可能ないくつかの属性があります。

  • ユーザー名: ネットワークデバイスと併用するユーザー名。
  • パスワード: ネットワークデバイスと併用するパスワード。
  • 秘密鍵のパスフレーズ: ユーザーを SSH 経由でネットワークに対して認証するために使用する秘密鍵の実際のパスフレーズ。
  • 認証: これを選択して、パスワードで RSA 鍵に署名する 認証パスワード を追加します (認証パスワード フィールドは、このオプションが選択されている場合にのみ表示されます)。
  • SSH キー: ユーザーを SSH 経由でネットワークに対して認証するために使用される SSH 秘密鍵。

10.4.3. ソースコントロール

SCM (ソースコントロール) 認証情報は、ローカルソースコードのリポジトリーを、Git、Subversion、または Mercurial などのリモートのリビジョンコントロールシステムからクローン作成したり、更新したりするためにプロジェクトで使用されます。

Credentials - create SCM credential

ソースコントロールの認証情報には、設定可能ないくつかの属性があります。

  • ユーザー名: ソースコントロールシステムと併用するユーザー名。
  • パスワード: ソースコントロールシステムと併用するパスワード。
  • 秘密鍵のパスフレーズ: 使用される SSH 秘密鍵がパスフレーズで保護される場合、秘密鍵のパスフレーズを設定できます。
  • SCM 秘密鍵: ユーザーを SSH 経由でソースコントロールシステムに対して認証するために使用される実際の SSH 秘密鍵。

注釈

ソースコントロールの認証情報は 実行時に確認しますか? を使用して設定することはできません。

10.4.4. Amazon Web Services

この認証情報タイプを選択すると、クラウドインベントリーの Amazon Web Services との同期が可能になります。

Credentials - create AWS credential

従来の Amazon Web Services の認証情報は、AWS アクセスキー および 秘密鍵 で構成されています。

Ansible Tower バージョン 2.4.0 では、EC2 STS トークン (IAM STS 認証情報と呼ばれることもある) のサポートを導入しました。セキュリティートークンサービス (STS) は、AWS Identity and Access Management (IAM) ユーザーの一時的な、制限付き権限の認証情報を要求できる web サービスです。IAM/EC2 STS トークンの詳細は、http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html を参照してください。

AWS 認証情報は以下で構成されています。

AWS_ACCESS_KEY
AWS_SECRET_KEY
AWS_SECURITY_TOKEN

注釈

EC2 のタグの値にブール値 (yes/no/true/false) が含まれる場合、それらを引用符で囲む必要があります。

警告

暗黙的な IAM ロールの認証情報を使用するには、IAM ロールに依存して AWS API にアクセスする場合に AWS クラウド認証情報を Tower で割り当てることはできません。AWS クラウド認証情報をジョブテンプレートに割り当てるのが良いと思われる場合でも、それを実行すると AWS 認証情報の使用が強制的に実行され、IAM ロールの認証情報が無視されます (boto ライブラリーの使用による)。

10.4.5. Rackspace

この認証情報タイプを選択すると、クラウドインベントリーと Rackspace との同期が可能になります。

Credentials - create RAX credential

Rackspace 認証情報は、Rackspace ユーザー名 および API キー で構成されています。

注釈

Rackspace インベントリーの同期は Tower 3.1.0 で非推奨になっており、Rackspace のサポートは今後のリリースで削除されます。

10.4.6. VMware vCenter

この認証情報タイプを選択すると、インベントリーと VMware vCenter との同期が可能になります。

Credentials - create VMware credential

VMware の認証情報には、設定可能ないくつかの属性があります。

  • vCenter ホスト: 接続先の vCenter ホスト名または IP アドレス。
  • ユーザー名: vCenter への接続に使用するユーザー名。
  • パスワード: vCenter への接続に使用するパスワード。

注釈

VMware ゲストツールがインスタンスで実行されていない場合、VMware インベントリーの同期により、そのインスタンスの IP アドレスが返されない場合があります。

10.4.7. Red Hat Satellite 6

この認証情報タイプを選択すると、クラウドインベントリーと Red Hat Satellite 6 との同期が可能になります。

Credentials - create Red Hat Satellite 6 credential

Satellite の認証情報には、設定可能ないくつかの属性があります。

  • Satellite 6 URL: 接続先の Satellite 6 URL または IP アドレス。
  • ユーザー名: Satellite 6 への接続に使用するユーザー名。
  • パスワード: Satellite 6 への接続に使用するパスワード。

10.4.8. Red Hat CloudForms

この認証情報タイプを選択すると、クラウドインベントリーと Red Hat CloudForms との同期が可能になります。

Credentials - create Red Hat CloudForms credential

CloudForms の認証情報には、設定可能ないくつかの属性があります。

  • CloudForms URL: 接続先の CloudForms URL または IP アドレス。
  • ユーザー名: CloudForms への接続に使用するユーザー名。
  • パスワード: CloudForms への接続に使用するパスワード。

その他のリソース:

Red Hat CloudForms 4.1 での Ansible Tower 統合についての Red Hat の一連のブログ掲載を参照してください (http://cloudformsblog.redhat.com/2016/07/22/ansible-tower-in-cloudforms/)。

10.4.9. Google Compute Engine

この認証情報タイプを選択すると、クラウドインベントリーと Google Compute Engine との同期が可能になります。

Credentials - create GCE credential

Google Compute Engine の認証情報には、設定可能ないくつかの属性があります。

  • サービスアカウントのメールアドレス: Google Compute Engine サービスアカウント に割り当てられるメールアドレス。
  • プロジェクト: GCE によって割り当てられる識別情報です。これは、以下のように 2 語とそれに続く 3 桁の数字で構成されます (例: squeamish-ossifrage-123)。
  • RSA 秘密鍵: サービスアカウントメールに関連付けられる PEM ファイル。

10.4.10. Microsoft Azure Classic (非推奨)

この認証情報タイプを選択すると、クラウドインベントリーと Windows Azure Classic との同期が可能になります。

Credentials - create Azure Classic credential

Microsoft Azure の認証情報には、設定可能ないくつかの属性があります。

  • サブスクリプション ID: Microsoft Azure Classic アカウントのサブスクリプション UUID。
  • 管理証明書: Microsoft Azure Classic コンソールでアップロードした証明書に対応する PEM ファイル。

10.4.11. Microsoft Azure Resource Manager

この認証情報タイプを選択すると、クラウドインベントリーと Microsoft Azure Resource Manager との同期が可能になります。

Credentials - create Azure credential

Microsoft Azure Resource Manager の認証情報には、設定可能ないくつかの属性があります。

  • サブスクリプション ID: Microsoft Azure アカウントのサブスクリプション UUID。
  • ユーザー名: Microsoft Azure アカウントへの接続に使用するユーザー名。
  • パスワード: Microsoft Azure アカウントへの接続に使用するパスワード。
  • クライアント ID: Microsoft Azure アカウントのクライアント ID。
  • クライアントシークレット: Microsoft Azure アカウントのクライアントシークレット。
  • テナント ID: Microsoft Azure アカウントのテナント ID。

サービスプリンシパルの認証情報を渡すには、以下の変数を定義します。

AZURE_CLIENT_ID
AZURE_SECRET
AZURE_SUBSCRIPTION_ID
AZURE_TENANT

Active Directory のユーザー名/パスワードのペアを渡すには、以下の変数を定義します。

AZURE_AD_USER
AZURE_PASSWORD
AZURE_SUBSCRIPTION_ID

認証情報はパラメーターとして Playbook 内のタスクに渡すこともできます。優先される順序は、パラメーター、環境変数、および最後にホームディレクトリーにあるファイルになります。

認証情報をパラメーターとしてタスクに渡すには、サービスプリンシパルの認証情報についての以下のパラメーターを使用します。

client_id
secret
subscription_id
tenant

または Active Directory のユーザー名/パスワードについての以下のパラメーターを渡します。

ad_user
password
subscription_id

10.4.12. OpenStack

この認証情報タイプを選択すると、クラウドインベントリーと OpenStack との同期が可能になります。

Credentials - create OpenStack credential

OpenStack の認証情報には、設定可能ないくつかの属性があります。

  • ホスト (認証 URL): 認証に使用するホスト。
  • ユーザー名: OpenStack への接続に使用するユーザー名。
  • パスワード (API キー): OpenStack に接続するために使用するパスワードまたは API キー
  • プロジェクト (テナント名): OpenStack に使用されるテナント名またはテナント ID。通常、この値はユーザー名と同じです。
  • ドメイン名: OpenStack への接続に使用する FQDN。

OpenStack クラウド認証情報の使用を検討している場合は、サンプルの Playbook を含む詳細について、クラウド認証情報の利用 を参照してください。