Kubernetes RBAC の解説：重要な概念と例

Kubernetes RBAC：基本概念

この記事をお読みの皆さんは、RBAC の一般的な概念についてご存じでしょう。RBAC システムは、オペレーティングシステムやパブリッククラウドなど、さまざまなコンテキストで、ユーザー ID に基づいて誰が何にアクセスできるかを定義するために使用されます。

Kubernetes RBAC は、これらの概念に基づいています。ただし、Kubernetes の RBAC は、他のほとんどの RBAC フレームワークとはいくつかの重要な点で異なります。

ユーザーアカウントとサービスアカウント

Kubernetes では、RBAC ポリシーを使用して、人のユーザー（または人のユーザーのグループ）のアクセス権限を定義できます。Kubernetes は、人のアカウントをユーザーアカウントとして識別します。

ただし、RBAC ポリシーは、Kubernetes が サービスアカウント として識別するソフトウェアリソースの動作も制御できます。

Kubernetes は概念的にはユーザーアカウントとサービスアカウントを区別していますが、RBAC ポリシーに関してはその違いはほとんど意味がありません。この点が、Kubernetes の RBAC を他の多くの RBAC システムと異なる点です。他の多くの RBAC システムは、通常、人間のユーザーの権限（役割やアカウントの種類などに基づく）を管理することに焦点を当てており、ソフトウェアサービスのアクセスを管理するものではありません。

柔軟なリソース定義

Kubernetes RBAC は、RBAC ポリシーが管理できるエンティティの定義方法に関しても、非常に広範です。

Kubernetes では、これらのエンティティを「リソース」と呼び、ポッド、ログ、イングレスコントローラー、または定義したその他のタイプの カスタムリソースなど、ほぼあらゆるものにすることができます。

他のほとんどの RBAC システムは、管理できるリソースのタイプについてより制限的です。例えば、クラウド IAM フレームワークは、仮想マシンインスタンスやストレージバケットなど、事前に定義されたリソースの種類のみを管理するように設計されています。（タグを使用して、どのポリシーがどのリソースに適用されるかを制御することも可能ですが、この方法は Kubernetes のアプローチよりもスケーラビリティに欠けます。なぜなら、各タグを手動で作成する必要があるからです。）

ロールとクラスターロール

Kubernetes RBAC の比較的単純ですが重要な特徴は、1 つのネームスペース内のリソースに適用される権限（ロールで管理）と、クラスタ全体に適用される権限（クラスターロールで管理）を区別していることです。

ほとんどの場合、より詳細なレベル（つまり、個々のネームスペース内）で権限を管理するために、ロールを使用します。ただし、Kubernetes ノードなど、クラスタレベルにのみ存在するリソースのルールを管理するには、クラスタロールを使用したい場合もあります。

「動詞」による権限の管理

アクセスを許可または拒否することしかできないアクセス制御システムや、「読み取り」、「書き込み」、「実行」などの大まかなカテゴリにアクセス権を分類するシステムとは異なり、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>

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 2048

次に、公開鍵とその他のサブジェクト情報を含む証明書署名要求を作成する必要があります。

openssl req -new -key john.key -out john.csr -subj "/CN=john/
O=examplegroup"

Kubernetes は、RBAC のユーザーグループメンバーシップを決定するために、組織 （O=examplegroup） フィールドを使用することに注意してください。

この CSR には、この例では /etc/kubernetes/pki にあるルート Kubernetes CA を使用して署名します （デプロイメントでのファイルの場所は異なる場合があります）。

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 Key

新しい証明書を確認できます。

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)

最後に、新しい認証情報と設定コンテキストを登録します。

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=john

ロールまたはクラスターロールの作成

次に、ロールまたはクラスターロールを作成する必要があります。ここでは、リソースに対して実行できるアクションを定義します。

たとえば、ポッドに対して取得、監視、および一覧表示の権限を付与するロールは次のとおりです。

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"]

RoleBinding または ClusterRoleBinding の作成

最後に、作成したユーザーまたはアカウントにロールまたはクラスターロールを「バインド」する必要があります。このバインドによって、指定したユーザーまたはアカウントが指定されたロールを実行できるようになります。

kubectl create rolebinding podreader-binding --user=john

Kubernetes RBAC のベストプラクティス

Kubernetes RBAC は強力なツールです。以下は、これを可能な限り責任を持って使用するためのベストプラクティスです。

API サーバーのフラグを最小限に抑える

Kubernetes API には、有効にすると Kubernetes の管理の一部を簡略化できるオプションのフラグがいくつかあります。ただし、これらのフラグはセキュリティリスクも高めます。可能な限り、これらのフラグは使用しないでください。

• --insecure-port： 認証されていない不正なリクエストへのアクセスを許可します。この
• パラメーターが 0 の場合、不安全なポートは使用されません。
• --insecure-bind-address： 理想的には、不安全な接続は完全に回避すべきですが、どうしても必要な場合は、このパラメーターを使用してローカルホストにのみバインドできます。このパラメーターが設定されていないことを確認してください。または、少なくともネットワークからアクセス可能な IP アドレスに設定されていないことを確認してください。
• --anonymous-auth： API サーバーのセキュアポートへの匿名リクエストを有効にします。

最低権限の原則に準拠

他の RBAC システムと同様、Kubernetes RBAC は、管理者が最小権限の原則に従う場合に最も効果的です。つまり、各ユーザーまたはアカウントは、その作業を実行するために必要な最小限の権限のみを受け取ります。

実際には、これは、可能な限り ClusterRole の代わりに Role を使用するなどといったことを意味します。各ネームスペースにロールを設定することは、クラスター全体にクラスターロールを定義するよりもやや手間がかかりますが、ロールは適用されるリソースが少なくて済むため、より安全です。

同様に、動詞やリソースへのアクセスを定義する際には、ワイルドカード ［「*」］ は使用しないでください。ワイルドカードは Kubernetes の「chmod 777」のようなもので、適用は便利ですが、あらゆる種類の不正アクセスを可能にしてしまいます。

サービスアカウントのデフォルト設定を回避

Kubernetes は、ポッド内で実行されているプロセスを識別するために、デフォルトのサービスアカウントを作成します。

独自のアカウントを設定する手間を省くために、これらのデフォルトアカウントを使用して権限を割り当てたくなるかもしれません。これはベストプラクティスではありません。代わりに、より詳細なアクセス制御の基盤となる、サービス固有のサービスアカウントを作成してください。

ちなみに、デフォルトユーザーについて疑問に思っているかもしれませんが、Kubernetes にはデフォルトのユーザーアカウントはありませんので、その点については心配する必要はありません。ロールやクラスターロールを割り当てる場合は、ユーザーを明示的に作成する必要があります。

RBAC ポリシーを継続的に更新

Kubernetes RBAC は、作成した RBAC ポリシーと同じくらいしか効果はありません。ポリシーが古くなると、すぐに権限が過剰なユーザーやサービスアカウントができてしまう可能性があります。

そのため、ユーザーやサービスアカウントの権限を作成、削除、更新する場合、またはネームスペースやポッドを作成する場合は、そのエンティティに関連付けられているすべての RBAC ポリシーも変更または削除することをお勧めします。Kubernetes には RBAC に関連する複数のファイルタイプ（ロール、ロールバインディング、クラスターロール、クラスターロールバインディング）が存在するため、この作業は多少面倒になる可能性があります。それでも、RBAC ポリシーの更新を Kubernetes 管理の体系的で継続的なプロセスとして組み込むことは重要です。

Kubernetes RBAC を最大限に活用

RBACを活用せずに、あらゆる規模のセキュアなKubernetesクラスタを運用することは不可能です。テスト目的でノートPC上で単一ノードのクラスタを運用する場合、RBACポリシーなしで運用できるかもしれませんが、複数のユーザー、ポッド、ネームスペースなどを含むクラスタでは、クラスタ内で誰が何を実行できるかを定義するためにRBACポリシーが必要です。

したがって、Kubernetes の RBAC へのアプローチは、特定の点では少し変わっていると感じられるかもしれませんし、必ずしも最もシンプルな RBAC システムであるとは限りませんが、Kubernetes の RBAC の仕組みと効果的な使用方法を理解するために時間を費やすことは、あらゆる本番環境の Kubernetes をセキュリティで保護するための基本的なベストプラクティスです。