Use ServiceAccount for Workload Identity clientID and tenantId

[dkirrane]

Feature Request
Currently for Workload Identity the SecretProviderClass requires clientID and tenantId.
However this detail is already available from the application's ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: default
  labels:
    azure.workload.identity/use: 'true'
  annotations:
    azure.workload.identity/client-id: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    azure.workload.identity/tenant-id: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-app
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    keyvaultName: my-kv
    tenantId: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Proposal

Instead can the SecretProviderClass just use the ServiceAccount for clientID and tenantId?
for example

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-app
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    serviceAccountName: my-app
    keyvaultName: my-kv

[rbtz-openai]

@aramase Can we bump the priority for this, or should we go through Azure Support to escalate?

[wenzel-felix]

#1443 I just opened this PR trying to adjust it similarly to your request.
Currently, it only takes care of the clientID, not the tenantID as the latter one is theoretically optional for the service account. I don't see it as big of an issue as the clientID, which potentially changes for every SPC. The tenantID is rather static.

[EPinci]

We would greatly benefit from this as well: the separate clientID has already caused issues in our workload.

[mo-martin]

This functionality would have prevented an outtage experienced with the dual clientID requirement, big thumbs up from me

[halabap]

This would be great, we would like to avoid specifying the client id in the SecretProviderClass as we are autogenerating SeviceAccount manifests for worload identity, but SecretProviderClass is created by development teams and the need to set the same client ID second time in SecretProviderClass leads to mistakes.

[mo-martin]

@halabap if your team is using helm, then a viable and temporary work around is to use helms 'lookup' function. It allows you to query any applied metadata in the Kubernetes resources.

It's not better than just referencing a service account, and it does add some fragility to the secret provider, but it works!

[halabap]

Thanks for hint. Yeah, I know about helm and we are using helm for platform services, but for the business services we stopped using helm and went to plain manifests as helm was adding complexity for developers who had to support the services and the evaluation was stuck sometimes, etc. If there is a chance that this feature will be merged then we will wait for some time as we have custom solution for secrets, which we want to replace by CSI store driver in the future 😉 ThanksSent from my iPhoneOn 29. 11. 2024, at 20:18, Moses Martin ***@***.***> wrote: @halabap if your team is using helm, then a viable and temporary work around is to use helms 'lookup' function. It allows you to query any applied metadata in the Kubernetes resources. It's not better than just referencing a service account, and it does add some fragility to the secret provider, but it works! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>