Feature Overview (aka. Goal Summary)  

• Ship and support the CSI Driver for secrets store. This driver is pluggable to provide the ability for secrets store vendors to create a plugin that allows Kubernetes to mount multiple secrets, keys, and certs stored in enterprise-grade external secrets stores into their pods as a volume. Once the Volume is attached, the data in it is mounted into the container's file system.
• See https://github.com/kubernetes-sigs/secrets-store-csi-driver.
• Operator & CSI available in OLM (OperatorHub)
• secret provider plugins are supported by partners

Goals (aka. expected user outcomes)

In a cluster where the Secret Store CSI Driver and Provider daemonset are running:

User creates a SecretProviderClass custom resource to provide driver configurations and provider-specific parameters to the CSI driver.

Example: 

apiVersion: secrets-store.csi.x-k8s.io/v1

kind: SecretProviderClass

metadata:

  name: my-provider

spec:

  provider: vault

  parameters:

    roleName: "csi"

    vaultAddress: "http://vault.vault:8200"

    objects:  |

      - secretPath: "secret/data/foo"

        objectName: "bar"

        secretKey: "bar"

      - secretPath: "secret/data/foo1"

        objectName: "bar1"

        secretKey: "bar1"

Next, User updates Deployment.yaml for their application to use secret store csi driver and point to the provider to mount the secrets using volumes

Example:

volumes:

  - name: secrets-store-inline

    csi:

      driver: secrets-store.csi.k8s.io

      readOnly: true

      volumeAttributes:

        secretProviderClass: "my-provider"

Requirements (aka. Acceptance Criteria):

 __ On pod start and restart, the driver will communicate with the provider using gRPC to retrieve the secret content from the external Secrets Store  specified in the SecretProviderClass custom resource. Then the volume is mounted in the pod as tmpfs and the secret contents are written to the volume. The Application is finally able to consume the secret from the volume mounted.  

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.