Kubernetes RBAC：許しを求めるのか、許可を得るのか #AquaSecurity #Kubernetes #DevSecOps

本ブログは「Aqua Security」社の技術ブログで2019年6月3日に公開された「Kubernetes RBAC: Asking for Forgiveness or Getting Permission」の日本語翻訳です。

このブログは私の母に捧げています。母は学習と旅行を愛する一流の精神科医でした。彼女は私にとって大きな存在でした。
母は「私が自分の好きなことを教えるために世界中を飛び回りながら情熱を追い求めている」ことを誇りに思うだろうと思います。

Kubernetes RBAC：事前に許可を得るより、あとで許してもらうほうが楽

母に加えて、ここではコンピュータ言語の創設者である「グレイス・ホッパー」の言葉を紹介したいと思います。
彼女の有名な言葉に以下があります。

「事前に許可を得るより、あとで許してもらうほうが楽」

この言葉の意味をKubernetesを考える際に咀嚼してみると興味深いものであることがわかります。
詳しくは本ブログの最後までご付き合いいただければわかります。

まずは、LinuxとKubernetesの両方の文脈で「パーミッション」を検討してみましょう。

LinuxとKubernetesのパーミッション

Linuxでは、ほとんどすべてがファイルで成り立っています。

Linuxでロールを割り当て、パーミッションを定義するのは簡単です。Linuxのファイルには、所有者/所有グループ/その他ユーザのそれぞれに対する、読み取り/書き込み/実行許可を示すフラグがあります。この所有権および許可情報はファイル自体の属性として定義され、追加のオブジェクトは必要ありません。

これは、パーミッション、所有者、およびグループを表示したLinuxのファイルの例です。

一方Kubernetesでは、すべてがリソース、つまりpod、node、service、serviceaccount等で成り立っています。
しかし、これらのリソースには所有権やパーミッションの属性はありません。代わりに、別の方法で定義します。

• Roleは、一連のリソースと一連のverbsを指定するルールを定義します。これにより、あるユーザがオブジェクトに対して実行できるアクションを制限できます。しかしあるユーザがオブジェクトに対して何のアクションを実行できるかについては一覧で表示することはできません。
• RoleBindingはRoleをユーザに紐づけます。これは、ユーザ、グループ、またはService Accountが該当します。これは「誰が」の部分を定義します。

RoleとRolebindingはnamespaceに適用されます。ClusterRolesおよびClusterRoleBindingsと呼ばれるKubernetesクラスタ全体に適用されるポリシーもあります。

これらのポリシーは、ロールベースのアクセス制御としてRBACと知られています。これらのポリシーによって柔軟性が増し、パーミッションのきめ細かい制御が可能になりますが、同時に複雑さも増します。そしてこの複雑さは、エントロピーの法則的に増加し続けます。

RBACの法則

エントロピーの法則とは、エントロピーは時間とともに増加することで、RBACの設定も時間とともに増加する傾向があるとされています。私はこの現象を「RBACの法則」と呼んでいます。

なぜこのようなこと起きてしまうのでしょうか。何かする必要があるときに新しい権限を要求するのは人間の性質です。ただし、不要になったときに権限を削除するように依頼する可能性は低いです。RBACの許可は付加的なものであり、ブラックリストではありません。許可を削除したい場合は、それを許可するすべてのRole及びRoleBindingの組み合わせを識別する必要があります。

さらに、クラスタ内のさまざまなオブジェクトにアクセスする権限を誰が持っているかを全体的に把握することは非常に困難です。もともと意図されていたよりはるかに高いレベルのアクセス権を付与している可能性があります。不明確な権限は、悪意のある/なしに関わらずpodのdeployやデータに対して操作を許す可能性を高めます。

私たちは権限を自由に与えるという傾向と向き合う必要があります。そのためのツールも必要です。

誰が権限を持っているかの確認

Linuxでは、そのファイルの権限と所有者の属性を調べることで、誰がファイルを実行できるかを簡単に見つけることができます。さきほど示した図では、実行権限が所有者とグループに設定されており、それ以外の人には設定されていないため、ユーザ「liz」とグループ「staff」のメンバーだけファイルに対して実行権限があります。

Kubernetesでは、余分なポリシーは誰が何をすることが出来るかを見つけるプロセスが、より複雑になることを意味しています。たとえば、ユーザがpodを作成できるかどうかを確認するには、以下のような方法が考えられます。

• ユーザに紐づけられているすべてのRoleBindingsを見つける
• RoleBindingsに紐づけられているすべてのRoleを見つける
• 各Roleでpodを作成することを許可されているか否かを調べる

このような作業が面倒に感じたならば、それを実行できるツールがあります。
次のコマンドで自分がpodを作成できるか否か簡単に確認することができます。


$ kubectl auth can-i create pods -as=


podを作成できるすべてのユーザを識別したい場合は以下のような方法が考えられます。

• ポッドを作成できるすべてのRoleを見つける
• Roleに紐づけられているすべてのRoleBindingsを見つける
• オブジェクトに紐づけられているすべてのRoleBindingsを見つける

今回私たちは、特定のオブジェクトに対して、「誰が」特定のオブジェクトに対して「どの操作を実行する権限を持つか」を調べるオープンソースツールkubectl-who-canを作りました。ぜひともご利用ください。

最後に

上記でも触れたように、多くのユーザに多くの権限を与える傾向があり、それを管理する必要があります。

Kubernetesで組織のさまざまなメンバーに特定の権限を設定するには、骨が折れますがそれだけの価値があります。
パーミッションを正しく設定するのは大変ですが、RBACのポリシー設定が増大したクラスタが危険にさらされるよりはマシでしょう。

RBACについて詳細な情報を知りたい方は 、Liz RiceとMichael Hausenblasが共著したO'Reillyの出版物Kubernetes Securityをぜひ読んでみてください。(無料でダウンロードできます)