Azure / secrets-store-csi-driver-provider-azure

Azure Key Vault provider for Secret Store CSI driver allows you to get secret contents stored in Azure Key Vault instance and use the Secret Store CSI driver interface to mount them into Kubernetes pods.
https://azure.github.io/secrets-store-csi-driver-provider-azure/
MIT License
441 stars 193 forks source link

Provide more native configuration for secrets/keys in SecretProviderClass #97

Open tomkerkhove opened 4 years ago

tomkerkhove commented 4 years ago

Describe the solution you'd like The current configuration feels a bit odd with the objects.array which is a mix of secrets & keys.

Example from README:

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: azure-kvname
spec:
  provider: azure                   
  parameters:
    usePodIdentity: "false"         # [OPTIONAL for Azure] if not provided, will default to "false"
    useVMManagedIdentity: "false"   # [OPTIONAL available for version > 0.0.4] if not provided, will default to "false"
    userAssignedIdentityID: "client_id"  # [OPTIONAL available for version > 0.0.4] use the client id to specify which user assigned managed identity to use. If using a user assigned identity as the VM's managed identity, then specify the identity's client id. If empty, then defaults to use the system assigned identity on the VM
    keyvaultName: "kvname"          # the name of the KeyVault
    cloudName: ""          # [OPTIONAL available for version > 0.0.4] if not provided, azure environment will default to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1
          objectAlias: SECRET_1     # [OPTIONAL available for version > 0.0.4] object alias
          objectType: secret        # object types: secret, key or cert
          objectVersion: ""         # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1
          objectAlias: ""
          objectType: key
          objectVersion: ""
    resourceGroup: "rg1"            # [REQUIRED for version < 0.0.4] the resource group of the KeyVault
    subscriptionId: "s

While it would feel more natural to be able to use this approach:

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: azure-kvname
spec:
  provider: azure                   
  parameters:
    usePodIdentity: "false"         # [OPTIONAL for Azure] if not provided, will default to "false"
    useVMManagedIdentity: "false"   # [OPTIONAL available for version > 0.0.4] if not provided, will default to "false"
    userAssignedIdentityID: "client_id"  # [OPTIONAL available for version > 0.0.4] use the client id to specify which user assigned managed identity to use. If using a user assigned identity as the VM's managed identity, then specify the identity's client id. If empty, then defaults to use the system assigned identity on the VM
    keyvaultName: "kvname"          # the name of the KeyVault
    cloudName: ""          # [OPTIONAL available for version > 0.0.4] if not provided, azure environment will default to AzurePublicCloud
    secrets:
    - name: secret1
      alias: SECRET_1
      version: ""
    keys:
    - keys: key1
      alias: KEY_1
      version: ""
    resourceGroup: "rg1"            # [REQUIRED for version < 0.0.4] the resource group of the KeyVault
    subscriptionId: "s

Anything else you would like to add: I'm not an expert in Kubernetes extensibility so it might be because of a technical limitation, but I would prefer the above proposal which is cleaner for people who are new to it.

lgmorand commented 4 years ago

you can't duplicate "secrets:" key. that's how arrays work in yaml, looks at "container" behavior. but I do agree, key names are not obvious

tomkerkhove commented 4 years ago

Sorry, it was a copy paste mistake - I've updated the sample to use keys instead

stan-solovyov commented 4 years ago

Is there any way to consume all secrets/keys from a Key Vault? I think the solution where you need to specify secrets/keys one by one is not very viable.

aramase commented 4 years ago

Support prefix reference issue - #61

tomkerkhove commented 4 years ago

@aramase Any input on the structure as a whole?

phantomkingx commented 3 years ago

Implementing the proposed format would also make kustomize manipulation possible.

schabdo commented 2 years ago

Stumbled-upon same issue when using Kustomize. No way to patch the array of secrets. Would be awesome to have something like the proposed structure in place since it is similar to the approach taken for populating K8s secrets from KeyVault (cf. Azure docs)