5.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 を有効にするには、フィーチャーゲートを使用して機能を有効にする 必要があります。

5.3.1. CSI について

ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。

CSI Operator は、in-tree (インツリー) ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。

5.3.2. namespace 間でのシークレットの共有

クラスター内の namespace 間でシークレットを共有するには、共有する Secret オブジェクトの SharedSecret カスタムリソース (CR) インスタンスを作成します。

前提条件

次のアクションを実行するためのパーミッションがある。

  • cluster スコープレベルで sharedsecrets.sharedresource.openshift.io カスタムリソース定義 (CRD) のインスタンスを作成する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
  • ロールおよびロールバインディングを管理し、Pod で指定されたサービスアカウントが、使用する SharedSecret CR インスタンスを参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。
  • 共有する Secret が含まれる namespace にアクセスする。

手順

  • クラスター内の namespace 間で共有する Secret オブジェクトの SharedSecret CR インスタンスを作成します。

    $ 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

5.3.3. Pod での SharedSecret インスタンスの使用

Pod から SharedSecret カスタムリソース (CR) インスタンスにアクセスするには、その SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

前提条件

  • クラスター内の namespace 間で共有する Secret の SharedSecret CR インスタンスを作成している。
  • 次のアクションを実行するためのパーミッションがある。

    • ビルド設定を作成し、ビルドを開始します。
    • oc get sharedsecretsコマンドを入力し、空でないリストを取得して、使用可能なSharedSecret CR インスタンスを見つけます。
    • namespace で利用可能な builder サービスアカウントが指定の SharedSecret CR インスタンスを使用できるかどうかを判別します。つまり、oc adm policy who-can use <identifier of specific SharedSecret> 実行して、namespace の builder サービスアカウントが一覧に表示されるかどうかを確認できます。
注記

このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedSecret CR インスタンスを検出し、サービスアカウントを有効にして SharedSecret CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。

手順

  1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

    注記

    現在、 kubectlocには、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedSecret CR インスタンスの使用に必要なロールを作成することはできません。

    $ 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
  2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
  3. Pod から SharedSecret CR インスタンスにアクセスします。

    $ 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

5.3.4. namespace 間での設定マップの共有

クラスター内の namespace 間で設定マップを共有するには、その設定マップの SharedConfigMap カスタムリソース (CR) インスタンスを作成します。

前提条件

次のアクションを実行するためのパーミッションがある。

  • cluster スコープレベルで sharedconfigmaps.sharedresource.openshift.io カスタムリソース定義 (CRD) のインスタンスを作成する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、Container Storage Interface (CSI) ボリュームをマウントする Pod のどのサービスアカウントが、それらのインスタンスを使用できるかを制御する。
  • 共有する Secret が含まれる namespace にアクセスする。

手順

  1. クラスター内の namespace 間で共有する設定マップの SharedConfigMap CR インスタンスを作成します。

    $ 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

5.3.5. Pod での SharedConfigMap インスタンスの使用

次のステップ

Pod から SharedConfigMap カスタムリソース (CR) インスタンスにアクセスするには、その SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

前提条件

  • クラスター内の namespace 間で共有する設定マップの SharedConfigMap CR インスタンスを作成している。
  • 次のアクションを実行するためのパーミッションがある。

    • ビルド設定を作成し、ビルドを開始します。
    • oc get sharedconfigmapsコマンドを入力し、空でないリストを取得して、使用可能なSharedConfigMap CR インスタンスを検出します。
    • namespace で利用可能な builder サービスアカウントが指定の SharedSecret CR インスタンスを使用できるかどうかを判別します。つまり、oc adm policy who-can use <identifier of specific SharedSecret> 実行して、namespace の builder サービスアカウントが一覧に表示されるかどうかを確認できます。
注記

このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedConfigMap CR インスタンスを検出し、サービスアカウントを有効にして SharedConfigMap CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。

手順

  1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

    注記

    現在、 kubectlocには、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedConfigMap CR インスタンスの使用に必要なロールを作成することはできません。

    $ 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
  2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

    oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
  3. Pod から SharedConfigMap CR インスタンスにアクセスします。

    $ 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

5.3.6. Shared Resource CSI Driver に対するその他のサポート制限

Shared Resource CSI Driver には、以下の重要な制限があります。

  • ドライバーは、Container Storage Interface (CSI) のインライン一時ボリュームの制限の対象となります。
  • readOnly フィールドの値は true である必要があります。そうでない場合には、Pod 起動時のボリュームのプロビジョニング時に、ドライバーはエラーを kubelet に返します。この制限は、関連するボリュームへの SELinux ラベルの適用に関して、アップストリームの Kubernetes CSI Driver で提案されたベストプラクティスに対応するためのものです。
  • ドライバーは、tmpfs ボリュームしかサポートしないため、FSType フィールドを無視します。
  • ドライバーは NodePublishSecretRef フィールドを無視します。代わりに、ドライバーはuse動詞で SubjectAccessReviews を使用して、Pod が SharedSecret または SharedConfigMap カスタムリソース (CR) インスタンスが含まれるボリュームを取得できるかどうかを評価します。

5.3.7. 共有リソース Pod ボリュームの VolumeAttributes に関する追加情報

以下の属性は、さまざまな形で共有リソース Pod ボリュームに影響を及ぼします。

  • volumeAttributes プロパティーの refreshResource 属性。
  • Shared Resource CSI Driver 設定の refreshResources 属性。
  • volumeAttributes プロパティーの sharedSecret および sharedConfigMap 属性。

5.3.7.1. refreshResource 属性

Shared Resource CSI Driver は、ボリュームの volumeAttributes プロパティーの refreshResource 属性を尊重します。この属性は、Pod 起動の一環としてボリュームが初回にプロビジョニングされた に、基礎となる Secret または ConfigMap オブジェクトの内容に対する更新がボリュームにコピーされるかどうかを制御します。refreshResource のデフォルト値は true です。これは、コンテンツが更新されることを意味します。

重要

Shared Resource CSI Driver 設定により、共有 SharedSecret および SharedConfigMap カスタムリソース (CR) インスタンス両方の更新が無効にされている場合、volumeAttribute プロパティーの refreshResource 属性は影響を及ぼしません。この属性の目的は、更新が一般的に許可されている場合に、特定のボリュームマウントの更新を無効にすることです。

5.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 を使用するすべてのクラスターのボリュームマウントが影響を受けます。

5.3.7.3. Pod の共有リソースボリュームをプロビジョニングする前の volumeAttributes の検証

1 つのボリュームの volumeAttributes で、sharedSecret または sharedConfigMap 属性いずれかの値を、SharedSecret または SharedConfigMap CS インスタンスの値に設定する必要があります。設定しないと、Pod の起動時にボリュームがプロビジョニングされる際に、検証でそのボリュームの volumeAttributes がチェックされ、以下の条件下では kubelet にエラーが返されます。

  • sharedSecret および sharedConfigMap 属性の両方に値が指定されている。
  • sharedSecret および sharedConfigMap 属性の両方に値が指定されていない。
  • sharedSecret または sharedConfigMap 属性の値が、クラスター内の SharedSecret または SharedConfigMap CR インスタンスの名前に対応していない。

5.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 にパーミッションを付与します。特に、クラスター管理者は、その SharedSecret CR インスタンスを使用するための、builder サービスアカウントパーミッションを付与します。
  • それらのプロジェクトまたは namespace 内で実行されるビルドは、SharedSecret CR インスタンスおよびそのエンタイトルメントが適用された RHEL コンテンツを参照する CSI Volume をマウントできます。