31. セキュリティー¶

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

すべての Playbook は、awx ファイルシステムのユーザー経由で実行されます。実行中のジョブについては、automation controller は、Linux コンテナーを使用してジョブの分離を行います。これにより、ジョブはそのジョブテンプレートの Project ディレクトリーにある Playbook、ロール、およびデータにのみアクセスできます。

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

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

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

RBAC は、特定の機能が設定されている「オブジェクト」を誰がまたは何が確認、変更、または削除できるかを正確に定義するロールの観点から考えるのが最も簡単です。RBAC は、ロールをユーザーまたはチームに付与する方法です。

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

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

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

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

31.2.2. RBAC の適用¶

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

31.2.2.1. ユーザーの編集¶

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

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

31.2.2.2. 組織の編集¶

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

組織管理者としての 1 ユーザー以上のユーザー
組織監査者としての 1 ユーザー以上のユーザー
組織メンバーとしての 1 ユーザー以上のユーザー (またはチーム)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31.2.2.6. ユーザービュー¶

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

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

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

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

31.2.3. ロール¶

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

31.2.3.1. 組み込みロール¶

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

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

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

31.2.3.2. 一般的なチームロール: "役割"¶

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

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

システムロール (組織用)	一般ユーザーロール	説明
所有者	チームリード - 技術リード	このユーザーは、組織内の他のユーザーのアクセスを制御できます。プロジェクト、インベントリー、ジョブテンプレートに、ユーザー固有のアクセスを追加、削除、付与できます。このユーザーは、組織のプロジェクト、テンプレート、インベントリー、チーム、認証情報を作成、削除、変更できます。
監査者	セキュリティーエンジニア - プロジェクトマネージャー	このアカウントは、組織のすべての側面を読み取り専用モードで表示できます。これは、コンプライアンスを確認し、維持するユーザーに割り当てるのが良いでしょう。さらには、ジョブデーターを管理し、 Ansible Tower から別のデータコレクターへ送るサービスアカウントのロールとしても良いでしょう。
メンバー - チーム	その他のすべてのユーザー	デフォルトで組織のメンバーとなるこれらのユーザーは、組織の側面へのアクセスを受け取りません。アクセスを付与するには、組織の各所有者が、各チームにユーザーを追加し、組織のプロジェクト、インベントリー、ジョブテンプレートの各コンポーネントへの Admin、Execute、Use、Update、Ad-hoc パーミッションを付与します。
メンバー - チーム “所有者”	パワーユーザー - 主な開発者	組織の所有者は、プロジェクト、インベントリー、ジョブテンプレートなどの組織のコンポーネントにあるチームインターフェースを介して “admin” を提供します。このユーザーは、各コンポーネントが指定したアクセスを修正して使用できます。
メンバー - チーム “管理者”	開発者 - エンジニア	これは最も一般的で、組織のメンバーが、ジョブテンプレートを実行し、特定のコンポーネントへのパーミッションを読み込むことができます。これは、テンプレートに適用されるパーミッションです。
メンバー - チーム “使用”	開発者 - エンジニア	このパーミッションは、組織の信用情報、インベントリー、プロジェクトに適用されます。このパーミッションにより、ユーザーは、ジョブテンプレート内の各コンポーネントへの機能が許可されます。
メンバー - チーム “更新”	開発者 - エンジニア	このパーミッションをプロジェクトに適用します。ユーザーが、プロジェクトで SCM の更新を実行できるようにします。

31.3. ロールの機能: 編集および作成¶

automation controller 3.3 では、ワークフローなど、特定のリソースタイプに固有の、組織の “リソースロール” 機能が新たに導入されました。このようなロールのメンバーになると、2 種類のパーミッションが通常割り当てられます。ワークフローの場合には、ユーザーは、組織 "Default" の "ワークフロー管理者ロール" が割り当てられます。

このユーザーは、組織 "Default" に新しいワークフローを作成できます。
ユーザーは "Default" 組織の全ワークフローを編集できます。

例外は、ジョブテンプレートで、このロールがあっても、作成パーミッションが割り当てられるわけではありません (詳細は専用のセクションに記載)。

31.3.1. リソースロールおよび組織のメンバーシップロールの独立性¶

リソース固有の組織ロールは、管理者やメンバーの組織ロールからは独立しています。"Default" 組織の "workflow admin role" が割り当てられていても、対象組織の全ユーザーを表示できませんが、"Default" 組織の "member" ロールが割り当てられている場合には、表示可能です。この 2 種類のロールは、それぞれ個別に委譲されます。

31.3.1.1. ジョブテンプレートの編集に必要なパーミッション¶

ジョブテンプレートの管理者ロールだけが割り当てられているユーザーは、ジョブ実行に影響がないフィールド (機密フィールドではない) の編集は可能ですが、ジョブテンプレートのジョブ実行に影響があるフィールドを編集するには、ユーザーには以下のロールが必要です。

ジョブテンプレートに対する 管理者 ロール
関連のプロジェクトに対する使用ロール
関連のインベントリーに対する使用ロール

"組織のジョブテンプレート管理者" ロールが導入されましたが、ジョブテンプレートが使用するプロジェクト/インベントリーへの使用ロールがない場合に、このロールだけでは、組織内のジョブテンプレートを編集できません。

ユーザーまたはチームに対する (組織内の) ジョブテンプレートの管理を 完全に 委譲するには、チームまたはユーザーに組織レベルのロールを 3 つ付与する必要があります。

ジョブテンプレートの管理者
プロジェクトの管理者
インベントリーの管理者

これにより、ユーザー (またはこれらのロールが割り当てられたチームに所属する全ユーザー) が組織内のジョブテンプレートを変更する全権限が割り当てられるようになります。ジョブテンプレートが別の組織からのインベントリーやプロジェクトを使用する場合には、これらの別の組織ロールを持つユーザーは、このジョブテンプレートを変更する権限がない可能性があります。パーミッションの管理を明確化するには、ベストプラクティスとして、異なる組織のプロジェクト/インベントリーを混同させないようにしてください。

31.3.1.2. RBAC パーミッション¶

組織管理者ロールに組織のコンテンツオブジェクトを含めるなど、ロールごとに、コンテンツオブジェクトを含める必要があります。ロールを委譲するには、コンテンツオブジェクトへの管理者パーミッションが必要です (ユーザーのパスワードをリセットできてしまうパーミッションは例外)。

親は組織です。

許可は新規パーミッションで明示的に許可される内容です。

範囲は新規ロールの作成先の親リソースです。例: Organization.project_create_role

前提として、リソースの作成者には対象リソースの管理者ロールを指定する必要があります。リソースを作成するとことで暗黙的にリソースの管理者が割り当てられない場合には、明示的に呼び出します。

各管理者タイプに付随するルールを以下に示します。

プロジェクト管理者

許可: プロジェクトの作成、読み取り、更新、削除
範囲: 組織
ユーザーインターフェース: プロジェクト追加画面 - 組織

インベントリー管理者

親: 組織管理者
許可: インベントリーの作成、読み取り、更新、削除
範囲: 組織
ユーザーインターフェース: インベントリー追加画面 - 組織

注釈

使用ロールが割り当てられているので、ユーザーにプロジェクト管理者およびインベントリー管理者が割り当てられている場合には、組織に対するジョブテンプレート (ワークフローではなく) を作成できます。

認証情報管理者

親: 組織管理者
許可: 共有されている認証情報の作成、読み取り、更新、削除
範囲: 組織
ユーザーインターフェース: 認証情報追加の画面 - 組織

通知管理者

親: 組織管理者
許可: 通知の割り当て
範囲: 組織

ワークフロー管理者

親: 組織管理者
許可: ワークフローの作成
範囲: 組織

組織実行

親: 組織管理者
許可: JT および WFJT の実行
範囲: 組織

以下は、組織とそのロール、それぞれがアクセスできるリソースを示すシナリオ例です。

_images/rbac-multiple-resources-scenario.png