openshift/csi-driver-shared-resource

CSI driver for sharing Secrets and ConfigMaps across namespaces.

OpenShift Shared Resource CSI Driver

The OpenShift Shared Resource CSI Driver allows Secrets and ConfigMaps to be shared across Kubernetes namespaces in a controlled manner. This CSI driver ensures that the entity (ServiceAccount) accessing the shared Secret or ConfigMap has permission to do so before mounting the data as a volume into the requesting Pod.

This CSI driver only supports the Ephemeral volume lifecycle mode. It also requires the following during operation:

• podInfoOnMount: true
• fsGroupPolicy: File
• attachRequired: false

Getting Started

The easiest way to use the Shared Resource CSI Driver is to deploy OpenShift v4.10 or higher, and enable the Tech Preview Features.

How To Use

1. Create a Secret or ConfigMap that you wish to share in a "source" namespace.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: shared-config
     namespace: default # This can be any desired "source" namespace
   data:
     config.txt: "Hello world!"

2. Create a SharedSecret or SharedConfigMap instance to make your resource shareable:

   apiVersion: sharedresource.openshift.io/v1alpha1
   kind: SharedConfigMap
   metadata:
     name: share-default-config
   spec:
     configMapRef:
       name: shared-config
       namespace: default

3. Grant the desired SeviceAccount in the "target" namespace permission to use the shared resource above:

   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: use-shared-default-config
     namespace: app-namespace # This is the "target" namespace
   rules:
     - apiGroups:
         - sharedresource.openshift.io
       resources:
         - sharedconfigmaps
       resourceNames:
         - share-default-config
       verbs:
         - use
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: use-shared-default-config
     namespace: app-namespace
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: use-shared-default-config
   subjects:
     - kind: ServiceAccount
       name: default
       namespace: app-namespace

4. Mount the shared resource into a Pod (or 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 # required to be true
           driver: csi.sharedresource.openshift.io
           volumeAttributes:
             sharedConfigMap: share-default-config

See also:

• Simple example
• Tekton example
• OpenShift BuildConfig example

Features

• ServiceAccounts must have the use permission to mount the respective SharedSecret or SharedConfigMap. Volumes fail to mount otherwise - see FAQ for more details.
• Automatic sync of the shared resource data (Secret/ConfigMap) into the mounting Pod.
• Automatic removal/restoration of shared resource data if the Pod's RBAC permissions change at runtime.
• Automatic removal/restoration of shared resource data if the backing Secret/ConfigMap is deleted/re-created.
• Survival of shared resource data with CSI driver restarts/upgrades.
• Multiple SharedSecret/SharedConfig volumes within a Pod. Also supports nested volume mounts within a container.
• Reserve a cluster-scoped share name to a specific Secret or ConfigMap.

The following CSI interfaces are implemented:

• Identity Service: GetPluginInfo, GetPluginCapabilities, Probe
• Node Service: NodeGetInfo, NodeGetCapabilities, NodePublishVolume, NodeUnpublishVolume
• Controller Service: not implemented.

NOTE: see CSI Volume Specifics for restrictions around these features for read-only Volumes.

FAQ

Please refer to the FAQ Guide for commonly asked questions.

Development

See the development guide on how to build and test locally.

csi-driver-shared-resource's Issues

update/recreate target configmap, the data of csi volume not update/recreate

Installation documentation broken at different points

While following the installation doc and after the introduction of new resources types, installation breaks at some points:

• using 0.4.8-rc is suffering breaking changes
• daemonset's hostpath container image requires quay.io/openshift/origin-csi-driver-shared-resource:4.10.0
• my-csi-volume has a missing share attribute

Future Release Branches Frozen For Merging | branch:release-4.17 branch:release-4.18

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.17
• release-4.18

For more information, see the branching documentation.

Future Release Branches Frozen For Merging | branch:release-4.16 branch:release-4.17

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.16
• release-4.17

For more information, see the branching documentation.

cleanup: change "pkg/hostpath" path in src tree

suggestion from @jsafrane

I'm inclined to rename hostpath to driver' or csidriver` to distinguish it from the k8s controller / shared informer piece which is in its own package

Allow volume to be optional

A regular Secret resource can be used as an optional volume:

volumes:            
- name: missing     
  secret:           
    secretName: missing
    optional: true  

If the secret does not exist, it does not prevent the Pod from being created. Any volumeMounts using the secret volume are mounted as an empty dir (or file if subpath is used).

This is helpful in creating resources (Pods, Jobs, Deployments, etc) that work in different environments.

Is it possible to do the same for the SharedSecret resource?

cleanup: /var/lib/kubelet/plugins/csi-hostpath is also quite an odd path where to place the driver socket.

from @jsafrane

IIRC I copied this from the sample hostpath plugin we referenced for creating this thing

look at what the other aws/azure/vsphere/ etc. drivers managed by the CSO do for this, and employ that pattern