2018.03.13

[和訳] Docker EE組み込みKubernetes用ロールベースのアクセス制御(RBAC) #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Role-based Access Control for Kubernetes with Docker EE (2018/1/24) の和訳です。

1月中旬にDocker Enterprise Edition (Docker EE) の最新ベータ版をリリースしました。このベータ版の最も重要な機能の1つは、SwarmとKubernetesのそれぞれのクラスタを一元管理できるマネジメントプレーンを提供している点であることに疑いの余地はありません。これはユーザの皆さまにとって、レガシーアプリケーションとクラウドネイティブアプリケーションの両方を管理するうえで他に例を見ないほど優れた機能です。

今回のベータ版Docker EEを開発中、私たちはこの機能について、KubernetesにGUIを載せて、ボタンをクリックするだけという仕上がりでは不十分だと分かっていました。Kubernetesのノード上でアプリケーションのデプロイを簡略化し、安全性を維持できる領域を見つけ出したかったのです。

そのような領域のひとつに、ロールベースのアクセス制御 (RBAC) がありました。その結果 Docker EE 17.06 に、複数のチームおよびユーザの間で柔軟かつ粒度の高いアクセス制御を提供できるよう強化したRBACソリューションを導入しました。Kubernetesはバージョン1.6で初めて基本的なRBACソリューションを導入していました。次期Docker EEのリリースでは、Docker EEの既存のRBACサポートを、Kubernetesの基本的なRBACソリューションをサポートするように拡張します。

(Docker EEでどのようにRBACが機能するかについて知りたい方は、2017年8月のブログ記事をお読みください)

Docker EEで定義済みの5つの認証ロール(“閲覧のみ”、 “すべての操作”、“権限なし”など)に加え、管理者がカスタムロールを作成するときに利用できる33の異なる運用カテゴリがあります。これらのカテゴリはそれぞれ、複数の異なる設定に対応しています。このことによって管理者は、よく考えられたユーザ向けロールのデフォルトと、必要に応じて高度にカスタマイズしたロールを組み合わせることができるのです。

“Kubernetes Pod Operations” カテゴリ下にある個々の操作の一部

混合オーケストレータにおけるRBACの例

これは私にとっても、実際にいくつかのパターンを試すまでは、複雑で理解しづらいものでした。例えば、キャサリン(Katherine)、サーンヴィ(Saavni)、カーリル(Kahlil)という3人がいるとします。キャサリンはコンテナ管理者で、クラスタ上のKubernetesのネームスペースと、Swarmのリソースすべてにアクセスできる権限を有します。カーリルは新米管理者で、必ずしも起動中のKubernetesリソースを管理する必要はありません。しかし本番用システム上における、Kubernetes上のアプリケーションの実行状況を監視する権限は必要です。サーンヴィはカーリルと同様ですが、彼女の担当はSwarm上のアプリケーションのチェックです。

そこでキャサリンは、カーリルにはポッドのリストアップのみを許可するカスタムロールを設定しました。そしてカーリルにそのロールを与えるグラントを作成しますが、それは“prod-web”のネームスペースのみで有効とします。

次にキャサリンは、Swarmのサービスをリストアップする権限のあるカスタムロールを作成し、それをサーンヴィに、“prod_db”コレクションとして付与しました。

お分かりのように、カーリルの権限は1つのネームスペース(prod-web) のみに制限されているので、どのポッドが実行中かを確認することのみ可能です。つまりカーリルは、実行中のポッドを修正することも、ポッドを新規に作成することもできません。そしてもちろん、他のネームスペースで稼働中のポッドを見ることもできません。このような制限は、カーリルがKubernetesクラスタにアクセスする際、Docker EEのUCP (Universal Control Plane)からアクセスしているのか、またはDocker EEのクライアントバンドルとKubectlを使ってコマンドラインからアクセスしているのか、そのどちらに関わらず適用されます。

そしてサーンヴィには、prod-dbコレクション内で実行されているSwarmサービスに対して、カーリルと同じような制限を適用しました。したがって、サーンヴィにはKubernetesリソースへのアクセス権限はなく、カーリルはSwarmリソースへのアクセス権限がありません。

これはきわめて初歩的な例ですが、Docker EEのRBACの実装が、アプリケーションがGUIかCLIのどちらから管理されているにせよ、KubernetesおよびSwarmの両者でそれぞれに、同じ管理の枠組みを設定できる機能を有する柔軟性を備えていることをご理解いたただけたと思います。

Kubernetesリソースの認証

Kubernetesリソースに対して、実際どのように機能しているのでしょうか？ Docker EEは、 KubernetesのWebhook認証モデルを活用しています。この機能は外部ソースによるすべてのリクエストの検証を可能にするものです。Docker EEでは、コントロールプレーンのRBACコントローラであるeNZiを使用します。Kubernetesの各リクエストを、その発行がCLI経由か、あるいはGUI経由であるかに関わらず、Docker EEのauthNまたはauthZデータベースに対して検証し、適切に拒否または受諾するものです。

今回ご紹介したKubernetesとDocker EEのアクセス制御の統合は、次期リリースにおける新機能のほんの1つにすぎません。私たちはまた、DTR (Docker Trusted Registry) にイメージのミラーリングを追加するなど、DTRへのKubernetes統合についても多くのことを行ってきました。このことがHTTPルーティング機能に大きな改善をもたらしました。これらについては今後もブログ記事でご紹介していきますのでご期待ください。

最新のベータ版に興味のある方は https://beta.docker.com/ にお越しください。

Docker EEについてもっと知りたい方は：