IBM Cloud Docs
RBAC 許可について

RBAC 許可について

IAMサービスのアクセス・ロールは、 Red Hat OpenShift on IBM Cloud クラスター内の Kubernetes ロール・ベース・アクセス・コントロール(RBAC)に対応する。 RBAC 役割および RBAC クラスター役割によって、ユーザーがクラスター内の Kubernetes リソースと対話できる方式についての一連の許可が定義されます。

IBM Cloud IAMを使えば、ユーザーにIAMサービスのアクセス・ロールを割り当てることで、 IBM Cloud からRBACを自動的に管理できる。 クラスター内のリソース (サービス・アカウントなど) に対するアクセス権限をカスタマイズするためには、RBAC についてより深く理解することが必要になる場合があります。

Red Hat OpenShift クラスターのすべてのユーザーが basic-users RBAC グループに追加されます。

  • IBM Cloud IAM 役割をサービス・アカウントに割り当てることはできません。 代わりに、直接 RBAC 役割をサービス・アカウントに割り当てることができます。
  • ユーザーは、自分の役割の変更を有効にするには ibmcloud ks cluster config コマンドを実行する必要があります。

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 役割バインディングに対して行った変更は、更新時に保持されません。

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

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

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

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

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

クラスター役割 vieweditadmin、および 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 のドキュメントをご覧ください。

デフォルトのクラスタ・ロールの権限を拡張したい一般的な操作にはどのようなものがありますか?

デフォルトの RBAC クラスター役割ごとに許可される操作を確認して、ユーザーが実行できる操作を十分に理解してから、許可された操作と実行できるようにする操作を比較します。

同じクラスター役割のユーザーに、同じタイプの操作で以下のようなエラーが発生した場合、クラスター役割を拡張してこの操作を含めることができます。

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"

始める前に、Red Hat OpenShift クラスターにアクセスします。

  1. クラスター役割の YAML ファイルを作成します。 labels セクションで、許可を集約する既存のクラスター役割を指定します。 以下の例では、事前定義された admin クラスター役割を拡張して、ユーザーに oc top pods の実行を許可しています。 その他の例については、 Kubernetes のドキュメントを参照のこと。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: view-pod-metrics
      labels:
        rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rules:
    - apiGroups:
      - "metrics.k8s.io"
      resources:
      - pods
      verbs:
      - list
    
    YAMLパラメータを理解する
    パラメーター 説明
    metadata.name クラスタ・ロールの名前を入力します。定義済みのクラスタ・ロール名は使用しないでくださいview edit, admin, および cluster-admin を使用しないでください。
    metadata.labels

    集約先のクラスター役割に適合するラベルをフォーマット rbac.authorization.k8s.io/aggregate-to-<cluster_role>: "true" で追加します。 事前定義されたクラスター役割のラベルは以下のとおりです。

    • 名前空間にスコープ設定された IAM マネージャー・サービス・アクセス役割: rbac.authorization.k8s.io/aggregate-to-admin: "true"
    • IAM ライター・サービス・アクセス役割: rbac.authorization.k8s.io/aggregate-to-edit: "true"
    • IAM リーダー・サービス・アクセス役割: rbac.authorization.k8s.io/aggregate-to-view: "true"
    rules.apiGroups "apps""batch""extensions" のように、ユーザーが対話できるようにしたい Kubernetes API グループを指定します。 REST パス api/v1 にあるコア API グループに対するアクセス権限については、[""] のようにグループをブランクにします。
    rules.resources "daemonsets""deployments""events""ingresses" など、アクセスを許可する Kubernetes リソースタイプを指定します。
    rules.verbs "get""list""describe""create""delete" など、ユーザーができるようにしたい アクションの種類を指定します。
  2. クラスター内にクラスター役割を作成します。 admin クラスター役割に対する役割バインディングを持つユーザーは、view-pod-metrics クラスター役割の追加の許可を持つようになりました。

    oc apply -f <cluster_role_file.yaml>
    
  3. admin クラスター役割を持つユーザーをフォローアップします。 クラスター構成をリフレッシュして、oc top pods などのアクションをテストするように要求してください。

RBAC 役割の確認

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

UI を使用した RBAC 役割の確認

  1. コンソールにログインします。

  2. RBAC 役割を確認するクラスターをクリックします。

  3. **「Red Hat OpenShift Web コンソール」**をクリックします。

    プライベート・ネットワーク専用のクラスターの場合、VPN 上でないとダッシュボードを開くことができない可能性があります。 プライベート・クラウド・サービス・エンドポイントを介したクラスターへのアクセスを参照するか、Satellite の場合は、Red Hat OpenShift の Satellite クラスターへのアクセスを参照してください。

  4. **「管理者 (Administrator)」パースペクティブから「ユーザー管理 (User Management)」>「ユーザー (Users)」**をクリックします。

  5. 確認するユーザーをクリックしてから、**「役割バインディング (Role Bindings)」**をクリックします。

CLI を使用した RBAC 役割の確認

  1. Red Hat OpenShift クラスターにアクセスします

  2. ユーザーが RBAC 役割に追加されていることを確認します。 対象となる役割バインディングより高い許可を持っているユーザーは、その役割バインディングに追加されません。 例えば、ユーザーがクラスター役割を割り当てられており、クラスター役割バインディング内にいる場合は、個別の名前空間の役割バインディングには追加されません。

    役割バインディングおよびクラスター役割バインディングを確認するには、クラスター管理者 (すべての名前空間のマネージャーのサービス・アクセス役割) である必要があります。

    • 読者:
      oc get rolebinding ibm-view -o yaml -n <namespace>
      
    • ライター:
      oc get rolebinding ibm-edit -o yaml -n <namespace>
      
    • 管理者 (1 つの名前空間が対象):
      oc get rolebinding ibm-operate -o yaml -n <namespace>
      
    • マネージャー、すべての名前空間:
      oc get clusterrolebinding ibm-admin -o yaml
      

出力例

ユーザー user@email.com とアクセス・グループ team1リーダーのサービス・アクセス役割を割り当てた後に oc get rolebinding ibm-view -o yaml -n default を実行すると、次の例のような出力が返されます。

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 リソース許可を示しています。

サービス役割および対応する RBAC 役割別の Kubernetes リソース許可
サービス・アクセス・ロール 対応する RBAC 役割、バインディング、およびスコープ Kubernetes リソース許可
リーダー役割 有効範囲を 1 つの名前空間に設定する場合: **ibm-view役割バインディングによってその名前空間で適用されるview**クラスター役割。
-有効範囲をすべての名前空間に設定する場合: **ibm-view役割バインディングによってクラスターの各名前空間で適用されるview**クラスター役割。 IBM Cloud コンソールおよび CLI でクラスターを表示することもできます。
-名前空間内のリソースへの読み取りアクセス権限
-役割および役割バインディングまたは Kubernetes シークレットへの読み取りアクセス権限なし
-名前空間内のリソースを表示するために Red Hat OpenShift ダッシュボードにアクセスして名前空間内のリソースを表示する。
ライター役割 1つのネームスペースにスコープされる場合: edit クラスタ・ロールは ibm-edit ロール・バインディングによって適用されます。

すべてのネームスペースにスコープされる場合: edit クラスタ・ロールは ibm-edit ロール・バインディングによって適用されます

-名前空間内のリソースに対する読み取り/書き込みアクセス権限
-役割および役割バインディングに対する読み取り/書き込みアクセス権限なし <
-Kubernetes ダッシュボードにアクセスして、名前空間内のリソースを表示します。
マネージャー役割 有効範囲を 1 つの名前空間に設定する場合: **admin役割バインディングによってその名前空間で適用されるibm-operateクラスター役割

有効範囲をすべての名前空間に設定する場合: すべての名前空間に適用される

cluster-adminクラスター役割バインディングによって適用されるibm-admin**クラスター役割

有効範囲を 1 つの名前空間に設定する場合:

  • 名前空間内のすべてのリソースに対する読み取り/書き込みアクセス、ただしリソース・クォータまたは名前空間自体への読み取り/書き込みアクセス権限はなし
  • 名前空間内で RBAC 役割および役割バインディングを作成する
  • Kubernetes ダッシュボードにアクセスして名前空間内のすべてのリソースを表示する
    有効範囲をすべての名前空間に設定する場合:
  • すべての名前空間内にあるすべてのリソースに対する読み取り/書き込みアクセス
  • 名前空間内で RBAC 役割および役割バインディングを作成する、またはすべての名前空間内でクラスター役割およびクラスター役割バインディングを作成する
  • Kubernetes ダッシュボードにアクセスする
  • アプリをだれでも利用できるようにする Ingress リソースを作成する
  • oc top podsoc top nodes、またはoc get nodesコマンドを使用した場合などのクラスター・メトリックを確認する
サービス・アクセス役割 Red Hat OpenShift クラスターのすべてのユーザーに basic-users が付与されます。

RBAC 役割ごとの Kubernetes リソース許可

IBM Cloud IAM サービス・アクセス役割が割り当てられたユーザーには必ず、対応する事前定義の Kubernetes 役割ベース・アクセス制御 (RBAC) 役割も自動的に割り当てられます。 独自のカスタム Kubernetes RBAC 役割を管理する場合は、ユーザー、グループ、またはサービス・アカウントに対するカスタム RBAC 許可の作成を参照してください。 ユーザー名について詳しくは、RBAC ユーザーの IBM Cloud IAM 発行者の詳細を参照してください。

名前空間内のリソースに対して特定の oc コマンドを実行する正しい許可があるかどうか不明な場合は、 oc auth can-i コマンドを試行します。

以下の表は、各 RBAC 役割によって個々の Kubernetes リソースに付与される許可を示しています。 パーミッションは、"get"、"list"、"describe"、"create"、"delete "など、そのロールを持つユーザがリソースに対して実行できる verbs (またはアクション)として表示されます。

各事前定義 RBAC 役割によって付与される Kubernetes リソース許可
Kubernetes リソース view edit admin および cluster-admin
bindings get、list、watch get、list、watch get、list、watch
cluster-admin のみ: create、delete、update
configmaps get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
cronjobs.batch get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
daemonsets.apps get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
daemonsets.extensions get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.apps get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.apps/rollback
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.apps/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.extensions get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.extensions/rollback
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
deployments.extensions/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
endpoints get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
events get、list、watch get、list、watch get、list、watch
horizontalpodautoscalers.autoscaling get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
ingresses.extensions get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
jobs.batch get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
limitranges get、list、watch get、list、watch get、list、watch
localsubjectaccessreviews
create
namespaces get、list、watch get、list、watch get、list、watch
cluster-admin のみ: create、delete
namespaces/status get、list、watch get、list、watch get、list、watch
networkpolicies get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
networkpolicies.extensions get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
node なし なし 1 つの名前空間を有効範囲とするadmin : なし

cluster-adminすべての名前空間の: すべての動詞

persistentvolume なし なし create、delete、 deletecollection、get、list、patch、update、watch
persistentvolumeclaims get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
poddisruptionbudgets.policy get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
pods get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、 top、patch、update、watch
pods/attach
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
pods/exec
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
pods/log get、list、watch get、list、watch get、list、watch
pods/portforward
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
pods/proxy
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
pods/status get、list、watch get、list、watch get、list、watch
replicasets.apps get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicasets.apps/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicasets.extensions get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicasets.extensions/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicationcontrollers get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicationcontrollers/scale get、list、watch cr}eate、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
replicationcontrollers/status get、list、watch get、list、watch get、list、watch
replicationcontrollers.extensions/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
resourcequotas get、list、watch get、list、watch get、list、watch
resourcequotas/status get、list、watch get、list、watch get、list、watch
rolebindings
create、delete、 deletecollection、get、list、patch、update、watch
roles
create、delete、 deletecollection、get、list、patch、update、watch
secrets
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
serviceaccounts get、list、watch create、delete、 deletecollection、get、list、patch、update、watch、 impersonate create、delete、 deletecollection、get、list、patch、update、watch、 impersonate
services get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
services/proxy
create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
statefulsets.apps get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch
statefulsets.apps/scale get、list、watch create、delete、 deletecollection、get、list、patch、update、watch create、delete、 deletecollection、get、list、patch、update、watch

RBAC ユーザーの IBM Cloud IAM 発行者の詳細

IAM で Red Hat OpenShift on IBM Cloud に対するサービス・アクセス役割を付与されたユーザーには、RBAC の対応するユーザー役割が付与されます。 RBAC ユーザーの詳細には、固有の発行者 ID、サブジェクト ID 請求、および Red Hat OpenShift ユーザー名が含まれています。 この詳細情報は、クラスターの Red Hat OpenShift のバージョンに応じて異なります。 古いバージョンからクラスターを更新すると、詳細も自動的に更新されます。 RBAC ユーザー名には、IAM# の出力などで、oc get users が接頭部として付加されます。 OpenID 認証の仕組みについての詳細は、 Red Hat OpenShift ドキュメントを参照のこと。

Red Hat OpenShift API サーバーの認証にユーザー詳細を使用しているクラスター内で自動化ツールを作成する場合に、この情報を使用することがあります。

IBM Cloud RBAC ユーザーの IAM 発行者の詳細
バージョン 発行者 クレーム 大/小文字*
Red Hat OpenShift https://iam.cloud.ibm.com/identity sub_<account_ID> 小文字

*: 小文字は「user.name@company.com」のようになります。 キャメル・ケースは「User.Name@company.com」のようになります。