Consider using a CRD for holding Key Vault configuration

[vplauzon]

This really is a UX improvement as it wouldn't enable new scenarios per se.

The configuration we need to put under "flexVolume" is quite verbose. Most of it gets repeated in each pod using the same key vault:

• driver
• secretRef
• usepodidentity
• keyvaultname
• resourcegroup
• subscriptionid
• tenantid

From the DRY principle, it would be nice to have that configuration in a separate object (CRD) and have pod simply referring to that CRD.

[ritazh]

The idea here is to use existing kubernetes objects, not create a new one.

[allantargino]

How about storing them in a ConfigMap?

[ritazh]

Hi @allantargino, Like Kubernetes Secrets, ConfigMaps are persisted to etcd as well. So if you are ok with using configmaps to hold data from key vault, then you probably would be ok with using Secrets. But if you are concerned with the security aspect of persisting data to etcd, then this solution will allow you to pull data from key vault without persisting anything to etcd.

[allantargino]

Hi @ritazh, thanks for answering the question. But I meant how about storing the properties keyvaultname, resourcegroup, subscriptionid, tenantid (and others) in a ConfigMap? This way, the user could just pass a secretRef (containing the principals) and a configMapRef (containing these other properties). This would make the pod spec less verbose as @vplauzon mentioned.