Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ユーザのクラスタアクセス権限を管理する

PFCP では、Kubernetes における Role/RoleBinding を用いた Role Based Access Control（RBAC）が利用できます。 RoleBinding を作成することで、Role に定義された権限をユーザやグループに付与できます。

Note

以下を読み進める前に PFCP のロール を確認し、PFCP で利用可能なロールについて把握してください。

PFCP で標準提供するロールとグループ

以下の 3 つの ClusterRole1 が利用できます。

  • org-view
    • ユーザのワークロードを閲覧するために必要な権限を有します。
  • org-edit
    • org-view の権限に加えて、ユーザのワークロードを実行するために必要な権限を有します。
  • org-admin
    • org-edit の権限に加えて、Role/RoleBinding 操作などの管理者権限を有します。

Info

各 ClusterRole は Kubernetes 標準の view/edit/admin ClusterRole を基として一部リソースの権限削除および PFCP で利用しているカスタムリソースの権限追加がされています。 具体的にどのリソースに対してどの操作が許可されているかについては下記コマンドで参照できます。

$ kubectl get clusterrole org-view org-edit org-admin -o yaml

また、以下の 2 つのグループが標準で提供されています。

  • org-<組織名>（例：org-pfn）
    • 組織管理者と一般ユーザの両方がこのグループに所属します。
    • ルートネームスペースに対してのみ org-edit Role が与えられます。サブネームスペースに対しては Role が付与されません。
  • org-<組織名>/admin（例：org-pfn/admin）
    • 組織管理者が所属するグループです。
    • ルートネームスペースおよびすべてのサブネームスペースに対して、org-admin ClusterRole が与えられます。

ルートネームスペースは、組織に属するすべてのユーザが org-edit 以上の権限を有しているため、初期設定のままご利用いただけます2。 新規に作成したサブネームスペースについては、一般ユーザは権限をもちません。一般ユーザに権限を付与するには、RoleBinding を作成します。

RoleBinding の作成

RoleBinding は、以下の 2 通りで作成できます。

  1. グループに対する RoleBinding の作成
  2. ユーザに対する RoleBinding の作成

サブネームスペースに対して、グループ・ユーザのそれぞれに org-edit の ClusterRole2を付与する方法を説明します。

グループに対する RoleBinding の作成

すべてのユーザに対し、サブネームスペース（org-<組織名>--foo）への権限を付与するには、以下の RoleBinding を作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit
  namespace: org-<組織名>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:org-<組織名>

また、組織のユーザを管理する で作成したユーザグループへ権限を付与できます。 ユーザグループ（ops）に対し、サブネームスペース（org-<組織名>--foo）への権限を付与するには、以下の RoleBinding を作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit-ops # name は任意です
  namespace: org-<組織名>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:org-<組織名>/ops  # PFCP のユーザグループ名を指定します。

Info

外部認証基盤との SAML 連携をご利用になりたい場合は、サポートまでお問い合わせください。

ユーザに対する RoleBinding の作成

特定のユーザ（alice@example.com）に対し、サブネームスペース（org-<組織名>--foo）への権限を付与するには、以下の RoleBinding を作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit-user-alice  # name は任意です
  namespace: org-<組織名>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: oidc:org-<組織名>/alice@example.com

一般ユーザのルートネームスペースに対するワークロード実行権限を削除する

PFCP で標準提供するロールとグループ に記載のとおり、一般ユーザにはルートネームスペースへの org-edit 権限がデフォルトで付与されます。 一般ユーザに対するルートネームスペースへの org-edit 権限付与をやめる場合は、以下のコマンドを実行します。

$ kubectl -n org-<組織名> delete rolebindings org-edit

これにより、一般ユーザはルートネームスペースでの任意のリソース作成とワークロードの実行ができなくなります。

Info

一般ユーザはルートネームスペースの org-view 権限を常に持ち、組織管理者がこの権限を無効化することはできません。

独自の Role を作成する

org-admin ClusterRole には任意の Role をネームスペースに作成する権限が含まれており、組織管理者は独自の権限設定を持つ Role を作成し一般ユーザに付与できます。

例えば Pods の閲覧権限のみを許可する独自の Role は次のようになります。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-view
  namespace: org-<組織名>--foo
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

参考リンク

FAQ

Q. 組織管理者権限を使用していますが、クラスタを操作するときは org-edit ロールを使用したいです

組織管理者に付与される org-admin ロールではサブネームスペースや RoleBinding などを操作できる強い権限を持つため、学習ワークロードを実行する際は org-edit ロールを使うことで、誤操作を防止できます。 これは、org-edit ロールが付与された ServiceAccount を作り、その ServiceAccount としてふるまうことで実現できます。

org-<組織名>--foo サブネームスペースを org-edit ロールで操作する場合の手順を、以下に記します。

// `org-<組織名>--foo` ネームスペースに ServiceAccount を作ります。
$ kubectl -n org-<組織名>--foo create sa org-edit-sa
serviceaccount/org-edit-sa created

// 作成した ServiceAccount に `org-edit` ロールを付与します。
$ kubectl -n org-<組織名>--foo create rolebinding org-edit-sa --clusterrole=org-edit --serviceaccount=org-<組織名>--foo:org-edit-sa
rolebinding.rbac.authorization.k8s.io/org-edit-sa created

// `--as system:serviceaccount:<Namespace>:<ServiceAccount>` フラグを付与することで、対象 ServiceAccount になりすまして処理を行います。
// 対象 ServiceAccount になりすませていることを確認します。
$ kubectl --as system:serviceaccount:org-<組織名>--foo:org-edit-sa auth whoami
ATTRIBUTE   VALUE
Username    system:serviceaccount:org-<組織名>--foo:org-edit-sa
Groups      [system:serviceaccounts system:serviceaccounts:org-<組織名>--foo system:authenticated]

// org-admin ロールであれば ResourceQuota を作成することができますが、なりすましているときは作成ができません。
$ kubectl auth can-i create resourcequotas -n org-<組織名>--foo
yes
$ kubectl --as system:serviceaccount:org-<組織名>--foo:org-edit-sa auth can-i create resourcequotas -n org-<組織名>--foo
no

--as フラグを都度追加するのを避けたい場合は、kubeconfig の user フィールドに以下の通り設定を追加することで、デフォルトの設定にできます。

 - name: pfcp-<組織名>-<クラスタ名>
   user:
+    as: system:serviceaccount:<Namespace>:<ServiceAccount>
     auth-provider:
       config

  1. ClusterRole はどの Namespace からでも利用できるロールです。 ↩

  2. 一般ユーザに対するルートネームスペースへの org-edit ClusterRole の付与が不要な場合には、オプトアウトできます。設定方法は 一般ユーザのルートネームスペースに対するワークロード実行権限を削除する を参照してください。 ↩ ↩2