はじめに
こちらの記事は下記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 | KM | SCR |
---|---|---|---|---|---|---|
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の説明も細かく何ができるか全て説明しているわけではないので、与えた権限が相応しいものかはよく検討するようにして頂ければ幸いです。