21. セキュリティー¶

以下のセクションでは、Ansible Tower がファイルシステムのセキュリティーに対応し、これらを制御する方法について説明します。

すべての Playbook は awx ファイルシステムユーザーによって実行されます。実行中のジョブについては、Ansible Tower は Linux の名前空間の指定および chroot でジョブの分離が可能になるようにデフォルト設定されます。この保護機能により、ジョブは、該当するジョブテンプレートのプロジェクトディレクトリーや /opt などの共通のロケーションからのみ Playbook およびロールにアクセスできます。Playbook は、デフォルトでは他のプロジェクトからロール、Playbook またはデータにアクセスすることはできません。

この保護機能を無効にする必要がある場合 (ただし、これは推奨されません)、/etc/tower/settings.py を編集し、AWX_PROOT_ENABLED を False に設定します。

注釈

このシナリオでは、Playbook はファイルシステムおよびそれによって示されるすべてのものへのアクセスがあります。そのため、Playbook を編集できるアクセス権を持つユーザーは信頼されるユーザーである 必要があります。

認証情報のセキュリティーの場合、ユーザーはロックされた SSH キーをアップロードし、パスワードのロック解除を「ask」に設定する選択ができます。また、システムに SSH 認証情報をデータベースに保存させるのではなく、システムから SSH 認証情報や sudo パスワードのプロンプトを出させるよう選択することもできます。

21.1. Playbook のアクセスおよび情報共有¶

デフォルトで、Tower のマルチテナントセキュリティーは、Playbook がプロジェクトディレクトリーの外部でファイルを読み込めないようにします。古いバージョンの Ansible Tower では、proot というシステムを使用して、tower ジョブプロセスを残りのシステムから分離していました。Tower バージョン 3.1 以降についえは、bubblewrap がその軽量さやメンテナンスされているプロセス分離システムを理由として代わりに使用されています。

bubblewrap はデフォルトで有効にされていますが、Tower ユーザーインターフェースの「Configure Tower (Tower の設定)」画面または tower 設定ファイルからオフにすることができます。

_images/ug-configure-tower-jobs-process-isolation.png

「Configure Tower (Tower の設定)」画面にアクセスするには、 Tower の設定セクションを参照してください。設定ファイルで bubblewrap 設定をカスタマイズするには、 /etc/tower/settings.py ファイルに移動します。

プロセスの分離は、(有効にされている場合は) 以下のジョブタイプに使用されます。

ジョブテンプレート: 通常のジョブテンプレートからのジョブの起動
アドホックコマンド: インベントリー内の 1 つ以上のホストに対するアドホックコマンドの起動

デフォルトで、プロセスの分離により、以下のディレクトリーが上記のタスクから非表示にされます。

/etc/tower: Tower 設定の公開を防ぐ。
/var/lib/awx: 使用されている現在のプロジェクトを除く (通常のジョブテンプレートの場合)
/var/log
/tmp (またはその他のすべての system temp ディレクトリー): プロセス自体の一時ファイルを除く。

「Configure Tower (Tower の設定)」画面または設定ファイルを使用して、Playbook の実行時に非表示にするか、または公開する内容をカスタマイズできます。詳細は、次のセクションの Bubblewrap 機能および変数を参照してください。

21.1.1. Bubblewrap 機能および変数¶

Ansible Tower の bubblewrap 機能により、Tower ファイルシステムのどのディレクトリーが Playbook に表示され、また Playbook の実行時に使用できるかを制限します。場合によっては bubblewrap 設定をカスタマイズする必要がある場合もあります。bubblewrap の使用を微調整するために、いくつかの変数を設定することができます。

bubblewrap サポートの無効化:

bubblewrap がジョブの実行をサポートしないように無効化するには (Playbook の実行のみ)、管理ユーザーとしてログインしていることを確認し、右上隅にある設定の歯車アイコンをクリックしてください。「Configure Tower (Tower の設定)」ボックスをクリックしてから、「ジョブ」のタブをクリックします。「ジョブの分離の有効化」まで下方向にスクロールして、ラジオボタンの選択肢を「Off」に切り替えます。

bubblewrap サポートの有効化:

bubblewrap がジョブの実行をサポートしないように有効化するには (Playbook の実行のみ)、管理ユーザーとしてログインしていることを確認し、右上隅にある設定の歯車アイコンをクリックしてください。「Configure Tower (Tower の設定)」ボックスをクリックしてから、「ジョブ」のタブをクリックします。「ジョブの分離の有効化」まで下方向にスクロールして、ラジオボタンの選択肢を「On」に切り替えます。

デフォルトでは、Tower はシステムの tmp ディレクトリー (デフォルトは /tmp) をステージング領域として使用します。これは、「Configure Tower (Tower の設定)」画面の Job Isolation Execution Path (ジョブの分離実行パス) フィールドからか、または設定ファイルで以下のエントリーを更新して変更できます。

AWX_PROOT_BASE_PATH = "/opt/tmp"

システム上に機密で非表示にすべきその他の情報がある場合には、「Configure Tower (Tower の設定)」画面の 分離されたジョブの非表示にするパス で指定するか、または設定ファイルで以下のエントリーを更新して指定することができます。

AWX_PROOT_HIDE_PATHS = ['/list/of/', '/paths']

とくに公開する必要のあるディレクトリーがある場合には、「Configure Tower (Tower の設定)」画面の 分離されたジョブの公開するパス に指定するか、または設定ファイルで以下のエントリーを更新して指定することができます。

AWX_PROOT_SHOW_PATHS = ['/list/of/', '/paths']

注釈

Playbook が /var/lib/awx/.ssh で定義された鍵や設定を使用する必要がある場合には、/var/lib/awx/.ssh を主要ファイルとして、AWX_PROOT_SHOW_PATHS に追加してください。

設定ファイルに変更を加えた場合には、変更の保存後に ansible-tower-service restart コマンドを使用してサービスを再起動するようにしてください。

21.2. ロールベースのアクセス制御¶

ロールベースのアクセス制御 (RBAC) は Tower に組み込まれ、Tower 管理者はアクセスをサーバーインベントリー、組織などに委任できます。管理者は各種の認証情報の管理を一元化することもでき、シークレットをエンドユーザーに公開せずに、エンドユーザーが必要なシークレットを使用できるようにします。RBAC の制御により、Tower ではセキュリティーを強化し、管理をスリム化することができます。

RBAC は、特定の機能が設定されている「オブジェクト」の表示、変更、または削除を実行するユーザーまたは機能を定義するロールという点から最も簡単に説明できる機能です。Ansible Tower バージョン 3.0 より前のリリースでは、RBAC はユーザーやチームにパーミッションを付与するものとして理解されていました。Tower 3.0 より、RBAC はロールをユーザーやチームに付与するものとして理解されるようになり、アプローチがより直観的になりました。

Tower における RBAC のデザインについては、ロール、リソースおよびユーザーなどの理解しておく必要のあるいくつかの主要な概念があります。ユーザーはロールのメンバーにすることができ、これにより、ロールに関連付けられたリソースや、「子孫」のロールに関連付けられるリソースへの特定のアクセスが付与されます。

基本的に、ロールは各種機能のコレクションです。ユーザーにはそれらの機能と Tower のリソースへのアクセスが、それらが割り当てられたロールやロールの階層で継承されたロールを介して付与されます。

ロールは機能のグループをユーザーのグループに関連付けます。すべての機能はロール内のメンバーシップから派生します。ユーザーは、それらが割り当てられたロールやロールの階層で継承するロールによってのみ各種機能を受信します。ロールのすべてのメンバーは、そのロールに付与されたすべての機能を持ちます。組織内でユーザーや機能の場合は数が多く、すぐに変更される可能性がありますが、ロールには比較的安定性があります。ユーザーは数多くのロールを持つことができます。

21.2.1. ロールの階層およびアクセスの継承¶

「SomeCompany」という名前の組織があり、「Josie」と「Carter」という 2 人の人に、その組織に関連付けられたすべての設定を管理できるアクセス権を付与する必要があるとします。これらの人々を組織の admin_role のメンバーにする必要があります。

user-role-relationship

システムには多くのロールがありますが、一部のロールに他のロールのすべての機能を組み込む必要があることがよくあります。たとえば、システム管理者に対して、組織管理者がアクセスできるすべてに対するアクセスや、プロジェクト管理者がアクセスできるすべてにアクセスできるようにする必要があるかもしれません。

この概念は「ロールの階層」と呼ばれています。

親ロールは、子ロールに付与するすべての機能を取得します。
ロールのメンバーは、それらがメンバーであるロールと子ロールのすべての機能を自動的に取得します。

ロールの階層は、ロールに「親ロール」を持たせることによって表されます。ロールが持つすべての機能は親ロール (またはそれらの親の親など) に暗黙的に付与されます。

rbac-role-hierarchy

システムには多くのロールがありますが、一部のロールに他のロールのすべての機能を組み込む必要のあることがよくあります。たとえば、システム管理者に対して、組織管理者がアクセスできるすべてに対するアクセスや、プロジェクト管理者がアクセスできるすべてにアクセスできるようにする必要があるかもしれません。この概念は「ロールの階層」と呼ばれており、これはロールに「親ロール」を持たせることによって表されます。ロールが持つすべての機能は親ロール (またはそれらの親の親など) に暗黙的に付与されます。当然のことながら、ロールには複数の親を持たせることができ、機能はすべての親に暗黙的に付与されます。

rbac-heirarchy-morecomplex

RBAC の制御により、ユーザーおよびユーザーのチームに対して、特定のホストセットに対して Playbook を実行することを明示的に許可する機能も利用できます。ユーザーおよびチームは、機能が付与された Playbook のセットやホストにのみ制限されます。また Tower では、必要なだけユーザーやチームを作成したり、インポートしたりできます。ユーザーやチームは手動で作成したり、それらを LDAP または Active Directory からインポートしたりできます。

RBAC は、特定の機能が設定されている「オブジェクト」の表示、変更、または削除を実行するユーザーまたは機能という点から最も簡単に説明できる機能です。

21.2.2. RBAC の適用¶

以下のセクションでは、Tower の RBAC システムを環境に適用する方法について説明します。

21.2.2.1. ユーザーの編集¶

ユーザーの編集時に、Tower システム管理者はユーザーを システム管理者 (スーパーユーザーとも呼ばれる) または システム監査者 として指定することができます。

システム管理者は、Tower 環境内のすべてのオブジェクトのすべての機能 (読み取り/書き込み/実行) を暗黙的に継承します。
システム監査者は、Tower 環境内のすべてのオブジェクトの読み取り専用機能を暗黙的に継承します。

21.2.2.2. 組織の編集¶

組織の編集時に、システム管理者は以下のロールを指定することができます。

組織管理者としての 1 ユーザー以上のユーザー
組織監査者としての 1 ユーザー以上のユーザー
および組織のメンバーとしての 1 ユーザー以上のユーザー

組織のメンバーであるユーザー/チームは組織管理者を表示することができます。

組織管理者であるユーザーは、Tower 組織内のすべてのオブジェクトのすべての機能を暗黙的に継承します。

組織監査者であるユーザーは、Tower 組織内のすべてのオブジェクトの読み取り専用機能を暗黙的に継承します。

21.2.2.3. 組織でのプロジェクトの編集¶

管理者となっている組織のプロジェクトの編集時に、組織管理者および組織管理者は以下を指定できます。

プロジェクト管理者である 1 以上のユーザー/チーム
プロジェクトメンバーである 1 以上のユーザー/チーム
組織のメンバーであるユーザー/チーム内の、SCM からプロジェクトを更新できる 1 以上のユーザー/チーム。

プロジェクトのメンバーであるユーザーはプロジェクト管理者を表示できます。

プロジェクト管理者は、SCM からプロジェクトを更新する機能を暗黙的に継承します。

管理者は、ジョブテンプレートでプロジェクトを使用できる 1 以上のユーザー/チームを (プロジェクトのメンバーから) 指定することもできます。

21.2.2.4. 組織内でのインベントリーおよび認証情報の作成¶

認証情報を使用し、読み取り、書き込むために付与されるすべてのアクセス権はロールで処理されます。認証用に「チーム」または「ユーザー」を設定する必要はありません。代わりに、Tower の RBAC システムを使用して、所有権、監査者、用途別のロールなどを割り当てます。

システム管理者および組織管理者は、管理機能に基づいて、組織内にインベントリーや認証情報を作成することができます。

インベントリーまたは認証情報の編集のどちらの場合でも、システム管理者および組織管理者は、インベントリーまたは認証情報の使用機能を付与するために、(組織のメンバーから) 1 以上のユーザー/チームを指定することができます。

システム管理者および組織管理者は、インベントリーを (動的または手動で) 更新する機能を付与するために、(組織のメンバーから) 1 以上のユーザー/チームを指定することができます。

21.2.2.5. ジョブテンプレートの編集¶

システム管理者、組織管理者およびプロジェクト管理者は、管理機能に基づき、プロジェクト内でプロジェクトの新規ジョブテンプレートを作成したり、変更したりすることができます。

ジョブテンプレートの編集時に、管理者 (Tower、組織、およびプロジェクト) は使用機能を持つ組織内のインベントリーおよび認証情報を選択したり、実行時に選択されるようにそれらのフィールドを空白にしたりすることができます。

さらに、それらジョブテンプレートの実行機能を持つ 1 つ以上のユーザー/チームを (プロジェクトのメンバーから) 指定することもできます。実行機能は、ジョブテンプレートに指定されるインベントリーまたは認証情報に基づいてユーザー/チームに付与される明示的な機能の有無にかかわらず有効になります。

21.2.2.6. ユーザービュー¶

ユーザーは以下を実行できます。

それらのユーザーがメンバーとなっている組織またはプロジェクトの確認
それらのユーザーに属する認証情報オブジェクトの作成
実行機能が付与されたジョブテンプレートの表示および実行

ユーザーに実行権限が与えられているジョブテンプレートにイベントリーまたは認証情報が指定されない場合は、そのユーザーが所有するか、または使用機能が付与されている組織内のインベントリーや認証情報を選択することを求めるプロンプトが実行時に出されます。

ジョブテンプレート管理者のユーザーはジョブテンプレートに変更を加えることができますが、ジョブテンプレートで使用するインベントリー、プロジェクト、Playbook、認証情報を変更するには、対象のプロジェクト、インベントリー、使用中または設定中の認証情報すべてに対する「使用」ロールも必要になります。

21.2.3. ロール¶

本書で前述したように、認証情報を使用し、読み取り、書き込むために付与されるすべてのアクセス権はロールで処理されるようになり、ロールはリソースについて定義されます。

21.2.3.1. 組み込みロール¶

以下の表では、RBAC システムのロールと、ロールが Tower の権限に関連して定義される方法についての簡単な説明を示しています。

システムロール	実行できる内容
システム管理者: システム全体のシングルトンロール (単一の管理者)	システムのすべての側面を管理します。
システム監査者: システム全体のシングルトンロール (単一の監査者)	システムのすべての側面を閲覧できます。
アドホックロール: インベントリー	インベントリーでアドホックコマンドを実行します。
管理者ロール: 組織、チーム、インベントリー、プロジェクト、ジョブテンプレート	定義された組織、チーム、インベントリー、プロジェクトまたはジョブテンプレートのすべての側面を管理します。
監査者ロール: 組織	定義された組織、プロジェクト、インベントリー、またはジョブテンプレートのすべての側面を表示します。
実行ロール: ジョブテンプレート	割り当てられたジョブテンプレートを実行します。
メンバーロール: 組織、チーム	ユーザーは定義された組織またはチームのメンバーです。
読み取りロール: 組織、チーム、インベントリー、プロジェクト、ジョブテンプレート	定義された組織、チーム、インベントリー、プロジェクトまたはジョブテンプレートのすべての側面を閲覧できます。
更新ロール: プロジェクト	設定されたソースコントロール管理システムからプロジェクトを更新します。
更新ロール: インベントリー	クラウドソース更新システムを使用してインベントリーを更新します。
所有者ロール: 認証情報	この認証情報のすべての側面を所有し、管理します。
ユーザーロール: 認証情報、インベントリー、プロジェクト	認証情報、インベントリー、またはプロジェクトをジョブテンプレートで使用します。

単一のロールは、システム全体でパーミッションを付与する特殊なロールです。現在、Ansible Tower は 2 つの組み込みシングルトンロール (単一ロール)を提供していますが、シングルトンロール (単一ロール) の作成またはカスタマイズ機能は現時点ではサポートされません。

21.2.3.2. 一般的なチームロール: “役割”¶

Tower サポート担当者は、通常、Tower が利用でき、サポートの容易性とユーザーの使いやすさのバランスが取れるような管理を選択します。しばしば、Ansible Tower サポートは、ユーザーに「組織所有者/管理者」を割り当てて、新しい組織を作成し、チームのメンバーに必要なアクセスを追加します。これにより、個々の対応を最低限に抑え、代わりにサービスのアップタイムを維持し、Ansible Tower を使用するユーザーを支援することに時間をかけられます。

以下は、Tower の組織が管理する一般的なロールの一部です。

System Role (For Organizations)	Common User Roles	説明
所有者	Team Lead - Technical Lead	This user has the ability to control access for other users in their organization.They can add/remove and grant users specific access to projects, inventories, and job templates.This user also has the ability to create/remove/modify any aspect of an organization’s projects,templates, inventories, teams, and credentials.
監査者	Security Engineer - Project Manager	This account can view all aspects of the organization in read-only mode. This may be good for a user who checks in and maintains compliance.This might also be a good role for a service account who manages or ships job data from Ansible Tower to some other data collector.
Member - Team	その他のすべてのユーザー	These users by default as an organization member do not receive any access to any aspect of the organization. In order to grant them access the respective organization owner needs to add them to their respective team and grant them Admin, Execute, Use, Update, Ad-hoc permissions to each component of the organization’s projects, inventories, and job templates.
Member - Team “Owner”	Power users - Lead Developer	Organization Owners can provide “admin” through the team interface, over any component of their organization including projects, inventories, and job templates. These users are able to modify and utilize the respective component given access.
Member - Team “Execute”	Developers - Engineers	This will be the most common and allows the organization member the ability to execute job templates and read permission to the specific components. This is permission applies to templates.
Member - Team “Use”	Developers - Engineers	This permission applies to an organization’s credentials, inventories, and projects.This permission allows the ability for a user to the respective component within their job template.
Member - Team “Update”	Developers - Engineers	このパーミッションをプロジェクトに適用します。ユーザーが、プロジェクトで SCM の更新を実行できるようにします。

21.2.3.3. Tower チームガバナンス¶

以下は、各ロールと、各ロールがアクセスできるリソースを示します。