< lcn home

Kubernetes RBACとは？基本概念と使い方を解説

Table of contents
This is the block containing the component that will be injected inside the Rich Text. You can hide this block if you want.

Kubernetesは、セキュリティが完備されたプラットフォームとはいえません。現状、公式ツールだけではアプリケーション内の脆弱性の検知や侵害の監視など、セキュリティ関連タスク全てをカバーするのは難しいのが現状です。

ただしKubernetesには、広範なビルトインRBACフレームワークが用意されており、ネイティブな方法で様々なセキュリティ関連タスクを処理可能です。クラスタとアプリケーションの安全を確保するには、RBACの理解が欠かせません。

この記事では、Kubernetes RBACの基本となる概念を解説したうえで、RBACポリシーの使い方と例、活用のポイントを解説します。

関 連 記 事

Kubernetesとは？Kubernetesセキュリティ
の基礎Kubernetesアーキテクチャの
設計方法AWSのEKS
（Elastic Kubernetes Service）Kubernetesの
クラスターとは？ Kubernetes のノードとは？KubernetesのPodとは？KubernetesのHelmとは？クラウドセキュリティと
ランタイムインサイト

Kubernetes RBACとは？

RBACとは、「Role Based Access Control」の略で、ロールにもとづいたリソースへのアクセス制御方法のことです。Kubernetesでは、コアセキュリティのシステムとして機能します。

さまざまなコンテキスト（オペレーティングシステムやパブリッククラウドなど）で、ユーザーIDにロールを割り当て、そのロールにもとづいて「誰が何にアクセスできるか」を定義できます。

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

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

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

概念レベルではユーザーアカウントとサービスアカウントを区別していますが、RBACポリシーに関する限り、その違いは実際には重要ではありません。このことが、Kubernetes RBACを他の多くのRBACシステムとは異なるものにしています。

基本は、ソフトウェアサービスのアクセスを管理するのではなく、（職務上の役割やアカウントタイプなどの要因に基づいて）人間のユーザーの権限を管理することに重点を置いています。

柔軟なリソースの定義

KubernetesのRBACは、RBACポリシーが管理できるエンティティをKubernetesが定義する方法に関しても、かなり幅広いです。

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

他の多くのRBACシステムは、管理できるリソースの種類をより制限する傾向があります。

たとえば、クラウドIAMフレームワークは、仮想マシンインスタンスやストレージバケットのような、定義済みのタイプのリソースだけを管理するように設計されています。どのポリシーがどのリソースに適用されるかを制御するために、タグ付けも使用できるものもあります。ですが各タグを手動で作成する必要があるため、Kubernetesのアプローチよりも拡張性が低い傾向です。

RoleとClusterRoleの違い

Kubernetes RBACの主要な特徴として、Rolesで管理される1つのネームスペース内のリソースに適用されるパーミッションと、ClusterRolesで管理されるクラスタ全体に適用されるパーミッションを区別していることも挙げられます。

ほとんどの場合、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>

Kubernetes RBACの使い方と例

KubernetesにおけるRBACの使い方と、その例を見ていきましょう。

RBACサポートの確認

前提として、クラスタがRBACをサポートしていることを確認します。RBACはKubernetes 1.6で導入され、ほとんどのクラスタではデフォルトで有効になっていますが、念のために確認しておいて損はありません。

マスターノードまたはKubernetes APIサーバポッドの/etc/kubernetes/manifestsでRBAC設定ファイルを探し、フラグが含まれていることを確認します。

--authorization-mode=Node,RBAC

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

RBACでは、ユーザーやサービスアカウントを定義する必要があります。簡単な例として、ここでは John という名前のユーザーアカウントを作成する手順を紹介しましょう。

まず、新しい秘密鍵を作成します。

openssl genrsa -out john.key 2048

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

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

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

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

RoleBindingまたはClusterRoleBindingの作成

RoleまたはClusterRoleを作成したユーザーまたはアカウントにバインドします。バインドは、指定のユーザーやアカウントが与えられたロールを実際に実行できるようにするものです。

kubectl create rolebinding podreader-binding --user=john

Kubernetes RBAC活用のポイント

Kubernetes RBACは便利ですが、活用するにはポイントを押さえる必要があります。ここでは主なものを紹介しましょう。

APIサーバフラグを最小化する

Kubernetes APIには、有効にするとKubernetes管理の一部を簡素化できるオプションのフラグが多数あり、セキュリティリスクを高めるためにも使えます。ただし、以下フラグは可能な限り避けましょう。

  • --insecure-port: 認証されていないリクエストへのアクセスを開放します。この パラメータが 0 の場合、安全でないポートがないことを意味します。
  • --insecure-bind-address: 理想的には、安全でない接続は完全に避けるべきです。ただし、 どうしても必要な場合には、このパラメータを使って localhost にだけバインドすることができます。このパラメータが設定されていないか、少なくともネットワークに到達可能なIPアドレスが設定されていないことを確認しましょう。
  • --anonymous-auth: APIサーバーのセキュアポートへの匿名リクエストを有効にします。

できる限り最小特権に従う

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管理の体系的かつ継続的な部分にすることは重要です。

まとめ

RBACを活用することなく、あらゆる規模のセキュアなKubernetesクラスタを運用するのは不可能です。テスト目的で、ラップトップ上のシングルノードクラスタを実行する場合、RBACポリシーがなくても何とかなるかもしれません。しかし、複数のユーザー、ポッド、ネームスペースなどを持つクラスタでは、クラスタ内で誰が何をできるかを定義するRBACポリシーが必須です。

KubernetesにおいてRBACがどのように機能するか理解することは、本番環境のセキュリティを確保するための基本です。

FAQs

No items found.

セキュリティ専門家とともに、
クラウドを防御する正しい方法を試してみよう

デモを依頼