Ansible Towerによる権限の管理

運用・管理

技術解説

連載 [第9回] :

注目の構成管理ツールAnsibleを徹底活用する

2017年7月27日(木)

平原一帆

複数のユーザーによる使用を前提としたAnsible Towerでの権限管理の方法を紹介する。

Ansible Tower権限管理の詳細

さて、これでPlaybookを実行するためのほとんどの要素が揃いました。あとはJob Templateにこれまでの情報を設定していくのですが、現時点で、下記のPermissionの設定が行われていません。ここで一度立ち止まって、Ansible Towerの権限管理について再度整理したいと思います。

残すはPermissionの設定

ユーザーの権限管理については、「ユーザーの作成」の項目で触れたUser Typeによって、System AdministratorやNormal UserといったTypeを設定しました。この時の設定では、「新しくInventoryやProjectを作成する権限があるか？」ということを設定しています。Normal Userでは、InventoryやProjectを作ることができません。下記の画像は、Normal UserがProjectを作成しようとした場合の例です。値は入力できますが、作成ボタンを押すと権限不足でエラーが返ってきます。

Normal UserがProjecttを作成しようとした場合のエラー

この「作成の権限」であるUser Typeという権限のほかに、各Projectなどへの「参加の権限」であるPermissionsを設定することができます。ユーザーを作成したら、そのユーザーの参加可能な権限の一覧であるGranted Permissionsを確認することができます。ユーザーを作成した直後には、このGranted Permissionsには何も表示されていません。下記は、作成したばかりの「TO1(Tokyo Ops 1)」ユーザーの権限です。

作成したユーザーのGranted Permissionsを確認

ProjectなどからPermissionが設定されていないため、ユーザー作成時に指定したOrganization参加の権限のみが表示されています。この状態のまま、Projectのページに移動しても、TO1ユーザーの使用できるProjectは表示されません。

初期状態ではSystem Administoratorで作成したユーザーでも使用できるProjectはない

ここで一旦Adminとしてログインし、Tokyo ProjectというTokyoユーザーを対象としたProjectを選択して、詳細設定からPermissionsを設定してみます。TO1とTD1というユーザーにUse権限を与えます。

ProjectへのPermissionをユーザーに付与

その後、改めてTO1ユーザーのGranted Permissionsを確認すると、Projectへの権限が付与されています。InventoryやJob Templateについても、Projectの場合と同様にPermissionを設定することができます。

Projectへの権限が付与された状態

TO1ユーザーにProjectへの権限が付与された状態で、改めてProjectのページへ移動してみます。

Projectへの権限があるので、Projectが表示されている

今度は参加権限が付与されているため、Projectが表示されています。これで表示されているProjectを利用することができます。

繰り返しとなりますが、Normal Userには参加権限はあっても作成権限を持たないため、この状態で改めて新規にProjectを作成する場合には作成権限であるSystem Administrator権限が必要となることに注意してください。なお、参加権限の付与の際には、Roleと呼ばれるAdmin/Update/Useのような権限を選択することができます。これは参加権限のあるProject内のみでの役割であり、Normal Userに特定のProjectの管理を任せたい場合などには、Adminの役割を付与することで、Normal UserにProject管理の権限を委譲することができます。

Project参加権限付与の際にはRoleを指定できる

Permissionsの付与はTeam単位での登録が可能なので、Userの数が多い場合はTeamを利用したほうが良いでしょう。今回は説明を割愛しますが、Userの数が多い場合にTeamとしてまとめて扱えるのと同じようように、Inventoryの設定時にHostの数が多い場合には、Groupとしてまとめて扱うこともできます。少し紛らわしいですが、Userの複数管理にはTeam、Hostの複数管理にはGroupを用いることになります。

ここまでに作成した要素

引用元：http://docs.ansible.com/ansible-tower/latest/html/userguide/organizations.html

Job Templateの作成と権限範囲の確認

Job Templateの作成

これまでの手順で、Jobを実行するための準備が整いました。これまでに設定した情報を用いて、Job Templateを作成します。Projectを選択すると、Projectで指定したディレクトリのPlaybookを選択できます。

Job Templateの作成

今回の環境では、下記3パターンのPlaybookをすべてのOrganizationで実行できるようにしていきます。

Playbook

Playbook	Playbookの説明
make_new_vm	対象にVMを作成する。必要時にその都度実行するPlaybook
alive_monitor	対象を死活監視する。1時間に一度実行するPlaybook
backup_log	対象のログをバックアップする。1日に一度実行するPlaybook

実際のOrganizationごとのJob Template名は下記のようになります。

Job Template名

地域＼所属	VMの作成	死活監視	ログバックアップ
東京（Tokyo）	Tokyo_make_new_vm	Tokyo_alive_monitor	Tokyo_backup_log
大阪（Osaka）	Osaka _make_new_vm	Osaka_alive_monitor	Osaka_backup_log
名古屋（Nagoya）	\|Nagoya_make_new_vm	Nagoya_alive_monitor	Nagoya_backup_log

Job Templateに対しては、Scheduleを設定することができます。VMを作成するなどの適宜実行する必要のあるPlaybookもあれば、死活監視やバックアップなど定期的に自動実行したいPlaybookもあり、これらをScheduleにより指定することができます。Scheduleは、毎時／毎日／毎週というような設定の他に、「特定の日時」のように柔軟に指定することができます。下記の例では毎日0時を設定しています。

Scheduleの設定例

Job Templateと権限範囲

作成したJob Templateを確認します。管理者から確認すると、すべてのOrganizationのJob Templateが確認できます。

作成したJob Templateの確認

1日経過した場合のJob Statusは下記のようになります。すべてのOrganizationのPlaybookが実行されており、死活監視については1時間おき、バックアップについては1日に1度実行されていることが分かります。

1日経過後のJob Status

一方で、Tokyoのユーザーとしてログインした場合、付与された権限の範囲でしかJob Statusが確認できないことが分かります。

Job Statusが見られるのは、付与された権限の範囲に限られる

正しく権限管理を行うことによって、必要なユーザーに必要な環境を提供することが可能になります。

まとめ

今回の記事では、Ansible Towerによる権限管理についてご紹介しました。紹介したように、Ansible Towerではさまざまな権限設定が可能となっています。今回紹介したProjectへのPermissionsの参加権限付与と同じように、OrganizationやInventoryに対してもPermissionsの設定が可能となっています。今回の記事を通して、Organizationによるマルチテナントの管理やユーザーの権限管理を行うことで、組織的にAnsible Towerを利用できることが確認いただければと思います。

次回は、Ansible Towerによるクラウド管理の一例についてご紹介いたします。

Ansibleは、Red Hat, Inc.の米国およびその他の国における商標または登録商標です。
OpenStackRの文字表記とOpenStackのロゴは、米国とその他の国におけるOpenStack Foundationの登録商標／サービスマークまたは商標／サービスマークのいずれかであり，OpenStack Foundationの許諾を得て使用しています。日立製作所は，OpenStack FoundationやOpenStackコミュニティの関連企業ではなく、また支援や出資を受けていません。