Kubernetes RBACの理解： 主な概念と例を紹介
SHARE:
Content
Kubernetesはセキュリティプラットフォームではありません。アプリケーション内の脆弱性の検知や侵害の監視など、セキュリティ関連タスクの大部分を処理するためのネイティブツールがありません。
しかし、Kubernetesがネイティブな方法で非常にうまく処理するセキュリティタスクがひとつあります。Kubernetesには、広範なビルトインRBACフレームワークが用意されています。KubernetesのRBACを活用することは、Kubernetesで実行されるクラスタとアプリケーションのセキュリティを確保するための基本的な第一歩です。
この記事では、Kubernetes RBACの中核となる概念、Kubernetes RBACポリシーの使用方法、KubernetesでRBACを使用する際に従うべきベストプラクティスと避けるべき間違いを紹介します。
Kubernetes RBAC： 基本概念
これを読んでいる方は、おそらく一般的な原理としてRBACをご存知でしょう。さまざまなコンテキスト（オペレーティングシステムやパブリッククラウドなど）で、RBACシステムは、ユーザーIDに基づいて誰が何にアクセスできるかを定義するために使用できます。
KubernetesのRBACは、これらの概念に基づいて構築されています。ただし、KubernetesのRBACは、他の多くのRBACフレームワークとはいくつかの重要な点で異なります：
ユーザーアカウントとサービスアカウントの比較
Kubernetesでは、RBACポリシーを使用して、人間のユーザー（または人間ユーザーのグループ）のアクセス権を定義できます。Kubernetesは人間のユーザーをユーザーアカウントとして識別します。
ただし、RBACポリシーは、Kubernetesがサービスアカウントとして識別するソフトウェアリソースの動作も制御できます。
Kubernetesは概念レベルではユーザーアカウントとサービスアカウントを区別していますが、RBACポリシーに関する限り、その違いは実際には重要ではありません。このことが、Kubernetes RBACを他の多くのRBACシステムとは異なるものにしています。通常、Kubernetes RBACは、ソフトウェアサービスのアクセスを管理するのではなく、（職務上の役割やアカウントタイプなどの要因に基づいて）人間のユーザーの権限を管理することに重点を置いています。
柔軟なリソースの定義
KubernetesのRBACは、RBACポリシーが管理できるエンティティをKubernetesが定義する方法に関しても、かなり幅広いです。
Kubernetesではこれらのエンティティを「リソース」と呼び、ポッド、ログ、イングレスコントローラー、その他定義するカスタムリソースの種類など、ほぼ何でも指定できます。
他の多くのRBACシステムは、管理できるリソースの種類をより制限する傾向があります。例えば、クラウドIAMフレームワークは、仮想マシンインスタンスやストレージバケットのような、定義済みのタイプのリソースだけを管理するように設計されています。(どのポリシーがどのリソースに適用されるかを制御するためにタグ付けも使用できるかもしれませんが、これは各タグを手動で作成する必要があるため、Kubernetesのアプローチよりもスケーラブルではありません)。
RoleとClusterRoleの比較
Kubernetes RBACの比較的シンプルでありながら重要な特徴は、Rolesで管理される1つのネームスペース内のリソースに適用されるパーミッションと、ClusterRolesで管理されるクラスタ全体に適用されるパーミッションを区別していることです。
ほとんどの場合、Rolesを使用します。Rolesはより細かい単位（つまり個々のネームスペース内）でパーミッションを管理するために使用できます。しかし、Kubernetesノードのようにクラスタレベルでのみ存在するリソースのルールを管理するためにClusterRolesを使用したい場合もあります。
「動詞」による権限管理
アクセスを許可または拒否することしかできないアクセス制御システムや、アクセス権を「読み取り」、「書き込み」、「実行」のような大まかなカテゴリに分類するシステムとは異なり、Kubernetes RBACは、アカウントがリソースに対して実行できる特定のアクションを定義する一連の「動詞」を提供します。
たとえば、RBACポリシー内で適切な動詞を指定することで、ユーザーに特定のリソースの「作成」と「一覧表示」を許可できます。
実行することで、クラスタで使用可能なすべての動詞のリストを取得できます：
kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get
--show-kind --ignore-not-found -l <label>=<value> -n <namespace>Code language: HTML, XML (xml)Kubernetes RBACを使った作業： 手順と例
KubernetesにおけるRBACの基本がわかったところで、その使い方を見ていきましょう。
RBACサポートの確認
ず、クラスタがRBACをサポートしていることを確認してください。RBACはKubernetes 1.6で導入され、ほとんどのクラスタではデフォルトで有効になっていますが、確認しておいて損はありません。
マスターノードまたはKubernetes APIサーバポッドの/etc/kubernetes/manifestsでRBAC設定ファイルを探し、フラグが含まれていることを確認します：
--authorization-mode=Node,RBACユーザーとサービスアカウントの定義
次に、ユーザーやサービスアカウントを定義する必要があります。簡単な例として、ここでは John という名前のユーザのユーザアカウントを作成する手順を示します。
まず、新しい秘密鍵を作成します：
openssl genrsa -out john.key 2048Code language: CSS (css)次に、公開鍵とその他のサブジェクト情報を含む証明書署名要求を作成しなければなりません：
openssl req -new -key john.key -out john.csr -subj "/CN=john/
O=examplegroup"Code language: PHP (php)KubernetesはOrganization (O=examplegroup)フィールドを使用して、RBACのユーザーグループメンバーシップを決定することに注意してください。
この例では/etc/kubernetes/pkiにあるルートKubernetes CAを使用して、このCSRに署名します（デプロイメントのファイルの場所は異なる場合があります）：
openssl x509 -req -in john.csr -CA /etc/kubernetes/pki/ca.crt
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out john.crt
Signature ok
subject=/CN=john/O=examplegroup
Getting CA Private KeyCode language: JavaScript (javascript)新しい証明書を確認できます：
openssl x509 -in john.crt -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 11309651818125161147 (0x9cf3f46850b372bb)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 2 20:20:54 2018 GMT
Not After : May 2 20:20:54 2018 GMT
Subject: CN=john, O=examplegroup
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)Code language: PHP (php)最後に、新しい認証情報と設定コンテキストを登録します：
kubectl config set-credentials john --client-certificate=/home/newusers/john.crt --client-
key=/home/newusers/john.key
kubectl config set-context john@kubernetes --cluster=kubernetes --user=johnCode language: JavaScript (javascript)RoleまたはClusterRoleの作成
次に、RoleまたはClusterRoleを作成しなければなりません。ここでリソースに対して実行できるアクションを定義します。
例えば、Podに対してget、watch、listの権限を付与するRoleを示します。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]Code language: PHP (php)RoleBindingまたはClusterRoleBindingの作成
最後に、RoleまたはClusterRoleを作成したユーザまたはアカウントに “バインド “しなければなりません。バインドは、指定されたユーザまたはアカウントが与えられたロールを実際に実行することを可能にするものです。
kubectl create rolebinding podreader-binding --user=johnKubernetes RBACのベストプラクティス
Kubernetes RBACは強力なツールです。可能な限り責任を持って使用するためのベストプラクティスを以下に示します。
APIサーバフラグの最小化
Kubernetes APIには、有効にするとKubernetes管理の一部を簡素化できるオプションのフラグが多数あります。しかし、これらはセキュリティリスクを高めるものでもあります。これらのフラグは可能な限り避けてください：
- –insecure-port: 認証されていないリクエストへのアクセスを開放します。この パラメータが 0 の場合、安全でないポートがないことを意味します。
- –insecure-bind-address: 理想的には、安全でない接続は完全に避けるべきですが、 どうしても必要な場合には、このパラメータを使って localhost にだけバインドすることができます。このパラメータが設定されていないか、少なくともネットワークに到達可能なIPアドレスが設定されていないことを確認してください。
- –anonymous-auth: APIサーバーのセキュアポートへの匿名リクエストを有効にします。
最小特権に従うこと
どのRBACシステムでもそうですが、KubernetesのRBACが最も効果的なのは、管理者が最小特権の原則に従ったときです。
実際には、これは可能な限りClusterRolesの代わりにRolesを使用することなどを意味します。名前空間ごとにRolesを設定するのは、クラスタ全体にClusterRoleを定義するよりも少し面倒ですが、Rolesはより少ないリソースに適用されるため、より安全です。
同様に、動詞やリソースへのアクセスを定義する際にはワイルドカード[“*”]を避けてください。ワイルドカードはKubernetesの “chmod 777 “です: 適用するのは便利ですが、あらゆる種類の不正アクセスの穴を開けてしまいます。
デフォルトのサービスアカウントを避けること
Kubernetesは、ポッド内で実行されているプロセスを識別するためにデフォルトのサービスアカウントを作成します。
わざわざ独自のアカウントを設定するよりも、これらのデフォルトアカウントを使用してパーミッションを割り当てたくなるかもしれません。それはベストプラクティスではありません。代わりに、サービス固有のサービスアカウントを作成して、よりきめ細かなアクセス制御の基礎を提供します。
ちなみに、デフォルトのユーザーについて疑問に思うかもしれませんが、Kubernetesにはデフォルトのユーザーアカウントはありません。RolesやClusterRolesを割り当てたい場合は、明示的にユーザーを作成する必要があります。
RBACポリシーの継続的なアップデート
Kubernetes RBACは、あなたが作成したRBACポリシーと同じくらい効果的です。また、ポリシーが古くなると、すぐに過剰なパーミッションを与えられたユーザーアカウント、またはサービスアカウントになってしまう可能性があります。
そのため、ユーザーアカウントやサービスアカウントのパーミッションを作成、削除、更新するとき、またはネームスペースやポッドを作成するときは必ず、そのエンティティに関連するすべてのRBACポリシーも変更または削除することがベスト・プラクティスです。KubernetesにはRBACに関連する複数のタイプのファイル（Roles、RoleBindings、ClusterRoles、およびClusterRoleBindings）があることを考えると、これはやや面倒です。それでも、RBACポリシーの更新をKubernetes管理の体系的かつ継続的な部分にすることは重要です。
KubernetesのRBACを最大限に活用するために
RBACを活用せずに、あらゆる規模のセキュアなKubernetesクラスタを運用することは不可能です。テスト目的でラップトップ上でシングルノードのクラスタを実行する場合は、RBACポリシーがなくても何とかなるかもしれませんが、複数のユーザー、ポッド、ネームスペースなどを持つクラスタでは、クラスタ内で誰が何をできるかを定義するRBACポリシーが必要になります。
このように、RBACに対するKubernetesのアプローチは、ある面では少し変わっていると感じるかもしれませんし、必ずしも最もシンプルなタイプのRBACシステムであるとは限りませんが、KubernetesのRBACがどのように機能し、どのように効果的に使用するかを理解するために時間を投資することは、あらゆる本番Kubernetes環境のセキュリティを確保するための基本的なベストプラクティスです。