10.2. 拡張機能リソースへのユーザーアクセス
クラスター拡張機能がインストールされ、Operator Lifecycle Manager (OLM) v1 によって管理されるようになると、多くの場合、拡張機能はクラスター上で新しい API リソースを公開する CustomResourceDefinition
オブジェクト (CRD) を提供できるようになります。通常、クラスター管理者はデフォルトでこれらのリソースへの完全な管理アクセス権を持ちますが、クラスター管理者以外のユーザー、つまり 通常のユーザー は十分な権限を持たない可能性があります。
OLM v1 では、インストールされた拡張機能が提供する API を通常のユーザーが操作できるように、ロールベースのアクセス制御 (RBAC) を自動的に設定または管理することはありません。クラスター管理者は、このようなユーザー向けにカスタムリソース (CR) を作成、表示、または編集するために必要な RBAC ポリシーを定義する必要があります。
拡張機能リソースへのユーザーアクセスについて説明されている RBAC 権限は、クラスター拡張機能自体の OLM v1 ベースの初期インストールを有効にするためにサービスアカウントに追加する必要がある権限とは異なります。拡張機能をインストールする際の RBAC 要件に関する詳細は、「拡張機能の管理」の「クラスター拡張機能の権限」を参照してください。
10.2.1. ユーザー用の一般的なデフォルトクラスターロール
インストールされたクラスター拡張機能には、拡張機能によって提供される API リソースに対する通常のユーザーのロールベースのアクセス制御 (RBAC) を決定するためのデフォルトのクラスターロールが含まれている場合があります。一般的なクラスターロールのセットとしては、次のようなものがあります。
view
クラスターロール- クラスター全体の指定された API リソースのすべてのカスタムリソース (CR) オブジェクトへの読み取り専用アクセスを許可します。リソースを表示する必要はあるが、リソースを変更する権限は不要な一般ユーザーを対象としています。監視目的やアクセス制限付きの表示に最適です。
edit
クラスターロール- クラスター内のすべての CR オブジェクトを変更することをユーザーに許可します。ユーザーによるリソースの作成、更新、削除を許可するものであり、リソースを管理する必要があるが、RBAC を制御したり他のユーザーの権限を管理したりする必要のないチームメンバーに適しています。
admin
クラスターロール-
クラスター全体の指定された API リソースのすべてのカスタムリソースオブジェクトについて、
create
、update
、delete
動詞を含む完全な権限を付与します。
関連情報
- User-facing roles (Kubernetes ドキュメント)
10.2.2. クラスター拡張機能によって公開される API グループとリソースの確認
クラスター拡張機能リソースへのユーザーアクセスを許可する適切な RBAC ポリシーを作成するには、インストールされた拡張機能によって公開される API グループとリソースを把握する必要があります。管理者は、OpenShift CLI (oc
) を使用して、クラスターにインストールされているカスタムリソース定義 (CRD) を調べることができます。
前提条件
- クラスター拡張機能がクラスターにインストールされている。
手順
特定のクラスター拡張機能をターゲットとするラベルセレクターを名前で指定して、その拡張機能によって所有されている CRD のみを検索しながら、インストールされている CRD をリスト表示するには、次のコマンドを実行します。
$ oc get crds -l 'olm.operatorframework.io/owner-kind=ClusterExtension,olm.operatorframework.io/owner-name=<cluster_extension_name>'
または、インストールされているすべての CRD を検索し、CRD 名で個別に調べることもできます。
次のコマンドを実行して、クラスターに現在インストールされている利用可能なすべてのカスタムリソース定義 (CRD) をリスト表示します。
$ oc get crds
探している CRD を出力で見つけます。
次のコマンドを実行して、個々の CRD をさらに調べて、その API グループを見つけます。
$ oc get crd <crd_name> -o yaml
10.2.3. カスタムロールバインディングを使用した拡張機能リソースへのユーザーアクセスの許可
クラスター管理者は、カスタムロールバインディングを使用して、ロールベースのアクセス制御 (RBAC) ポリシーを手動で作成および設定し、ユーザーに拡張機能リソースへのアクセス権を付与できます。
前提条件
- クラスター拡張機能がクラスターにインストールされている。
- API グループとリソース名のリストがある。「クラスター拡張機能によって公開される API グループとリソースの確認」の説明を参照してください。
手順
インストールされたクラスター拡張機能にデフォルトのクラスターロールがない場合は、1 つ以上のロールを手動で作成します。
「ユーザー用の一般的なデフォルトクラスターロール」で説明されているロールセットのユースケースを検討します。
たとえば、次の
ClusterRole
オブジェクト定義を 1 つ以上作成し、<cluster_extension_api_group>
と<cluster_extension_custom_resource>
を、インストールされたクラスター拡張機能によって提供される実際の API グループとリソース名に置き換えます。view-custom-resource.yaml
ファイルの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: view-custom-resource rules: - apiGroups: - <cluster_extension_api_group> resources: - <cluster_extension_custom_resources> verbs: - get - list - watch
edit-custom-resource.yaml
ファイルの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: edit-custom-resource rules: - apiGroups: - <cluster_extension_api_group> resources: - <cluster_extension_custom_resources> verbs: - get - list - watch - create - update - patch - delete
admin-custom-resource.yaml
ファイルの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: admin-custom-resource rules: - apiGroups: - <cluster_extension_api_group> resources: - <cluster_extension_custom_resources> verbs: - '*' 1
- 1
verbs
にワイルドカード (*
) を設定すると、指定したリソースに対するすべてのアクションが許可されます。
作成した YAML ファイルに対して次のコマンドを実行して、クラスターロールを作成します。
$ oc create -f <filename>.yaml
クラスターロールを個々のユーザー名またはグループ名にバインドすることで、クラスターロールを特定のユーザーまたはグループに関連付け、リソースに対する必要な権限を付与します。
すべての namespace へのアクセスを許可する クラスターロールバインディング、または特定の namespace 内でアクセスを許可する ロールバインディング のオブジェクト定義を作成します。
次のクラスターロールバインディングの例では、すべての namespace のカスタムリソースに対する読み取り専用の
view
アクセスを許可します。ユーザーの
ClusterRoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: view-custom-resource-binding subjects: - kind: User name: <user_name> roleRef: kind: ClusterRole name: view-custom-resource apiGroup: rbac.authorization.k8s.io
ユーザーの
ClusterRoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: view-custom-resource-binding subjects: - kind: Group name: <group_name> roleRef: kind: ClusterRole name: view-custom-resource apiGroup: rbac.authorization.k8s.io
次のロールバインディングでは、
edit
権限を特定の namespace に制限します。ユーザーの
RoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: edit-custom-resource-edit-binding namespace: <namespace> subjects: - kind: User name: <username> roleRef: kind: Role name: custom-resource-edit apiGroup: rbac.authorization.k8s.io
- オブジェクト定義を YAML ファイルに保存します。
以下のコマンドを実行してオブジェクトを作成します。
$ oc create -f <filename>.yaml
10.2.4. 集約されたクラスターロールを使用した拡張機能リソースへのユーザーアクセスの許可
クラスター管理者は、集約されたクラスターロールを使用して拡張機能リソースへのユーザーアクセスを許可するように、ロールベースのアクセス制御 (RBAC) ポリシーを設定できます。
既存のデフォルトのクラスターロールを自動的に拡張するには、次のラベルを 1 つ以上 ClusterRole
オブジェクトに追加して、集約ラベル を追加できます。
ClusterRole
オブジェクトの集約ラベル
# .. metadata: labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-view: "true" # ..
これにより、すでに view
、edit
、または admin
ロールを持っているユーザーが、ClusterRole
オブジェクトによって指定されたカスタムリソースとやり取りできるようになります。特定のユーザーまたはグループに、ロールまたはクラスターロールのバインディングを追加する必要はありません。
前提条件
- クラスター拡張機能がクラスターにインストールされている。
- API グループとリソース名のリストがある。「クラスター拡張機能によって公開される API グループとリソースの確認」の説明を参照してください。
手順
クラスター拡張機能によって提供される API グループとリソースを指定するクラスターロールのオブジェクト定義を作成し、集約ラベルを追加して 1 つ以上の既存のデフォルトクラスターロールを拡張します。
集約ラベルを使用した
ClusterRole
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: view-custom-resource-aggregated labels: rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: - <cluster_extension_api_group> resources: - <cluster_extension_custom_resource> verbs: - get - list - watch
create
、update
、delete
などの適切な動詞を使用して、edit
およびadmin
用の同様のClusterRole
オブジェクトを作成できます。集約ラベルを使用すると、カスタムリソースの権限がデフォルトのロールに追加されます。- オブジェクト定義を YAML ファイルに保存します。
以下のコマンドを実行してオブジェクトを作成します。
$ oc create -f <filename>.yaml
関連情報
- Aggregated ClusterRoles (Kubernetes ドキュメント)