Keda TriggerAuthentication Vault service account token request

[BojanZelic]

Proposal

Currently TriggerAuthentication/ClusterTriggerAuthentication supports authentication using the serviceAccount of keda containers;

ex

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
spec:
...
  hashiCorpVault:
    address: {hashicorp-vault-address}
    credential:
      token: {hashicorp-vault-token}
      serviceAccount: {path-to-service-account-file}

Proposal to use the service account (via token request) of the namespace that the TriggerAuthentication is deployed to instead so that permissions can be scoped on a per-namespace level;

ex:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
spec:
...
  hashiCorpVault:
    address: {hashicorp-vault-address}
    credential:
      serviceAccountName: default

Use-Case

Usually the way I've seen vault setup is where vault secrets are bound to the namespace of the service account that's logged into vault;

The current configuration leads to a design where users have to grant overly permissive permissions on keda service accounts to vault;

The keda-operator role needs to be configured in a way that grants permissions to read ALL secrets that keda uses; But this means that keda-operator permissions are too permissive;

for example lets say we have 10 projects that leverage kafka autoscaling (w/credentials) that are deployed in 10 different namespaces;

With the existing setup when the keda-operator service account token authenticates to vault, it needs to be configured so that it can access credentials for all the 10 projects; Meaning that credentials can be accessed across namespaces;

If we were to leverage token requests across namespaces for vault authentication, then permissions can be granted on a per-namespace level;

ex; default service account in namespace1 can only read credentials for kafka1

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

vault-secrets-webhook does something similar that we could implement; https://github.com/bank-vaults/vault-secrets-webhook/blob/783c8b96966bfeaf3dca9cf3de622ce5f0cffdc6/pkg/webhook/webhook.go#L231-L265

I'm proposing to change it from:
Before:

After:

[JorTurFer]

Hello
This is an interesting issue an it's related with other issue we have been discussion about during last weeks about KEDA requesting tokens in behalf of other service account. The conclusion was that we agree with KEDA requesting token in behalf of other service account but controller by RBAC, as default the RBAC must block the token requests and users have to enable the RBAC explicitly (it can be done just with a helm value, but the default behaviour must be disabling it)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[BojanZelic]

rm stale

Still planning on implementing this when i get a chance

[stale]

This issue has been automatically closed due to inactivity.