6.3. Shared Resource CSI Driver Operator
クラスター管理者は、OpenShift Container Platform で Shared Resource CSI Driver を使用して、Secret または ConfigMap オブジェクトの内容が含まれるインライン一時ボリュームをプロビジョニングできます。これにより、ボリュームマウントを公開する Pod および他の Kubernetes タイプ、ならびに OpenShift Container Platform Builds は、クラスター内の namespace 全体でそれらのオブジェクトの内容を安全に使用できます。そのために、現在、SharedSecret カスタムリソース (Secret オブジェクト用) および SharedConfigMap カスタムリソース ConfigMap オブジェクト用) という 2 種類の共有リソースがあります。
Shared Resource CSI Driver は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Shared Resource CSI Driver を有効にするには、フィーチャーゲートを使用して機能を有効化 する必要があります。
6.3.1. CSI について リンクのコピーリンクがクリップボードにコピーされました!
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
6.3.2. namespace 間でのシークレットの共有 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の namespace 間でシークレットを共有するには、共有する Secret オブジェクトの SharedSecret カスタムリソース (CR) インスタンスを作成します。
前提条件
次のアクションを実行するためのパーミッションがある。
-
cluster スコープレベルで
sharedsecrets.sharedresource.openshift.ioカスタムリソース定義 (CRD) のインスタンスを作成する。 - クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
-
ロールおよびロールバインディングを管理し、Pod で指定されたサービスアカウントが、使用する
SharedSecretCR インスタンスを参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。 - 共有する Secret が含まれる namespace にアクセスする。
手順
クラスター内の namespace 間で共有する
SecretオブジェクトのSharedSecretCR インスタンスを作成します。oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: my-share spec: secretRef: name: <name of secret> namespace: <namespace of secret> EOF$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: my-share spec: secretRef: name: <name of secret> namespace: <namespace of secret> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3. Pod での SharedSecret インスタンスの使用 リンクのコピーリンクがクリップボードにコピーされました!
Pod から SharedSecret カスタムリソース (CR) インスタンスにアクセスするには、その SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。
前提条件
-
クラスター内の namespace 間で共有する Secret の
SharedSecretCR インスタンスを作成している。 次のアクションを実行するためのパーミッションがある。
-
oc get sharedsecretsコマンドを入力し、空でないリストを取得して、使用可能なSharedSecretCR インスタンスを見つけます。 -
Pod が指定するサービスアカウントが、指定された
SharedSecretCR インスタンスの使用を許可されているかどうかを判断します。つまり、oc adm policy who-can use <identifier of specific SharedSecret>実行して、namespace のサービスアカウントが一覧に表示されるかどうかを確認できます。 -
Pod が指定するサービスアカウントが
csiボリュームの使用を許可されているかどうか、または Pod を直接作成したリクエストユーザーとしてcsiボリュームの使用が許可されているかどうかを確認します。詳細は、「Pod セキュリティーアドミッションの理解と管理」を参照してください。
-
このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedSecret CR インスタンスを検出し、サービスアカウントを有効にして SharedSecret CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。
手順
YAML コンテンツと共に
oc applyを使用して、その Pod でSharedSecretCR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。注記現在、
kubectlとocには、use動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …を使用して、SharedSecretCR インスタンスの使用に必要なロールを作成することはできません。oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - my-share verbs: - use EOF$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - my-share verbs: - use EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow ocコマンドを使用して、ロールに関連付けられたRoleBindingを作成します。oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
$ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod から
SharedSecretCR インスタンスにアクセスします。oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: my-share EOF$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: my-share EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.4. namespace 間での設定マップの共有 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の namespace 間で設定マップを共有するには、その設定マップの SharedConfigMap カスタムリソース (CR) インスタンスを作成します。
前提条件
次のアクションを実行するためのパーミッションがある。
-
cluster スコープレベルで
sharedconfigmaps.sharedresource.openshift.ioカスタムリソース定義 (CRD) のインスタンスを作成する。 - クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
- クラスター内の namespace 全体でロールおよびロールバインディングを管理し、Container Storage Interface (CSI) ボリュームをマウントする Pod のどのサービスアカウントが、それらのインスタンスを使用できるかを制御する。
- 共有する Secret が含まれる namespace にアクセスする。
手順
クラスター内の namespace 間で共有する設定マップの
SharedConfigMapCR インスタンスを作成します。oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: my-share spec: configMapRef: name: <name of configmap> namespace: <namespace of configmap> EOF$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: my-share spec: configMapRef: name: <name of configmap> namespace: <namespace of configmap> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.5. Pod での SharedConfigMap インスタンスの使用 リンクのコピーリンクがクリップボードにコピーされました!
次のステップ
Pod から SharedConfigMap カスタムリソース (CR) インスタンスにアクセスするには、その SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。
前提条件
-
クラスター内の namespace 間で共有する設定マップの
SharedConfigMapCR インスタンスを作成している。 次のアクションを実行するためのパーミッションがある。
-
oc get sharedconfigmapsコマンドを入力し、空でないリストを取得して、使用可能なSharedConfigMapCR インスタンスを検出します。 -
Pod が指定するサービスアカウントが、指定された
SharedSecretCR インスタンスの使用を許可されているかどうかを判断します。つまり、oc adm policy who-can use <identifier of specific SharedSecret>実行して、namespace のサービスアカウントが一覧に表示されるかどうかを確認できます。 -
Pod が指定するサービスアカウントが
csiボリュームの使用を許可されているかどうか、または Pod を直接作成したリクエストユーザーとしてcsiボリュームの使用が許可されているかどうかを確認します。詳細は、「Pod セキュリティーアドミッションの理解と管理」を参照してください。
-
このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedConfigMap CR インスタンスを検出し、サービスアカウントを有効にして SharedConfigMap CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。
手順
YAML コンテンツと共に
oc applyを使用して、その Pod でSharedConfigMapCR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。注記現在、
kubectlとocには、use動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …を使用して、SharedConfigMapCR インスタンスの使用に必要なロールを作成することはできません。oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - my-share verbs: - use EOF$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - my-share verbs: - use EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow ocコマンドを使用して、ロールに関連付けられたRoleBindingを作成します。oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod から
SharedConfigMapCR インスタンスにアクセスします。oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: my-share EOF$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: my-share EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.6. Shared Resource CSI Driver に対するその他のサポート制限 リンクのコピーリンクがクリップボードにコピーされました!
Shared Resource CSI Driver には、以下の重要な制限があります。
- ドライバーは、Container Storage Interface (CSI) のインライン一時ボリュームの制限の対象となります。
-
readOnlyフィールドの値はtrueである必要があります。Podの作成時に、readOnlyがfalseの場合、検証受付 Webhook は Pod の作成を拒否します。なんらかの理由で検証用アドミッション Webhook に接続できない場合、Pod の起動中のボリュームプロビジョニングで、ドライバーは kubelet にエラーを返します。readOnlyがtrueであることを要求することは、アップストリームの Kubernetes CSI ドライバーが関連するボリュームに SELinux ラベルを適用するための提案されたベストプラクティスに沿っています。 -
ドライバーは、
tmpfsボリュームしかサポートしないため、FSTypeフィールドを無視します。 -
ドライバーは
NodePublishSecretRefフィールドを無視します。代わりに、ドライバーはuse動詞でSubjectAccessReviewsを使用して、Pod がSharedSecretまたはSharedConfigMapカスタムリソース (CR) インスタンスが含まれるボリュームを取得できるかどうかを評価します。 -
名前が
openshiftで始まるSharedSecretまたはSharedConfigMapカスタムリソース (CR) インスタンスを作成することはできません。
6.3.7. 共有リソース Pod ボリュームの VolumeAttributes に関する追加情報 リンクのコピーリンクがクリップボードにコピーされました!
以下の属性は、さまざまな形で共有リソース Pod ボリュームに影響を及ぼします。
-
volumeAttributesプロパティーのrefreshResource属性。 -
Shared Resource CSI Driver 設定の
refreshResources属性。 -
volumeAttributesプロパティーのsharedSecretおよびsharedConfigMap属性。
6.3.7.1. refreshResource 属性 リンクのコピーリンクがクリップボードにコピーされました!
Shared Resource CSI Driver は、ボリュームの volumeAttributes プロパティーの refreshResource 属性を尊重します。この属性は、Pod 起動の一環としてボリュームが初回にプロビジョニングされた 後 に、基礎となる Secret または ConfigMap オブジェクトの内容に対する更新がボリュームにコピーされるかどうかを制御します。refreshResource のデフォルト値は true です。これは、コンテンツが更新されることを意味します。
Shared Resource CSI Driver 設定により、共有 SharedSecret および SharedConfigMap カスタムリソース (CR) インスタンス両方の更新が無効にされている場合、volumeAttribute プロパティーの refreshResource 属性は影響を及ぼしません。この属性の目的は、更新が一般的に許可されている場合に、特定のボリュームマウントの更新を無効にすることです。
6.3.7.2. refreshResources 属性 リンクのコピーリンクがクリップボードにコピーされました!
グローバルスイッチを使用して、共有リソースの更新を有効または無効にできます。このスイッチは Shared Resource CSI Driver の csi-driver-shared-resource-config 設定マップの refreshResources 属性で、openshift-cluster-csi-drivers namespace で確認できます。この refreshResources 属性を false に設定する場合、ボリュームに保存されている Secret または ConfigMap オブジェクト関連のコンテンツは、ボリュームの初回プロビジョニング後に更新されません。
この Shared Resource CSI Driver 設定を使用して更新を無効にすると、ボリュームの volumeAttributes プロパティーの refreshResource 属性に関係なく、Shared Resource CSI Driver を使用するすべてのクラスターのボリュームマウントが影響を受けます。
6.3.7.3. Pod の共有リソースボリュームをプロビジョニングする前の volumeAttributes の検証 リンクのコピーリンクがクリップボードにコピーされました!
1 つのボリュームの volumeAttributes で、sharedSecret または sharedConfigMap 属性いずれかの値を、SharedSecret または SharedConfigMap CS インスタンスの値に設定する必要があります。設定しないと、Pod の起動時にボリュームがプロビジョニングされる際に、検証でそのボリュームの volumeAttributes がチェックされ、以下の条件下では kubelet にエラーが返されます。
-
sharedSecretおよびsharedConfigMap属性の両方に値が指定されている。 -
sharedSecretおよびsharedConfigMap属性の両方に値が指定されていない。 -
sharedSecretまたはsharedConfigMap属性の値が、クラスター内のSharedSecretまたはSharedConfigMapCR インスタンスの名前に対応していない。
6.3.8. 共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーション リンクのコピーリンクがクリップボードにコピーされました!
共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーションにより、Red Hat サブスクリプション (RHEL エンタイトルメント) を OpenShift Container Platform Builds で簡単に使用できます。
従来、OpenShift Container Platform 4.9.x 以前では、認証情報を手動でインポートし、ビルドを実行している各プロジェクトまたは namespace にコピーしていました。
OpenShift Container Platform 4.10 以降では、OpenShift Container Platform Builds では、共有リソースおよび Insights Operator によって提供される単純なコンテンツアクセス機能を参照して、Red Hat サブスクリプション (RHEL エンタイトルメント) を使用できるようになりました。
-
シンプルなコンテンツアクセス機能は、サブスクリプションの認証情報を、既知の
Secretオブジェクトにインポートします。以下の「関連情報」セクションのリンクを参照してください。 -
クラスター管理者は、その
Secretオブジェクトに関するSharedSecretカスタムリソース (CR) インスタンスを作成し、特定のプロジェクトまたは namespace にパーミッションを付与します。特に、クラスター管理者は、そのSharedSecretCR インスタンスを使用するための、builderサービスアカウントパーミッションを付与します。 -
それらのプロジェクトまたは namespace 内で実行されるビルドは、
SharedSecretCR インスタンスおよびそのエンタイトルメントが適用された RHEL コンテンツを参照する CSI Volume をマウントできます。