31. セキュリティー¶

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

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

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

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

Role-Based Access Controls (RBAC) are built into automation controller and allow administrators to delegate access to server inventories, organizations, and more. Administrators can also centralize the management of various credentials, allowing end users to leverage a needed secret without ever exposing that secret to the end user. RBAC controls allow the controller to help you increase security and streamline management.

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

There are a few main concepts that you should become familiar with regarding automation controller's RBAC design--roles, resources, and users. Users can be members of a role, which gives them certain access to any resources associated with that role, or any resources associated with "descendant" roles.

A role is essentially a collection of capabilities. Users are granted access to these capabilities and the controller's resources through the roles to which they are assigned or through roles inherited through the role hierarchy.

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

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

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

user-role-relationship

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

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

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

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

rbac-role-hierarchy

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

rbac-heirarchy-morecomplex

RBAC controls also give you the capability to explicitly permit User and Teams of Users to run playbooks against certain sets of hosts. Users and teams are restricted to just the sets of playbooks and hosts to which they are granted capabilities. And, with automation controller, you can create or import as many Users and Teams as you require--create users and teams manually or import them from LDAP or Active Directory.

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

31.2.2. RBAC の適用¶

The following sections cover how to apply automation controller's RBAC system in your environment.

31.2.2.1. ユーザーの編集¶

When editing a user, a automation controller system administrator may specify the user as being either a System Administrator (also referred to as the Superuser) or a System Auditor.

System administrators implicitly inherit all capabilities for all objects (read/write/execute) within the automation controller environment.
System Auditors implicitly inherit the read-only capability for all objects within the automation controller environment.

31.2.2.2. 組織の編集¶

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

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

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

Users who are organization administrators implicitly inherit all capabilities for all objects within that automation controller organization.

Users who are organization auditors implicitly inherit the read-only capability for all objects within that automation controller organization.

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

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

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

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

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

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

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

All access that is granted to use, read, or write credentials is now handled through roles. You no longer set the “team” or “user” for a credential. Instead, you use automation controller's RBAC system to grant ownership, auditor, or usage roles.

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

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

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

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

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

When editing a job template, administrators (automation controller, organization, and project) can select among the inventory and credentials in the organization for which they have usage capabilities or they may leave those fields blank so that they will be selected at runtime.

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

31.2.2.6. ユーザービュー¶

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

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

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

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

31.2.3. ロール¶

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

31.2.3.1. 組み込みロール¶

The following table lists the RBAC system roles and a brief description of the how that role is defined with regard to privileges in automation controller.

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

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

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

Automation controller support personnel typically works on ensuring that the controller is available and manages it a way to balance supportability and ease-of-use for users. Often, automation controller support will assign “Organization Owner/Admin” to users in order to allow them to create a new Organization and add members from their team the respective access needed. This minimizes supporting individuals and focuses more on maintaining uptime of the service and assisting users who are using automation controller.

Below are some common roles managed by the automation controller Organization:

システムロール (組織用)	一般ユーザーロール	説明
所有者	チームリード - 技術リード	このユーザーは、組織内の他のユーザーのアクセスを制御できます。プロジェクト、インベントリー、ジョブテンプレートに、ユーザー固有のアクセスを追加、削除、付与できます。このユーザーは、組織のプロジェクト、テンプレート、インベントリー、チーム、認証情報を作成、削除、変更できます。
監査者	セキュリティーエンジニア - プロジェクトマネージャー	このアカウントは、組織のすべての側面を読み取り専用モードで表示できます。これは、コンプライアンスを確認し、維持するユーザーに割り当てるのが良いでしょう。さらには、ジョブデーターを管理し、 ships job data from automation controller to some other data collector.
メンバー - チーム	その他のすべてのユーザー	デフォルトで組織のメンバーとなるこれらのユーザーは、組織の側面へのアクセスを受け取りません。アクセスを付与するには、組織の各所有者が、各チームにユーザーを追加し、組織のプロジェクト、インベントリー、ジョブテンプレートの各コンポーネントへの 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