Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 1. Shared Resource CSI Driver

To securely share Secret and ConfigMap objects across namespaces, use the Shared Resource Container Storage Interface (CSI) driver with the csi volume type. This driver provisions inline ephemeral volumes, enabling pods and Builds to utilize these shared configuration resources.

1.1. Sharing a Secret object across namespaces
Copier lien

A SharedSecret custom resource (CR) enables secure sharing of Secret objects containing sensitive information like passwords, OAuth tokens, and SSH keys across namespaces within a cluster. This eliminates manual duplication and provides a single source for sensitive data with controlled access.

1.1.1. Creating a SharedSecret custom resource
Copier lien

Create a SharedSecret custom resource (CR) to share a Secret object across namespaces. By creating a SharedSecret custom resource (CR), you can share a Secret object across namespaces, ensuring that sensitive configuration data remains consistently accessible cluster-wide.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as an administrator.
  • You have created a Secret object that you want to share in other namespaces. To create a Secret object, see "Creating Secrets".
  • You have subscribed to the cluster and have entitlement keys synced through the Insights Operator.

  • You must have permissions to perform the following actions:

    • Create the sharedsecrets.sharedresource.openshift.io CR at a cluster-scoped level.
    • Create the ClusterRole object for the SharedSecret CR.
    • Create the Role and RoleBinding objects for the Shared Resource CSI Driver.
    • Manage roles and role bindings across the namespaces in the cluster to control users.
    • Manage roles and role bindings so that the service account specified by a pod can use the SharedSecret CR to mount a CSI volume that references a Secret object.
    • Access to the namespaces that contain the Secret object you want to share.

Procedure

  1. Create the Role and RoleBinding objects that grant the Shared Resource CSI driver the permission to access the SharedSecret object by using the following example configurations:

    Example Role object

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: share-etc-pki-entitlement
  namespace: openshift-config-managed
rules:
  - apiGroups:
      - ""
    resources:
      - secrets
    resourceNames:
      - etc-pki-entitlement
    verbs:
      - get
      - list
      - watch

    • metadata.name defines the name of the Role CR.

    Example RoleBinding object

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: share-etc-pki-entitlement
  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

    • metadata.name defines the name of the RoleBinding CR.
    • roleRef.name defines the name of the Role CR.
    • subjects.name defines the name of the ServiceAccount CR.

  2. Create a SharedSecret CR by using the following example configuration: 

    apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedSecret
metadata:
  name: shared-test-secret
spec:
  secretRef:
    name: test-secret
    namespace: openshift-config-managed
    • spec.secretRef.namespace defines the name of the SharedSecret CR.

  3. Create a ClusterRole object that grants RBAC permission to use the referenced shared resource by using the following example configuration: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-shared-test-secret
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - shared-test-secret
    verbs:
      - use
    • metadata.name defines the name of the ClusterRole CR.

Verification

  1. Run the following command to verify that the required Role is created: 

    $ oc get role share-etc-pki-entitlement -n openshift-config-managed

    Example output

    NAME                        CREATED AT
share-etc-pki-entitlement   2025-11-19T12:05:32Z

  2. Run the following command to verify that the required RoleBinding is created: 

    $ oc get rolebinding share-etc-pki-entitlement -n openshift-config-managed

    Example output

    NAME                        ROLE                             AGE
share-etc-pki-entitlement   Role/share-etc-pki-entitlement   2m

  3. Run the following command to verify that the required ClusterRole is created: 

    $ oc get clusterrole use-shared-test-secret

    Example output

    NAME                     CREATED AT
use-shared-test-secret   2025-11-19T12:05:44Z

1.1.2. Using a SharedSecret custom resource in a pod
Copier lien

To access the SharedSecret custom resource (CR) from a pod, you grant role-based access control (RBAC) permission to a service account.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as one of the following users:

    • A cluster administrator who has created the SharedSecret CR instance for the Secret object.
    • A user with permissions to access the target namespaces and to create or manage the SharedSecret custom resource for the Secret to be shared.

  • You must have permissions to perform the following actions:

    • Run the oc adm policy who-can use <sharedsecret_identifier> command to check if a service account is allowed to use the SharedSecret CR and the service account is listed in your namespace.
    • Confirm that the service account of your pod is allowed to use the csi volume. If you created the pod as a user, confirm that you are allowed to use the csi volume.
Note

If you are unable to complete the last two prerequisites, the cluster administrator can establish the necessary RBAC permission so that you can enable service accounts to use the SharedSecret CR.

Procedure

  1. Create the RoleBinding object in the cluster associated with the role and grant the permission to your service account to use the shared resource. See the following example configuration: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: use-shared-secret
  namespace: app-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-shared-secret
subjects:
  - kind: ServiceAccount
    name: <service_account_name>

    where:

    metadata.name
    Defines the name of the RoleBinding CR.
    <service_account_name>
    Specifies the name of the service account of your application.

  2. Mount the shared resource csi driver into a pod or any other resource that accepts csi volumes. See the following example configuration: 

    apiVersion: v1
kind: Pod
metadata:
  name: example-shared-secret
  namespace: <app_namespace>
spec:
  ...
  serviceAccountName: default
  volumes:
    - name: shared-secret
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedSecret: shared-test-secret

    where:

    <app_namespace>
    Specifies the name of the namespace of your application.
    volumes.volumeAttributes.sharedSecret
    Defines the value of the sharedSecret attribute that must be same as the name of the SharedSecret CR.
    Important

    The pod fails to start in the following cases:

    • The value of the sharedSecret attribute does not match the name of the SharedSecret instance.
    • A volume is defined but not mounted, the pod stays in the ContainerCreating state and eventually fails.

Verification

  1. Run the following command to verify the permission granted to your service account: 

    $ oc describe rolebinding share-etc-pki-entitlement -n openshift-config-managed

    Example output: 

    Name:         share-etc-pki-entitlement
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  share-etc-pki-entitlement
Subjects:
  Kind            Name                        Namespace
  ----            ----                        ---------
  ServiceAccount  csi-driver-shared-resource  openshift-builds

1.2. Sharing a ConfigMap object across namespaces
Copier lien

A ConfigMap object stores non-sensitive data, such as URLs or feature flags. By using a SharedConfigMap custom resource (CR), you can share a ConfigMap object across namespaces without duplication, providing a single configuration source and ensuring consistency cluster-wide.

1.2.1. Creating a SharedConfigMap custom resource
Copier lien

Create a SharedConfigMap custom resource (CR) to share a ConfigMap object across namespaces. By creating a SharedConfigMap custom resource (CR), you can share configuration data across namespaces, ensuring that sensitive configuration data remains consistently accessible cluster-wide.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as an administrator.
  • You have created a ConfigMap object that you want to share in other namespaces. To create a ConfigMap object, see "Adding input secrets and configmaps".

  • You must have permissions to perform the following actions:

    • Create the sharedconfigmaps.sharedresource.openshift.io CR at a cluster-scoped level.
    • Create a ClusterRole object for the SharedConfigMap CR.
    • Create the Role and RoleBinding objects for the Shared Resource Container Storage Interface (CSI) Driver.
    • Manage roles and role bindings across the namespaces in the cluster to control which users can get, list, and watch instances.
    • Manage roles and role bindings so that the service account specified by a pod can use the SharedConfigMap CR to mount a csi volume that references a ConfigMap object.
    • Access the namespaces that contain the ConfigMap object you want to share.

Procedure

  1. Create a Role and RoleBinding object to grant the Shared Resource CSI Driver permission to access the ConfigMap object. See the following example configuration:

    Example Role object

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-test-config
  namespace: <name_of_the_source_namespace>
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["shared-config"]
    verbs: ["get", "list", "watch"]

    where:

    <name_of_the_source_namespace>
    Specifies the name of the source namespace.

    Example RoleBinding object

     apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
 metadata:
   name: shared-test-config
   namespace: <name_of_the_source_namespace>
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: shared-test-config
 subjects:
   - kind: ServiceAccount
     name: csi-driver-shared-resource
     namespace: openshift-builds

    where:

    <name_of_the_source_namespace>
    Specifies the name of the source namespace.
    subjects
    Specifies a list of service accounts for the Shared Resource CSI driver DaemonSet. When deployed with builds for Red Hat OpenShift, the service account name is csi-driver-shared-resource, and the namespace matches the one where the Builds for Red Hat OpenShift Operator is deployed.

  2. Create a SharedConfigMap CR for the ConfigMap object that you want to share across namespaces in the cluster. The following example shows a sample configuration: 

    apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedConfigMap
metadata:
  name: share-test-config
spec:
  configMapRef:
    name: shared-config
    namespace: <name_of_the_source_namespace>

    where:

    metadata.name
    Specifies the name of the SharedConfigMap CR.
    <name_of_the_source_namespace>
    Specifies the name of your source namespace.

  3. Create a ClusterRole CR instance that grants role-based access control (RBAC) permission to use the referenced shared resource. The following example shows a sample configuration: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <cluster_role_name>
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedconfigmaps
    resourceNames:
      - share-test-config
    verbs:
      - use

    where:

    <cluster_role_name>
    Specifies the name of your cluster role.
    rules.resourceNames
    Defines name of the SharedConfigMap CR.

Verification

  1. Run the following command to verify that the required Role is created: 

    $ oc get role share-etc-pki-entitlement -n openshift-config-managed

    Example output

    NAME                        CREATED AT
share-etc-pki-entitlement   2025-11-19T12:05:32Z

  2. Run the following command to verify that the required RoleBinding is created: 

    $ oc get rolebinding share-etc-pki-entitlement -n openshift-config-managed

    Example output

    NAME                        ROLE                             AGE
share-etc-pki-entitlement   Role/share-etc-pki-entitlement   2m

  3. Run the following command to verify that the required ClusterRole is created: 

    $ oc get clusterrole use-shared-test-secret

    Example output

    NAME                     CREATED AT
use-shared-test-secret   2025-11-19T12:05:44Z

1.2.2. Using a SharedConfigMap custom resource in a pod
Copier lien

To access a SharedConfigMap custom resource (CR) from a pod, you must grant the associated service account the necessary role-based access control (RBAC) permissions to use that SharedConfigMap CR.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as one of the following users:

    • A cluster administrator who has created the SharedConfigMap CR instance for the ConfigMap object.
    • A user with permissions to access the target namespaces and to create or manage the SharedConfigMap CR for the ConfigMap to be shared.

  • You must have permissions to perform the following actions:

    • Run the oc get sharedconfigmaps command to get the list of the SharedConfigMap CR instances.
    • Run the oc adm policy who-can use <sharedsecret_identifier> command to check if a service account is allowed to use the SharedSecret CR and the service account is listed in your namespace.
    • Run the oc describe clusterrole <roleName> command to confirm that the service account of your pod is allowed to use csi volumes. If you created the pod as a user, confirm that you are allowed to use csi volumes.
Note

If you are unable to complete the last two prerequisites, the cluster administrator can grant you the RBAC permission to enable the service accounts to use the SharedConfigMap CR.

Procedure

  1. Create the RoleBinding object associated with the role and grant the permission to your service account to use the shared resource. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: use-shared-config
  namespace: <app_namespace>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-shared-config
subjects:
  - kind: ServiceAccount
    name: <service_account_name>

    where:

    <app_namespace>
    Specifies the name of the namespace of your application.
    <service_account_name>
    Specifies the service account name of your application.

  2. Mount the Shared Resource Container Storage Interface (CSI) Driver into a pod or any other resource that accepts csi volumes. 

    apiVersion: v1
kind: Pod
metadata:
  name: example-shared-config
  namespace: <app_namespace>
spec:
  ...
  serviceAccountName: default
  volumes:
    - name: shared-config
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedConfigMap: share-test-config

    where:

    <app_namespace>
    Specifies the name of the namespace of your application.
    volumes.volumeAttributes.sharedConfigMap
    Specifies the name of the sharedConfigMap object.
    Important

    The pod fails to start in the following cases:

    • The value of the SharedConfigMap attribute does not match the name of the SharedConfigMap instance.
    • A volume is defined but not mounted, the pod stays in the ContainerCreating state and eventually fails.

Verification

  1. Run the following command to verify the permission granted to your service account: 

    $ oc describe rolebinding share-etc-pki-entitlement -n openshift-config-managed

    Example output: 

    Name:         share-etc-pki-entitlement
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  share-etc-pki-entitlement
Subjects:
  Kind            Name                        Namespace
  ----            ----                        ---------
  ServiceAccount  csi-driver-shared-resource  openshift-builds

1.3. Building images using RHEL entitlements
Copier lien

If you have a Red Hat Enterprise Linux (RHEL) entitlement, the Insights Operator automatically manages the entitlement keys using the Simple Content Access (SCA) feature. With SCA, the RHEL systems access the subscription content without manually managing the entitlement keys. The Insights Operator imports your SCA entitlement keys and stores them in a secret called etc-pki-entitlement in the openshift-config-managed namespace.

Previously, a cluster administrator would manually copy the etc-pki-entitlement secret to the required namespace. Starting with OpenShift Container Platform 4.10 and later, builds for Red Hat OpenShift can share the etc-pki-entitlement secret from the openshift-config-managed namespace with other namespaces by using the Shared Resource Container Storage Interface (CSI) Driver Operator.

1.3.1. Sharing RHEL entitlement across namespaces
Copier lien

You can use a SharedSecret object to securely share and synchronize the RHEL entitlement keys of a cluster in Builds across namespaces.

Prerequisites

  • You must have permissions to perform the following actions:

    • Create SharedSecret object.
    • Create build configs and start builds.
    • Run the oc get sharedsecrets command to discover which SharedSecret custom resource (CR) instances are available.
    • Run the oc adm policy who-can use <sharedsecret_identifier> command to check if a service account is allowed to use the SharedSecret CR and the service account is listed in your namespace.
Note

If you are unable to complete the last two prerequisites, the cluster administrator can establish the necessary RBAC permission so that you can grant service accounts to use the SharedSecret CR.

Procedure

  1. Create a SharedSecret object instance with the entitlement secret of a cluster by running the following command: 

    $ 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

    where:

    metadata.name
    Specifies the name of the SharedSecret object.

  2. Create a ClusterRole object to grant permission to access the SharedSecret object by using the following example configuration: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-share-etc-pki-entitlement
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - etc-pki-entitlement
    verbs:
      - use

    where:

    metadata.name
    Specifies the name of the ClusterRole CR.

  3. Create the Role and RoleBinding object that grants the Shared Resource CSI driver the permission to access the SharedSecret object:

    Example Role object: 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: share-etc-pki-entitlement
  namespace: openshift-config-managed
rules:
  - apiGroups:
      - ""
    resources:
      - secrets
    resourceNames:
      - etc-pki-entitlement
    verbs:
      - get
      - list
      - watch

+

where:

metadata.name
Specifies the name of the Role CR.

+ Example RoleBinding object:

+ 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: share-etc-pki-entitlement
  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

+ where:

metadata.name
Specifies the name of the RoleBinding CR.
subjects.namespace

Specifies the name of the namespace where openshift-builds is installed.

  1. Create a RoleBinding object for the builder and pipeline service accounts in the namespace where builds run: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: use-share-etc-pki-entitlement
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-share-etc-pki-entitlement
subjects:
  - kind: ServiceAccount
    name: pipeline
  - kind: ServiceAccount
    name: builder

    where:

metadata.name

Specifies the name of the RoleBinding CR for the builder and pipeline service accounts.

Note

The service account that consumes the SharedSecret object is created and managed by the OpenShift controllers.

  1. Mount the SharedSecret object by using the buildah build strategy. See the following example: 

    $ 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
      volumeAttributes:
        sharedSecret: <sharedsecret_object_name>
    name: etc-pki-entitlement
  output:
    image: <output_image_location>
EOF

    where:

volumes.csi.readOnly
Specifies the readOnly value to mount the shared resource in the build.
volumes.csi.volumeAttributes.sharedSecret
Specifies the name of the SharedSecret object to include it in the build.
volumes.output.image
Specifies the location where you want to push the built image.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début