This RFC aims to establish whether you have considered implementing this CSI driver as a Secret Store CSI Driver (secrets-store.csi.k8s.io). This provider dynamically generates and injects short-lived, renewed TLS certificates directly into application volumes, operating in a similar way to Secret Store CSI.
This could standardise the use of secrets to some extent, enabling the sharing of a common security platform with other secret providers in the ecosystem, including rotation and caching mechanisms, while decreasing maintenance, probably.
Example configuration:
apiVersion: secrets-store.csi.k8s.io/v1
kind: SecretProviderClass
metadata:
name: cert-manager-tls
spec:
provider: cert-manager
parameters:
issuerName: "my-internal-issuer"
issuerKind: "ClusterIssuer"
commonName: "my-app.internal"
keyUsages:
- digital signature,
- key encipherment
- server authI have been considering implementing it myself, but it won't hurt to ask in case I'm missing something.
This RFC aims to establish whether you have considered implementing this CSI driver as a Secret Store CSI Driver (secrets-store.csi.k8s.io). This provider dynamically generates and injects short-lived, renewed TLS certificates directly into application volumes, operating in a similar way to Secret Store CSI.
This could standardise the use of secrets to some extent, enabling the sharing of a common security platform with other secret providers in the ecosystem, including rotation and caching mechanisms, while decreasing maintenance, probably.
Example configuration:
I have been considering implementing it myself, but it won't hurt to ask in case I'm missing something.