はじめに

こちらの記事は下記Advent Calendar 2024で紹介しているIBM Cloud権限設定における Kubernetes Service になります。

Kubernetes Serviceとありますが、IBM CloudではKubernetes、OpenShiftの両方に対しての権限設定になります。

共通権限は割愛

こちらの記事に記載しているように、プラットフォーム・アクセス、サービス・アクセスの権限でそれぞれどのようなものが共通して設定されているかを紹介させて頂きました。

こちらの記事では共通部分で出現する権限を除いた各サービス毎の権限設定を紹介します。

Kubernetes Serviceで指定可能な権限のアクセス範囲

リソース・グループ
Region
Cluster
Namespace

リソース・グループの指定

これは指定されたリソース・グループに所属するKubernetes Serviceのみに対してアクセス権限を適用します。異なるリソース・グループのKubernetes Serviceに対しては別途権限を設定する必要があります。

Regionの指定

これは jp-tok といったKubernetes Serviceの存在するRegionを指定することで、その指定されたRegionのみの権限を与えることが可能になります。

Clusterの指定

これは、指定されたKubernetes Serviceのクラスターのみに対して権限を与えることが可能です。

Namespaceの指定

これはクラスター内のNamespaceを指定して権限付与が可能です。Namespaceを分けてPod管理している場合かつ、その運用担当が異なる場合はこちらを指定して権限を厳密にする必要があります。

Kubernetes Serviceに設定された権限

プラットフォーム・アクセスの権限

※Admin : Administrator, KM : Key Manager, SCR : Service Configuration Reader

権限	Viewer	Operator	Editor	Admin
containers-kubernetes.cluster.read	〇	〇	〇	〇
containers-kubernetes.cluster.operate		〇		〇
containers-kubernetes.cluster.update			〇	〇
containers-kubernetes.cluster.create				〇

Kubernetes Serviceのサービス固有権限はreadやoperateといった各権限に集約されすぎてこれを見てもよくわからない部分があります。。。

containers-kubernetes.cluster.read

クラスターの詳細をIBM Cloudコンソール上で確認可能ですが、インフラストラクチャーの変更、つまりWorker Poolの追加変更等を実施することができません。

containers-kubernetes.cluster.operate

こちらはエンジニア向け、ということでWorker Nodeが追加可能で、Worker Nodeの再ロードといったアクションの実施が可能になります。ただ、資格情報の作成やクラスター全体に対する設定変更等は実施できません。

containers-kubernetes.cluster.update

クラスターに対して他のサービスのバインドや、Ingressの操作、Cloud Logsといったサービスへのログ転送の設定といったことが可能になります。

containers-kubernetes.cluster.create

クラスター作成や削除、クラスター全体に関わる設定、アドオンの追加といった操作が可能になります。

ただし、クラスターの作成には権限設定に注意が必要です。

下記リンク先に記載されていますが、Kubernetes Serviceでクラスターを作成する際には他のサービスの権限も必要になります。インフラストラクチャーのサービス上に構成されるので、その権限や他のコンテナ関連サービスの権限も必要と記載されているのでよくご確認ください。
https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles&locale=ja#cluster-create-permissions

サービス・アクセスの権限

権限	Reader	Writer	Manager
containers-kubernetes.kube.read	〇
containers-kubernetes.kube.write		〇
ontainers-kubernetes.kube.manage			〇

権限の名称が役割と一緒なだけで何ができる権限か全然わからないですね。

こちらはKubernetesが提供しているRBAC(Role Based Access Control)と紐づく形になっています。

上記を確認して頂き、下記のマッピングで対応しています。
read : ユーザー向けRoleのViewに相当
write : ユーザー向けRoleのEditに相当
manage : ユーザー向けRoleのCluster-Adminに相当

もしこれだと与える権限が広い、実行可能なkubectlコマンドが多いといったものがあれば、下記ドキュメントを参考にカスタムRBACを作成して、それをユーザーやサービスIDに権限として割り当てることも可能なので、こちらも参考にして頂ければと思います。

さいごに

Kubernetes Serviceは権限は抽象化というかまとめられすぎていてよくわからないですよね。RBACの説明も細かく何ができるか全て説明しているわけではないので、与えた権限が相応しいものかはよく検討するようにして頂ければ幸いです。