共有リソースの使用


builds for Red Hat OpenShift 1.4

Shared Resources CSI Driver Operator の使用

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Shared Resources CSI Driver を使用する手順の例を示します。

第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 CRClusterRole オブジェクトを作成する。
    • Shared Resource CSI Driver の Role オブジェクトと RoleBinding オブジェクトを作成する。
    • ユーザーを制御するために、クラスター内の namespace 全体でロールとロールバインディングを管理する。
    • ロールとロールバインディングを管理して、Pod によって指定されたサービスアカウントが、Secret または Configmap CR を参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。
    • 共有するシークレットが含まれている namespace にアクセスする。

手順

  1. 次の例の設定を使用して、クラスター内の 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 の名前を定義します。
  2. 次の設定例を使用して、参照される共有リソースを使用するための 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 の名前を定義します。
  3. 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
    RoleBinding CR の名前を定義します。
    2
    Role CR の名前を定義します。
    3
    ServiceAccount CR の名前を定義します。

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) を確立することを推奨します。

手順

  1. ロールに関連付けられた 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
    1
    RoleBinding CR の名前を定義します。
    2
    アプリケーションのサービスアカウント名を指定します。
  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
    <app_namespace> は、アプリケーションの namespace 名に置き換えます。
    2
    sharedSecret 属性の値を定義します。この値は、SharedSecret CR の名前と同じである必要があります。

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 にアクセスする。

手順

  1. クラスター内の 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
    1
    SharedConfigMap CR の名前を定義します。
    2
    <name_of_the_source_namespace> は、ソース 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
    1
    <cluster_role_name> は、クラスターロールの名前に置き換えます。
    2
    SharedSecret CR の名前を定義します。
  3. 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
    ソース namespace の名前を定義します。
    2
    Shared Resource CSI Driver DaemonSet 用のサービスアカウントのリストを定義します。Builds for OpenShift を使用してデプロイすると、サービスアカウント名は csi-driver-shared-resource になり、namespace は Builds for OpenShift Operator がデプロイされる場所と同じになります。

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) を確立することを推奨します。

手順

  1. ロールに関連付けられた 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
    1
    <app_namespace> は、アプリケーションの namespace 名に置き換えます。
    2
    アプリケーションのサービスアカウント名を指定します。
  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
    <app_namespace> は、アプリケーションの namespace 名に置き換えます。
    2
    sharedConfigMap オブジェクトの名前を定義します。

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) を確立することが推奨されます。

手順

  1. 次のコマンドを実行して、クラスターのエンタイトルメントシークレットを含む 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
  2. 次の例の設定を使用して、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 の名前を定義します。
  3. 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

    1
    RoleBinding CR の名前を定義します。
    2
    openshift-builds がインストールされている namespace の名前を定義します。
  4. ビルドが実行される 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 コントローラーによって作成および管理されます。

  5. 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
1
ビルドで共有リソースをマウントするには、readOnlytrue に設定する必要があります。
2
ビルドに含める SharedSecret オブジェクトの名前を指定します。
3
ビルドしたイメージをプッシュする場所を指定します。

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.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.