Azure Service Operator support for ASO-created Managed Identities

[tyler-gs]

Describe the solution you'd like
If you create a Managed Identity using Azure Service Operator, the operator exposes values through a Kubernetes ConfigMap (Principal ID, Client ID, Tenant ID). However, when creating a SecretProviderClass, you need to provide the ClientID value. There's no easy way to transpose the values from one to the other without a manual solution involving scraping the value and passing it over.

If there were an interoperable way for the SecretProviderClass to get the client ID of the ManagedIdentity for the purposes of Workload Identity, that would remove a manual step and make setting up an environment much simpler. Off the top of my head, if there were a way for the SecretProviderClass to support getting the ClientID value from a ConfigMap, that could alleviate the issue.

Anything else you would like to add:
The ASO team tapped me to create this as an issue, as I mentioned there was no easy solution for this.

[matthchr]

I am not sure what the right solution to this issue is, but interested in folks thoughts. I do think that the ability to use ASO to provision a Managed Identity + Role Assignment for your app as part of your Helm chart or YAML, and then feeding that directly to CSI Driver would be an interesting scenario to enable. Curious what @aramase thinks.

[ahmadhusaini]

It would be great to get this solved. Would it be possible to get the Client ID of the ManagedIdentity from the workload requesting the volume mount? The workload would have it as an environment variable.

Currently, the CSI driver is getting the service account token associated with the workload requesting the volume mount, and I'm curious if the same can be done with the Client ID. Suppose there's a way to get that value through Pod Info on Mount [https://kubernetes-csi.github.io/docs/pod-info.html].

[varunvijayagopal]

@tyler-gs were you able to find some work around for this other than using a different helm chart and install it as a prerequisite ? please let me know if there is a better way to handle this .

[tyler-gs]

@tyler-gs were you able to find some work around for this other than using a different helm chart and install it as a prerequisite ? please let me know if there is a better way to handle this .

I'll be honest, I ended up swapping from this CSI driver provider to the External Secrets operator, since that does what I want it to do, which is setup the secrets automatically without having to launch a pod first.

[antoineozenne-at-leocare]

I've asked the same thing for the App Configuration Kubernetes Provider and the feature was developed. I really need this too. For this moment, I see two workarounds:

• Using the App Configuration Kubernetes Provider to access a Key Vault secret via the App Configuration Store.
• Using the External Secrets Operator which can read the clientID from a configmap.

[nraooptum]

Seeing the same issue as well. Would love to pipe the output of ASO to a SPC. Supporting something like this would be great:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
spec:
  provider: azure
  parameters:
    clientID: # string | configMapKeyRef | secretKeyRef
      configMapKeyRef:
        name: some-name
        key: some-key

[benjaminapetersen]

The Provider should not be able to directly read ConfigMaps or Secrets, this would be a Node Isolation violation (it is a DaemonSet).