RBACロールの種類とは？

• Kubernetes 役割 は、デプロイメントやサービスなど、特定の名前空間内のリソースにスコープ設定されます。
• Kubernetes _クラスター役割_は、ワーカー・ノードなど、クラスター全体のリソースにスコープ設定されることも、ポッドなど、各名前空間で検出できる名前空間スコープ・リソースにスコープ設定されることもあります。

RBACロールバインディングとクラスターロールバインディングとは何ですか？

役割バインディングによって、RBAC 役割または RBAC クラスター役割が特定の名前空間に適用されます。 役割バインディングを使用して役割を適用すると、ユーザー・アクセス権限を、特定の名前空間内の特定のリソースに付与することになります。 役割バインディングを使用してクラスター役割を適用すると、ユーザー・アクセス権限を、各名前空間内で見つかる名前空間に有効範囲設定されたリソース (ポッドなど) に付与することになりますが、特定の名前空間内でのみ有効です。

クラスター役割バインディングによって、RBAC クラスター役割がクラスター内のすべての名前空間に適用されます。 クラスター役割バインディングを使用してクラスター役割を適用すると、ユーザー・アクセス権限を、クラスター全体のリソース (ワーカー・ノードなど)、またはすべての名前空間内の名前空間に有効範囲設定されたリソース (ポッドなど) に付与することになります。

私のクラスターでは、これらの役割はどのようなものだろうか？

ユーザーがクラスター内から Kubernetes リソースを操作できるようにするには、IBM CloudIAM サービス・アクセス役割を介してユーザーに 1 つ以上の名前空間に対するアクセス権限を割り当てる必要があります。 サービス・アクセス役割が割り当てられているすべてのユーザーには、対応する RBAC クラスター役割が自動的に割り当てられます。 これらの RBAC クラスター役割は事前定義されており、これらによってユーザーはクラスター内の Kubernetes リソースと対話することが許可されます。 また、特定の名前空間にクラスター役割を適用するために役割バインディングが作成されるか、すべての名前空間にクラスター役割を適用するためにクラスター役割バインディングが作成されます。

各 RBAC ロールによって許可されるアクションの詳細については、 IBM Cloud IAM サービス・アクセス・ロールのリファレンス・トピックを参照してください。 各 RBAC 役割によって付与される、個々の Kubernetes リソースに対する権限を確認するには、RBAC 役割別の Kubernetes リソースの許可を確認してください。

カスタムロールやクラスターロールを作成できますか？

独自のカスタム RBAC ポリシーを作成する場合は、クラスター内の既存の IBM 役割バインディングを編集したり、既存の IBM バインディングと同じ名前でカスタム役割バインディングを作成したりしないようにしてください。 IBM提供の RBAC 役割バインディングに対して行った変更は、更新時に保持されません。

クラスター役割 view、edit、admin、および cluster-admin は、対応する IBM Cloud IAM サービス・アクセス役割をユーザーに割り当てたときに自動的に作成される事前定義役割です。 他の Kubernetes 許可を付与するには、カスタム RBAC 許可を作成できます。 カスタム RBAC 役割は、サービス・アクセス役割で割り当てられた任意の RBAC 役割に追加されるものであり、そのような RBAC 役割は変更もオーバーライドもできません。 カスタム RBAC 許可を作成するには、IAM の管理者のサービス・アクセス役割が必要です。これにより、Kubernetes の cluster-admin の RBAC 役割が付与されます。 ただし、独自のカスタム Kubernetes RBAC 役割を管理する場合、他のユーザーには IAM サービス・アクセス役割は必要ありません。

カスタム・クラスター役割バインディングおよび役割バインディングをいつ使用する必要がありますか?

クラスター内でポッドを作成したりアップデートしたりできる権限を与える場合があります。 セキュリティー・コンテキスト制約 (SCC) を使用して、クラスターに付属している既存のクラスター役割バインディングを使用することも、独自のものを作成することもできます。

クラスターにアドオンを組み込む場合もあります。 例えば、クラスターで Helm をセットアップする場合です。

ユーザー、グループ、またはサービス・アカウントに対するカスタム RBAC 許可の作成

クラスター役割 view、edit、admin、および cluster-admin は、対応する IBM Cloud IAM サービス・アクセス役割を割り当てると、自動的に作成されます。 これらの事前定義許可で実行されるものよりも粒度の高いクラスター・アクセス・ポリシーが必要ですか? 問題ありません。 カスタム RBAC 役割およびカスタム RBAC クラスター役割を作成できます。

カスタム RBAC 役割およびカスタム RBAC クラスター役割を個別のユーザー、ユーザー・グループ、またはサービス・アカウントに割り当てることができます。 グループに対してバインディングが作成されると、そのグループに追加またはそのグループから削除されるすべてのユーザーに影響を与えます。 ユーザーをグループに追加すると、ユーザーは、付与された個別のアクセス権限に加えて、グループのアクセス権限を得ます。 ユーザーを削除した場合、アクセス権限は取り消されます。 サービス・アカウントをアクセス・グループに追加することはできないことに注意してください。

継続的デリバリーのツールチェーンなど、ポッド内で実行されるコンテナ・プロセスにアクセスを割り当てたい場合は、次のようにします。 Kubernetes ServiceAccounts. Travis と Jenkins 用のサービスアカウントをセットアップし、カスタム RBAC ロールをサービスアカウントに割り当てる方法を示すチュートリアルは、ブログポスト Kubernetes ServiceAccounts 自動化システム用 を参照のこと。

変更の中断を防ぐために、事前定義された view クラスター役割、edit クラスター役割、admin クラスター役割、cluster-admin クラスター役割は変更しないでください。 カスタム RBAC 役割は、IBM Cloud IAM サービス・アクセス役割で割り当てられてた可能性があるすべての RBAC 役割に追加されるものであり、そのような RBAC 役割がカスタム RBAC 役割によって変更されたりオーバーライドされたりすることはありません。

• 名前空間アクセス: 特定の名前空間内のリソースへのアクセスをユーザー、アクセス・グループ、またはサービス・アカウントに許可するには、以下の組み合わせのいずれかを選択します。

  • 役割を作成して、役割バインディングをそれに適用します。 このオプションは、1 つの名前空間にのみ存在する固有リソース (アプリのデプロイメントなど) へのアクセスを制御する場合に役立ちます。
  • クラスター役割を作成して、役割バインディングをそれに適用します。 このオプションは、1 つの名前空間内の一般リソース (ポッドなど) へのアクセスを制御する場合に役立ちます。

• クラスター全体のアクセス: クラスター全体のリソースまたはすべての名前空間内のリソースへのアクセスをユーザーまたはアクセス・グループに許可するには、クラスター役割を作成して、クラスター役割バインディングをそれに適用します。 このオプションは、有効範囲が名前空間に設定されていないリソース (ワーカー・ノードなど)、またはクラスターのすべての名前空間内のリソース (各名前空間のポッドなど) へのアクセスを制御する場合に役立ちます。

• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

• すべてのネームスペースに Manager IAM サービス・アクセス・ロールが あることを確認します。

• 個々のユーザーまたはアクセスグループ内のユーザーにアクセスを割り当てるには、そのユーザーまたはグループに、 Red Hat OpenShift on IBM Cloud サービスレベルで少なくとも 1 つの IAM プラットフォームアクセスロールが割り当てられていることを確認します。

カスタム RBAC 許可を作成するには、以下のようにします。

1. 以下のような .yaml ファイルを作成して、 role または cluster role を定義します。

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       namespace: default
       name: my_role
   rules:
   - apiGroups: [""]
       resources: ["pods"]
       verbs: ["get", "watch", "list"]
   - apiGroups: ["apps", "extensions"]
       resources: ["daemonsets", "deployments"]
       verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   

   YAMLパラメータを理解する

   パラメーター	説明
   kind	特定の名前空間内のリソースへのアクセス権限を付与する場合は Role を使用します。 クラスター全体のリソース (ワーカー・ノードなど)、または名前空間に有効範囲が設定されたリソース (すべての名前空間のポッドなど) へのアクセス権限を付与する場合は ClusterRole を使用します。
   metadata.namespace	kind が Role のみの場合: アクセス権限を付与する Kubernetes 名前空間を指定します。
   rules.apiGroups	"apps"、 "batch"、 "extensions" のように、ユーザーが対話できるようにしたい Kubernetes API グループを指定します。 REST パス api/v1 にあるコア API グループに対するアクセス権限については、[""] のようにグループをブランクにします。
   rules.resources	"daemonsets"、 "deployments"、 "events"、 "ingresses" など、アクセスを許可する Kubernetes リソースタイプを指定します。 "nodes" を指定する場合、kind は ClusterRole でなければなりません。
   rules.verbs	"get"、 "list"、 "describe"、 "create"、 "delete" など、ユーザーができるようにしたい アクションの種類を指定します。

2. クラスター内に役割またはクラスター役割を作成します。

   oc apply -f my_role.yaml
   

3. 役割またはクラスター役割が作成されたことを確認します。

   • 役割:

     oc get roles -n <namespace>
     

   • クラスター役割:

     oc get clusterroles
     

4. .yaml ファイルを作成して、ユーザーを役割またはクラスター役割にバインドします。 各件名 (subject) の name に使用している固有の URL に注目してください。

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       name: my_role_binding
       namespace: default
   subjects:
   - kind: User
       name: IAM#user1@example.com
       apiGroup: rbac.authorization.k8s.io
   - kind: Group
       name: team1
       apiGroup: rbac.authorization.k8s.io
   - kind: ServiceAccount
       name: <service_account_name>
       namespace: <kubernetes_namespace>
   roleRef:
       kind: Role
       name: my_role
       apiGroup: rbac.authorization.k8s.io
   

   YAMLパラメータを理解する

   パラメーター	説明
   kind	RoleBinding を名前空間固有の Role または ClusterRole に対して指定します。 クラスター全体の ClusterRoleBinding の場合 ClusterRole を指定します。
   apiVersion	Kubernetes 1.8 以降が稼働するクラスターには、rbac.authorization.k8s.io/v1 を使用します。 それより前のバージョンの場合は、apiVersion: rbac.authorization.k8s.io/v1beta1 を使用します。
   metadata.namespace	kind RoleBinding の場合: アクセス権限の付与先となる Kubernetes 名前空間を指定します。 kind が ClusterRoleBinding の場合: namespace フィールドは使用しません。
   metadata.name	役割バインディングまたはクラスター役割バインディングの名前を指定します。
   subjects.kind	kind を次のいずれかとして指定します: User: RBAC 役割またはクラスター役割を自分のアカウントにおける個別ユーザーにバインドします。 Group: RBAC 役割またはクラスター役割を自分のアカウントにおける IBM Cloud IAM アクセス・グループにバインドします。 ServiceAccount: RBAC 役割またはクラスター役割を自分のクラスターにおける名前空間内のサービス・アカウントにバインドします。
   subjects.name	User の場合: 次のように個別ユーザーの E メール・アドレスを IAM# に追加します: IAM#user@email.com。 Group の場合: ご使用のアカウントにおいて IBM Cloud IAM アクセス・グループの名前を指定します。 ServiceAccount の場合: サービス・アカウント名を指定します。
   subjects.apiGroup	User または Group の場合: rbac.authorization.k8s.io を使用します。 ServiceAccount の場合: このフィールドを含めないでください。
   subjects.namespace	ServiceAccount の場合のみ: サービス・アカウントがデプロイされる Kubernetes 名前空間の名前を指定します。
   roleRef.kind	役割用の kind ファイルの .yaml と同じ値 (Role または ClusterRole) を入力します。
   roleRef.name	役割用の .yaml ファイルの名前を入力します。
   roleRef.apiGroup	rbac.authorization.k8s.io を使用します。

5. クラスター内に役割バインディングまたはクラスター役割バインディングのリソースを作成します。

   oc apply -f my_role_binding.yaml
   

6. バインディングが作成されたことを確認します。

   oc get rolebinding -n <namespace>
   

7. オプション: 他の名前空間で同じレベルのユーザー・アクセスを実行するには、他の名前空間にこれらの役割またはクラスター役割に対する役割バインディングをコピーします。

   1. 役割バインディングを、ある名前空間から別の名前空間にコピーします。

      oc get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | oc -n <namespace_2> create -f -
      

      例えば、 custom-role 名前空間の default 役割バインディングを testns 名前空間にコピーします。

      oc get rolebinding custom-role -o yaml | sed 's/default/testns/g' | oc -n testns create -f -
      

   2. 役割バインディングがコピーされたことを確認します。 IBM Cloud IAM アクセス・グループを役割バインディングに追加した場合は、アクセス・グループ ID としてではなく、そのグループの各ユーザーが個別に追加されます。

      oc get rolebinding -n <namespace_2>
      

カスタム Kubernetes RBAC 役割またはクラスター役割を作成してバインドしたので、ユーザーをフォローアップします。 役割を介して実行許可を持っているアクション (ポッドを削除するなど) をテストするようにユーザーに依頼してください。

クラスター役割の集約による既存の許可の拡張

クラスター役割を他のクラスター役割と集約または結合することにより、ユーザーの既存の許可を拡張できます。 ユーザーに IBM Cloud サービス・アクセス役割を割り当てると、そのユーザーは対応する Kubernetes RBAC クラスター役割に追加されます。 ただし、特定のユーザーが追加の操作を実行できるようにすることもできます。

例えば、名前空間スコープ設定の admin クラスター役割を持つユーザーは、oc top pods コマンドを使用して名前空間におけるすべてのポッドについてポッド・メトリックを表示できるわけではありません。 admin クラスター役割のユーザーに top pods コマンドの実行が許可されるように、クラスター役割を集約できます。 詳しくは、 Kubernetes のドキュメントをご覧ください。

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAM#myname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

RBAC 役割の確認

Red Hat OpenShift on IBM Cloud クラスターで、カスタム RBAC を確認したり、RBAC 役割に同期される IAM のサービス・アクセス権限を確認したりできます。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: 2018-05-23T14:34:24Z
  name: ibm-view
  namespace: default
  resourceVersion: "8192510"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/ibm-view
  uid: 63f62887-5e96-11e8-8a75-b229c11ba64a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: IAM#user@email.com
- apiGroup: rbac.authorization.k8s.io
  kind: group
  name: team1

Kubernetes サービス・アクセス役割と対応する RBAC 役割

以下の表は、各サービス・アクセス役割およびそれに対応する RBAC 役割によって付与される Kubernetes リソース許可を示しています。