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 役割バインディングに対して行った変更は、更新時に保持されません。
クラスター役割 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 許可を作成するには、以下のようにします。
-
以下のような
.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"
など、ユーザーができるようにしたい アクションの種類を指定します。 -
クラスター内に役割またはクラスター役割を作成します。
oc apply -f my_role.yaml
-
役割またはクラスター役割が作成されたことを確認します。
- 役割:
oc get roles -n <namespace>
- クラスター役割:
oc get clusterroles
- 役割:
-
.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
を使用します。 -
クラスター内に役割バインディングまたはクラスター役割バインディングのリソースを作成します。
oc apply -f my_role_binding.yaml
-
バインディングが作成されたことを確認します。
oc get rolebinding -n <namespace>
-
オプション: 他の名前空間で同じレベルのユーザー・アクセスを実行するには、他の名前空間にこれらの役割またはクラスター役割に対する役割バインディングをコピーします。
- 役割バインディングを、ある名前空間から別の名前空間にコピーします。
例えば、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 -
- 役割バインディングがコピーされたことを確認します。 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 クラスターにアクセスします。
-
クラスター役割の 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"
など、ユーザーができるようにしたい アクションの種類を指定します。 - 名前空間にスコープ設定された IAM マネージャー・サービス・アクセス役割:
-
クラスター内にクラスター役割を作成します。
admin
クラスター役割に対する役割バインディングを持つユーザーは、view-pod-metrics
クラスター役割の追加の許可を持つようになりました。oc apply -f <cluster_role_file.yaml>
-
admin
クラスター役割を持つユーザーをフォローアップします。 クラスター構成をリフレッシュして、oc top pods
などのアクションをテストするように要求してください。
RBAC 役割の確認
Red Hat OpenShift on IBM Cloud クラスターで、カスタム RBAC を確認したり、RBAC 役割に同期される IAM のサービス・アクセス権限を確認したりできます。
UI を使用した RBAC 役割の確認
-
コンソールにログインします。
-
RBAC 役割を確認するクラスターをクリックします。
-
**「Red Hat OpenShift Web コンソール」**をクリックします。
プライベート・ネットワーク専用のクラスターの場合、VPN 上でないとダッシュボードを開くことができない可能性があります。 プライベート・クラウド・サービス・エンドポイントを介したクラスターへのアクセスを参照するか、Satellite の場合は、Red Hat OpenShift の Satellite クラスターへのアクセスを参照してください。
-
**「管理者 (Administrator)」パースペクティブから「ユーザー管理 (User Management)」>「ユーザー (Users)」**をクリックします。
-
確認するユーザーをクリックしてから、**「役割バインディング (Role Bindings)」**をクリックします。
CLI を使用した RBAC 役割の確認
-
ユーザーが 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 リソース許可 |
---|---|---|
リーダー役割 | 有効範囲を 1 つの名前空間に設定する場合: **ibm-view 役割バインディングによってその名前空間で適用されるview **クラスター役割。-有効範囲をすべての名前空間に設定する場合: ** ibm-view 役割バインディングによってクラスターの各名前空間で適用されるview **クラスター役割。
IBM Cloud コンソールおよび CLI でクラスターを表示することもできます。 |
-名前空間内のリソースへの読み取りアクセス権限 -役割および役割バインディングまたは Kubernetes シークレットへの読み取りアクセス権限なし -名前空間内のリソースを表示するために Red Hat OpenShift ダッシュボードにアクセスして名前空間内のリソースを表示する。 |
ライター役割 | 1つのネームスペースにスコープされる場合: edit クラスタ・ロールは ibm-edit ロール・バインディングによって適用されます。
すべてのネームスペースにスコープされる場合: |
-名前空間内のリソースに対する読み取り/書き込みアクセス権限 -役割および役割バインディングに対する読み取り/書き込みアクセス権限なし < -Kubernetes ダッシュボードにアクセスして、名前空間内のリソースを表示します。 |
マネージャー役割 | 有効範囲を 1 つの名前空間に設定する場合: **admin 役割バインディングによってその名前空間で適用されるibm-operate クラスター役割
有効範囲をすべての名前空間に設定する場合: すべての名前空間に適用される cluster-admin クラスター役割バインディングによって適用されるibm-admin **クラスター役割 |
有効範囲を 1 つの名前空間に設定する場合:
|
サービス・アクセス役割 | 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
(またはアクション)として表示されます。
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 : なし
|
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 サーバーの認証にユーザー詳細を使用しているクラスター内で自動化ツールを作成する場合に、この情報を使用することがあります。
バージョン | 発行者 | クレーム | 大/小文字* |
---|---|---|---|
Red Hat OpenShift | https://iam.cloud.ibm.com/identity |
sub_<account_ID> |
小文字 |
*
: 小文字は「user.name@company.com
」のようになります。 キャメル・ケースは「User.Name@company.com
」のようになります。