共有リソースの使用
Shared Resources CSI Driver Operator の使用
概要
第1章 Shared Resource CSI Driver Operator
クラスター管理者は、ボリュームタイプを csi
として使用する任意の Kubernetes オブジェクトで Shared Resource Container Storage Interface (CSI) Driver を使用して、Secret
または ConfigMap
オブジェクトの内容内容が含まれるインライン一時ボリュームをプロビジョニングできます。これにより、ボリュームマウントを公開する Pod および他の Kubernetes タイプ、ならびに OpenShift Container Platform Builds は、クラスター内の namespace 全体でそれらのオブジェクトの内容を安全に使用できます。これを実現するために、現在、次の 2 種類の共有リソースが用意されています。
-
Secret
オブジェクト用のSharedSecret
カスタムリソース -
ConfigMap
オブジェクト用のSharedConfigMap
カスタムリソース
1.1. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装により、サードパーティープロバイダーは、Kubernetes のコアコードを変更することなく、標準インターフェイスを使用してストレージプラグインを提供できます。CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを Builds ユーザーに提供します。
1.2. namespace 間でのシークレットの共有
クラスター内の namespace 間でシークレットを共有するには、Secret
オブジェクトの SharedSecret
カスタムリソース (CR) インスタンスを作成します。
前提条件
-
他の namespace で共有する
Secret
オブジェクトを作成している。 次の操作を実行するための権限がある。
- クラスターにサブスクライブし、Insights Operator を通じてエンタイトルメントキーを同期する。
-
クラスタースコープレベルで
sharedsecrets.sharedresource.openshift.io
カスタムリソース定義 (CRD) のインスタンスを作成する。 -
SharedConfigMap CR
のClusterRole
オブジェクトを作成する。 -
Shared Resource CSI Driver の
Role
オブジェクトとRoleBinding
オブジェクトを作成する。 - ユーザーを制御するために、クラスター内の namespace 全体でロールとロールバインディングを管理する。
-
ロールとロールバインディングを管理して、Pod によって指定されたサービスアカウントが、
Secret
またはConfigmap
CR を参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。 - 共有するシークレットが含まれている namespace にアクセスする。
手順
次の例の設定を使用して、クラスター内の namespace 全体で参照される
Secret
を共有するSharedSecret
インスタンスを作成します。apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: shared-test-secret 1 spec: secretRef: name: test-secret namespace: <name_of_the_source_namespace>
- 1
SharedSecret
CR の名前を定義します。
次の設定例を使用して、参照される共有リソースを使用するための RBAC 権限を付与する
ClusterRole
オブジェクトを作成します。. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: use-shared-test-secret 1 rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - shared-test-secret verbs: - use
- 1
ClusterRole
CR の名前を定義します。
Shared Resources CSI Driver に
SharedSecret
オブジェクトへのアクセス権を付与するRole
オブジェクトとRoleBinding
オブジェクトを作成します。Role
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: share-etc-pki-entitlement 1 namespace: openshift-config-managed rules: - apiGroups: - "" resources: - secrets resourceNames: - etc-pki-entitlement verbs: - get - list - watch
- 1
Role
CR の名前を定義します。
RoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: share-etc-pki-entitlement 1 namespace: openshift-config-managed roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: share-etc-pki-entitlement 2 subjects: - kind: ServiceAccount name: csi-driver-shared-resource 3 namespace: openshift-builds
1.3. Pod での SharedSecret インスタンスの使用
Pod から SharedSecret
カスタムリソース (CR) にアクセスするために、サービスアカウントにロールベースのアクセス制御 (RBAC) 権限を付与します。
前提条件
-
クラスター内の namespace 間で共有する設定マップの
SharedConfigMap
CR インスタンスを作成している。 次の操作を実行するための権限がある。
-
oc get sharedconfigmaps
コマンドを入力して、SharedConfigMap
CR インスタンスのリストを取得する -
oc adm policy who-can use <sharedsecret_identifier>
コマンドを実行して、サービスアカウントがSharedSecret
CR を使用できるかどうか、およびサービスアカウントが namespace にリストされているかどうかを確認する。 -
Pod のサービスアカウントが
csi
ボリュームを使用できることを確認する。ユーザーとして Pod を作成した場合は、ユーザーがcsi
ボリュームを使用できることを確認する。
-
最後の 2 つの前提条件を満たすことができない場合は、サービスアカウントが SharedConfigMap
CR を使用できるように、クラスター管理者が必要なロールベースのアクセス制御 (RBAC) を確立することを推奨します。
手順
ロールに関連付けられた
RoleBinding
オブジェクトを作成し、共有リソースを使用する権限をサービスアカウントに付与します。次の設定例を参照してください。apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: use-shared-secret 1 namespace: app-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: use-shared-secret subjects: - kind: ServiceAccount name: <service_account_name> 2
共有リソース
csi
ドライバーを、csi
ボリュームを受け入れる Pod またはその他のリソースにマウントします。次の設定例を参照してください。apiVersion: v1 kind: Pod metadata: name: example-shared-secret namespace: <app_namespace> 1 spec: ... serviceAccountName: default volumes: - name: shared-secret csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: shared-test-secret 2
1.4. namespace 間での config map の共有
クラスター内の namespace 間で config map を共有するには、SharedConfigMap
カスタムリソース (CR) インスタンスを作成します。
前提条件
次の操作を実行するための権限がある。
-
クラスタースコープレベルで
sharedconfigmaps.sharedresource.openshift.io
カスタムリソース定義 (CRD) を作成する。 -
SharedConfigMap
CR のClusterRole
オブジェクトを作成する。 - Shared Resource Container Storage Interface (CSI) Driver のロールおよびロールバインディングを作成する。
- クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
- クラスター内の namespace 全体でロールとロールバインディングを管理し、CSI ボリュームをマウントする Pod 内のどのサービスアカウントがそれらのインスタンスを使用できるかを制御する。
- 共有するシークレットが含まれている namespace にアクセスする。
手順
クラスター内の namespace 間で共有する config map の
SharedConfigMap
CR インスタンスを作成します。次の設定例を参照してください。apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: share-test-config 1 spec: configMapRef: name: shared-config namespace: <name_of_the_source_namespace> 2
次の設定例を使用して、参照される共有リソースを使用するためのロールベースのアクセス制御 (RBAC) 権限を付与する
ClusterRole
CR インスタンスを作成します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <cluster_role_name> 1 rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - share-test-config 2 verbs: - use
CSI Driver に config map へのアクセス権を付与するための
Role
およびRoleBinding
オブジェクトを作成します。Role
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-test-config namespace: test-share-source 1 rules: - apiGroups: [""] resources: ["configmaps"] resourceNames: ["shared-config"] verbs: ["get", "list", "watch"]
- 1
- ソース namespace の名前を定義します。
RoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: shared-test-config namespace: test-share-source 1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: shared-test-config subjects: 2 - kind: ServiceAccount name: csi-driver-shared-resource namespace: openshift-builds
1.5. Pod での SharedConfigMap インスタンスの使用
Pod から SharedConfigMap
カスタムリソース (CR) インスタンスにアクセスするには、その SharedConfigMap
CR インスタンスを使用するためのロールベースのアクセス制御 (RBAC) 権限を特定のサービスアカウントに付与します。
前提条件
-
クラスター内の namespace 間で共有する設定マップの
SharedConfigMap
CR インスタンスを作成している。 次の操作を実行するための権限がある。
-
oc get sharedconfigmaps
コマンドを入力して、SharedConfigMap
CR インスタンスのリストを取得する -
oc adm policy who-can use <sharedsecret_identifier>
コマンドを実行して、サービスアカウントがSharedSecret
CR を使用できるかどうか、およびサービスアカウントが namespace にリストされているかどうかを確認する。 -
Pod のサービスアカウントが
csi
ボリュームを使用できることを確認する。ユーザーとして Pod を作成した場合は、ユーザーがcsi
ボリュームを使用できることを確認する。
-
最後の 2 つの前提条件を満たすことができない場合は、サービスアカウントが SharedConfigMap
CR を使用できるように、クラスター管理者が必要なロールベースのアクセス制御 (RBAC) を確立することを推奨します。
手順
ロールに関連付けられた
RoleBinding
オブジェクトを作成し、共有リソースを使用する権限をサービスアカウントに付与します。次の設定例を参照してください。apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: use-shared-config namespace: <app_namespace> 1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: use-shared-config subjects: - kind: ServiceAccount name: <service_account_name> 2
共有リソース
csi
ドライバーを、csi
ボリュームを受け入れる Pod またはその他のリソースにマウントします。次の設定例を参照してください。apiVersion: v1 kind: Pod metadata: name: example-shared-config namespace: <app_namespace> 1 spec: ... serviceAccountName: default volumes: - name: shared-config csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: share-test-config 2
1.6. volumeAttributes を検証する条件
1 つのボリュームの volumeAttributes
フィールドで、sharedSecret
属性または sharedConfigMap
属性のいずれかを、SharedSecret
インスタンスまたは SharedConfigMap
インスタンスの値に設定する必要があります。設定しないと、Pod の起動中にボリュームがプロビジョニングされるときに、検証チェックによって kubelet にエラーが返されます。Pod の共有リソースボリュームをプロビジョニングするために、次の条件を確認してください。
-
sharedSecret
属性とsharedConfigMap
属性の値を指定する必要があります。 -
sharedSecret
属性とsharedConfigMap
属性の値は、カスタムリソース (CR) の名前と一致する必要があります。
1.7. OpenShift サブスクリプションのエンタイトルメントを使用したイメージのビルド
共有リソース、Insights Operator、および builds for Red Hat OpenShift 間の統合により、Red Hat サブスクリプション (RHEL エンタイトルメント) を builds for Red Hat OpenShift で簡単に使用できます。
OpenShift Container Platform 4.10 以降、builds for Red Hat OpenShift では、共有リソースと Insights Operator によって提供される Simple Content Access 機能を参照して、Red Hat サブスクリプション (RHEL エンタイトルメント) を使用できます。
-
Simple Content Access 機能は、サブスクリプションの認証情報を既知の
Secret
オブジェクトにインポートします。 -
クラスター管理者は、
Secret
オブジェクトを使用してSharedSecret
カスタムリソース (CR) を作成し、プロジェクトまたは namespace に権限を付与します。クラスター管理者は、builder
サービスアカウントにSharedSecret
CR を使用する権限を付与します。 -
これらのプロジェクトまたは namespace 内で実行されるビルドは、
SharedSecret
CR インスタンスとそのエンタイトルメントが適用される RHEL コンテンツを参照する Container Storage Interface (CSI) ボリュームをマウントできます。
1.8. SharedSecret オブジェクトを使用したビルドの実行
SharedSecret
オブジェクトを使用すると、ビルドでクラスターの RHEL エンタイトルメントキーにセキュアにアクセスできます。SharedSecret
オブジェクトを使用すると、namespace 間でシークレットを共有および同期できます。
前提条件
次の操作を実行するための権限がある。
- ビルド設定を作成し、ビルドを開始する。
-
SharedSecret
オブジェクトを作成する。 -
oc get sharedsecrets
コマンドを入力して空でないリストを取得することにより、使用可能なSharedSecret
カスタムリソース (CR) インスタンスを検出する。 -
oc adm policy who-can use <sharedsecret_identifier>
コマンドを実行して、サービスアカウントがSharedSecret
CR を使用できるかどうか、およびサービスアカウントが namespace にリストされているかどうかを確認する。
最後の 2 つの前提条件を満たすことができない場合は、サービスアカウントによる SharedSecret
CR の使用を許可できるように、クラスター管理者が必要なロールベースのアクセス制御 (RBAC) を確立することが推奨されます。
手順
次のコマンドを実行して、クラスターのエンタイトルメントシークレットを含む
SharedSecret
オブジェクトインスタンスを作成します。$ oc apply -f -<<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: etc-pki-entitlement spec: secretRef: name: etc-pki-entitlement namespace: openshift-config-managed EOF
次の例の設定を使用して、
SharedSecret
オブジェクトにアクセスする権限を付与するClusterRole
オブジェクトを作成します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: use-share-etc-pki-entitlement 1 rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - etc-pki-entitlement verbs: - use
- 1
ClusterRole
CR の名前を定義します。
Shared Resources CSI Driver に
SharedSecret
オブジェクトにアクセスする権限を付与するRole
およびRoleBinding
オブジェクトを作成します。Role
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: share-etc-pki-entitlement 1 namespace: openshift-config-managed rules: - apiGroups: - "" resources: - secrets resourceNames: - etc-pki-entitlement verbs: - get - list - watch
- 1
Role
CR の名前を定義します。
RoleBinding
オブジェクトの例apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: share-etc-pki-entitlement 1 namespace: openshift-config-managed roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: share-etc-pki-entitlement subjects: - kind: ServiceAccount name: csi-driver-shared-resource namespace: openshift-builds 2
ビルドが実行される namespace に、
builder
およびpipeline
サービスアカウントのRoleBinding
オブジェクトを作成します。apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: use-share-etc-pki-entitlement 1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: use-share-etc-pki-entitlement subjects: - kind: ServiceAccount name: pipeline - kind: ServiceAccount name: builder
- 1
builder
およびpipeline
サービスアカウントのRoleBinding
CR の名前を定義します。
注記SharedSecret
オブジェクトを使用するサービスアカウントは、OpenShift コントローラーによって作成および管理されます。buildah
ビルドストラテジーを使用してSharedSecret
オブジェクトをマウントします。以下の例を参照してください。$ oc apply -f -<<EOF apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-rhel spec: source: type: Git git: url: https://github.com/redhat-openshift-builds/samples contextDir: buildah-build strategy: name: buildah kind: ClusterBuildStrategy paramValues: - name: dockerfile value: DockerFile volumes: - csi: driver: csi.sharedresource.openshift.io readOnly: true 1 volumeAttributes: sharedSecret: <sharedsecret_object_name> 2 name: etc-pki-entitlement output: image: <output_image_location> 3 EOF
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.