【和訳】チュートリアル：Universal Control Planeでロールに基づくアクセス制限をするには #docker

本稿は Tutorial: Role Based Access Control in Universal Control Plane (2016/3/18) の和訳です。

数週間前にDocker Datacenterをリリースして以来、とてもエキサイティングな時を過ごしています。Docker Datacenterには一般リリース版のUniversal Control Plane (UCP)、オンプレミスやVPCに配置できるマネジメント、そしてコンテナのオーケストレーションなどがあります。情熱的な反応をありがとうございました。我々はDocker Datacenterプラットフォームへエンタープライズ級の機能を提供し続けます。

UCP 1.0の機能の一つに、ロールに基づくアクセス制限 (以下RBACと省略)があります。これは、誰がどのリソースにアクセスできるかを定義し制限するものです。

これがITインフラストラクチャー市場において、非常に重要で複雑な部分です。このチュートリアルでは、この機能がどのようにUCPに実装しているのかに触れ、例を挙げながら説明していきます。

なぜRBACなのか。

RBACはお客様のインフラストラクチャーにおける以下の疑問に答えることができるので重要です。

1. リソースにアクセスできるのは誰か。
2. これらのユーザーはそのリソースに対しどの程度のレベルのアクセス権を持つか。
3. 自分の環境内でどのようにアクセス制限するか。

RBACを最も簡単に理解するためには、その例を知ることです。あなたがAppCoシステム管理者だとしましょう。あなたはmyAppというコンテナ型アプリケーションを開発しています。組織内には3つのチームがあります。開発チーム、運用チーム、営業チームです。各チームはそれぞれの方法でmyAppと関わっています。開発チームはアプリを構築し、クラスター上でテストをする必要があります。運用チームはアプリケーションを展開し、ホスト上のkernelレベルのリソースにアクセスする必要があります。営業チームはmyAppに頻繁に目をやる必要があります。

数週間前にDocker Datacenterをリリースして以来、とてもエキサイティングな時を過ごしています。Docker Datacenterには一般リリース版のUniversal Control Plane (UCP)、オンプレミスやVPCに配置できるマネジメント、そしてコンテナのオーケストレーションなどがあります。情熱的な反応をありがとうございました。我々はDocker Datacenterプラットフォームへエンタープライズ級の機能を提供し続けます。
UCP 1.0の機能の一つに、ロールに基づくアクセス制限 (以下RBACと省略)があります。これは、誰がどのリソースにアクセスできるかを定義し制限するものです。
これがITインフラストラクチャー市場において、非常に重要で複雑な部分です。このチュートリアルでは、この機能がどのようにUCPに実装しているのかに触れ、例を挙げながら説明していきます。

なぜRBACなのか。
RBACはお客様のインフラストラクチャーにおける以下の疑問に答えることができるので重要です。
1. リソースにアクセスできるのは誰か。
2. これらのユーザーはそのリソースに対しどの程度のレベルのアクセス権を持つか。
3. 自分の環境内でどのようにアクセス制限するか。
RBACを最も簡単に理解するためには、その例を知ることです。あなたがAppCoシステム管理者だとしましょう。あなたはmyAppというコンテナ型アプリケーションを開発しています。あなたの組織内には3つのチームがあります。開発チーム、運用チーム、営業チームです。各チームはそれぞれ異なった方法でmyAppと関わっています。開発チームはアプリをビルドし、クラスター上でテストをする必要があります。運用チームはアプリケーションを展開し、ホスト上のkernelレベルのリソースにアクセスする必要があります。営業チームはmyAppに頻繁に目をやる必要があります。

仕事中のAppCo（アプリケーション、チーム、ユーザー）

これらのチームすべてがmyAppにアクセスする必要があります。しかし、各チームが業務遂行に必要なレベルまでのアクセスしかしない保証はあるでしょうか。RBACがUCP内でどう機能するかに触れ、例としてAppCoを使用してみましょう。

ユーザーとチーム

RBAC実行への最初のステップは、ユーザー作成です。UCPユーザーは手動と、LDAP/AD統合経由でのインポートとのどちらでも作成可能です。そして管理者とユーザーという2つのフレーバーがあります。管理者はUCP環境内では何でもできます：すべてのリソースにアクセスでき、UCP設定を変更でき、ユーザーアカウントを管理でき、アクセス権を設定できます。管理者ユーザーでない場合、デフォルトでは、管理者に権限を与えられた以上のことはできません。自分のパスワードは変更できますが、それだけです。AppCoの場合、あなたは明らかに管理者であるので（インストールの一部として最初の管理者アカウントが作成されます）、組織の全員に管理者でないユーザーアカウントを作成します。

ユーザー作成

自分のユーザーは作成したので、それらをチームに入れたいとお思いでしょう。チームとは、アクセス制限目的でのユーザーのグループ分けのことです。チームはUCP経由で、手動で作成可能で、また、LDAP/AD統合を通して同期することも可能です。

AppCoにおいては、実世界のものとマッチするように、UCPで3つのチームを作成しました：開発チームと運用チームと営業チームです。そして、各ユーザーを与えられたチームへ割り当てることができます。

一人のユーザーが同時に複数のチームに入れることにご留意ください。

ユーザーをチームに追加する。

権限のレベル

次に、ユーザーにどのレベルの権限を与えれば良いかについて知りたいとお思いでしょう。UCPは4セットの決定的に異なる権限を提供しています。これにより、起こり得るすべてのアクションに都度個別の権限を設定することなく、簡単にユーザーアクセスを割り当て、把握することができます。以下がその権限の4セットです：

フルコントロール：リソースに対して可能な限りのすべてのことができます。（例 コンテナを作成、再起動、削除、閲覧する、など）これは非管理者ユーザーが持ちうる最高レベルのアクセス権です。

限定的コントロール：フルコントロールと似ていますが、コンテナ実行、特権のあるコンテナ、ホストにマウントされたボリューム、その他の細心の注意を払うべき操作に対して制限があります。グループに、製作中のコンテナを実行してもらいたいが、kernelケーパビリティにアクセスしたり、実行特権を使用してコンテナに変更を加えたりしてほしくない場合に最適です。

閲覧のみ：閲覧は可能ですが、手を触れることはできません。リソースを閲覧、検閲だけできます。

アクセス権なし：リソースの閲覧、アクセスができません。

Universal Control Planeにおいて権限がどのように機能するか

権限に関するより詳細の情報を得るには、UCPドキュメントをご覧ください。

ユーザーデフォルト権限を利用して粒度の低いアクセス制限を行うには

UCPにより、2つの決定的に異なる方法を通じてリソースアクセスを設定しアクセス制限を行うことが可能です：ユーザー割り当てるデフォルトの権限と、チームに割り当てるコンテナ・ラベルです。まず、デフォルト権限を扱います。

全ユーザーに、アカウント作成時に割り当てられ、いつでも管理者により編集可能なデフォルト権限設定があります。デフォルト権限は、ラベル付けされていない全てのコンテナリソースと、画像、ネットワーク、ボリュームのようなコンテナではないリソースに対して実行されます。

AppCoの場合、ユーザーを作成した際、ユーザーには“アクセス権なし”というデフォルト設定がありました。そのため、各ユーザーは画像のタブやネットワーク、ボリュームを見ることもできません。考え直した結果、あなたは運用チームの仲間にはコンテナでないリソースを作成したり削除したりできる必要があると思い、それらすべてのユーザーデフォルト権限を“フルコントロール”へ変更します。開発チームと営業チームの仲間は、クラスターの展開を理解するために、これらのリソースを閲覧できなければなりません。そのため、あなたはすべてのユーザーデフォルト権限を“閲覧のみ”に変更します。

様々なユーザーデフォルト権限のコントロールパネルサイドバー

Team Container Labelsを利用して粒度の高いアクセス制限を実行するには

デフォルトの権限は、コンテナと他のリソースへ、広範で粒度の低いアクセス制限を提供できます。しかし多くの場合、特定のコンテナに対して非常に細かなアクセスを提供したいとお思いでしょう。また、より簡潔な組織運営と利便性のために、個人よりもチームレベルでの制限をお好みかもしれません。ここでラベル権限の出番です。

AppCoの場合、（管理者としての）あなたは様々なチームに対して、myAppアプリケーションをコンテナ化した内容物、これらすべてを対象とする様々なレベルのアクセス権が必要だと考えます。まず初めのステップは、myAppの一部として開始するコンテナすべてに対し、アクセルラベルとしてcom.docker.ucp.access.labelキーとmyApp値を確実に使用することです。これはUCP GUI（次に示す）でも、コンテナ実行中でもどちらにおいてでも設定できます。（例 docker run –label com.docker.ucp.access.label="myApp"）

権限ラベルを用いてアプリケーションを展開

次に、Team UIスクリーンへ移動して各チームの権限を設定します：

1. 営業チームは作動中のmyAppコンテナを見る必要はあるが、アプリケーションを変更する権限は必要としません。そこで、彼らには“myApp”ラベルに対して“閲覧のみ”を与えます。
2. 開発チームはmyAppコンテナを起動し停止できる必要はあるが、あなたは彼らに実行中のコンテナを編集したり、ホストに対してkernelレベルのアクセス権を持ったりしてほしくはありません。そこで、“myApp”ラベルに対して“限定コントロール”アクセス権を与えます。
3. 運用チームは、必要に応じてアプリケーションを自由に変更する必要があるので、 “myApp”ラベルに対して“フルコントロール”アクセス権を与えます。

チームに権限ラベルを付与
同じラベルに対してアクセス権を持ち、複数のチームに属しているユーザーには、それらのチームのうちの持ちうる最高のアクセス権があることにご留意ください。AppCoの例より、管理者がユーザーJaneを開発と運用のチーム両方に追加したとしましょう。myAppラベルに対して、運用チームにはフルコントロール、開発チームには制限コントロールアクセス権があります。そのため、JaneにはmyAppラベルに対してフルコントロール権があります。それら2つのチームのうち、より高位のアクセス権です。

まとめ
現在、AppCoの全ユーザーにユーザー割り当てデフォルト権限とチーム割り当てラベル権限があります。ユーザーが権限のない行為をしようとした場合、 “アクセス拒否”エラーが出ます。これはユーザがDocker Clientを通して、UCP GUI内あるいはCLI内でこのような行為を行った場合に起こります。

GUIとCLIの両方においてアクセスが拒否される
RBACの概要は役立ちましたか。私たちはRBACに関して非常に楽しみにしており、今後より多くのエンタープライズ級の機能をUniversal Control Planeに構築することを待ち望んでいます。何か質問がありましたらUCPフォーラムで遠慮なくお話しください。

追加資料
• Docker Datacenterの30日無料トライアルを試す
• Docker Datacenterのトレーニングを受ける
• 次のDocker Datacenterデモに登録する