トップ > Kubernetes入門 > Kubernetesにおけるロール設定

Kubernetesにおけるロール設定

Kubernetes入門

Kubernetesにおけるセキュリティ、アクセス制御の仕組みについて解説します。

アクセス制御はなぜ必要なのか?

スタートアップ企業や、エンジニアリング組織の立ち上げ期では、数名の社員から始まることが多く、権限管理についても比較的緩やかな管理になります。 Kubernetesで実行されるアプリケーションは、通常パーミッションは設定されていません。 特に指定しない限り、すべてのPodはそれらによって作成されるNamespaceのdefaultサービスアカウントとして実行され、いかなるロールも関連づけられません。

しかし、組織が成長するとシステムの規模も人員も拡大し、誰かがミスを犯しただけでやってはいけない変更が発生する可能性があります。

Kubernetesでは、ロールベースのアクセス管理が可能であるため、ユーザーごとにロールを設定することができます。

クラスタ別のアクセス管理

Kubernetesクラスタのセキュリティを確保するために実施できる最も簡単な方法は、クラスタにアクセスできるユーザーを制限することです。 加えて、アクセスできるユーザーをクラスタ運用者とアプリケーション開発者の2種類があります。

このようにすることで、チームごとにクラスタを用意すれば、別のチームが望ましくない変更を加えることを防ぐことができます。

ロールベースのアクセス制御(RBACの導入)

Kubernetesが備えるロールベースのアクセス制御システムを使うことで、クラスタ内の操作を誰が実行できるか制御できます。

このロールベースのアクセス制御システムをRole-Based Access Controlと呼びます。

RBACでは特定のパーミッションを特定のユーザーに与えることで、システムの読み取りから書き込みをできるようにします。 例えば、クラスタ内のPodを一覧表示する権限を基本的なユーザーに与えることで、Podの全てが確認できるようになります。

RBACが有効になっているかどうかの確認

RBACクラスタが有効になっているかどうかを確認するには、次のコマンドを実行してみてください。

kubectl describe pod -n kube-system -l component=kube-apiserver

上記のコマンド結果で、--authorization-modeにRBACが含まれていなければ、クラスタではRBACが有効になっていません。

ロールの理解

Kubernetesのロールは許可を出すパーミッションのセットのことです。 ロールをカスタマイズしたものを作ることが可能ですが、Kubernetesには、初めから使える定義ずみのロールがいくつか用意されています。 (viewロールは与えられたnamespaceに含まれるオブジェクトを閲覧可能ですが、変更権限はありません。)

ロールはNamespaceのレベルか、Clusterの範囲で適応することができます。

ClusterRole

KubernetesのリソースであるClusterRoleは任意のクラスターにあるPodsまたはservicesに対して、 読み取りのアクセス許可を与えるマニフェストになります。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: my-cluster-role  # ClusterRoleの名前
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]  # アクセス対象のリソース
    verbs: ["get", "list", "watch"]  # 許可されるアクション

ポイントは3つ

  • metadata : には制約を課したいクラスター名を記述します。
  • resources : には制約を課すリソース名を記述します。
  • verbs : では許可を与える動作を記述します。

Role

KubernetesのRoleオブジェクトは、クラスタ内の特定のネームスペース内のリソースへのアクセス権を管理するために使用されるリソースです。ClusterRoleと異なりクラスタが対象ではなくNamespaceが対象となります。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: your-namespace  # ロールが適用されるネームスペース
  name: pod-reader-role  # ロールの名前
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

metadataと同様、namespaceに名前を入れることで、対象のネームスペースでのロールを設定することができます。

定義済みのロール3つ

kubernetesでは次の3つのロールが存在します。

  • cluster-admin : 管理者権限
  • edit : 編集のみ
  • view : 読み取り専用

新たにロールを作成せずともこれらの3つのロールで、大部分の要件をカバーできます。

ユーザーにロールを結び付ける

ロールはkubectl applyで指定して実行しただけでは効力が発揮されません。 ユーザーにロールを関連付けて初めて効果を発揮します。

そのために使用するのがロールバインディング（RoleBinding）です。 以下で示すのが、ユーザーdaz酸に対して、demoというネームスペースのみで、pod-reader-roleを付与するマニフェストの書き方です。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: daz-pod-reader-binding  # RoleBindingの名前
  namespace: demo # ロールバインディングが適用されるネームスペース
subjects:
- kind: User  # ユーザーへのアクセスを提供する場合
  name: daz  # ユーザー名
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role  # 結びつけるRoleの種類
  name: pod-reader-role  # 先ほど定義したRoleの名前
  apiGroup: rbac.authorization.k8s.io

ちなみにKubernetesのロールは加法的であり、ロールとバインディングを増やしていくことで許可を追加していきます。