Make get secrets permissions optional in Metric Adapter

[sbuliarca]

Proposal

In version 2.7.1, keda-metrics-apiserver requires the permissions to get secrets for resolving the container's environment for a targetted deployment( code is here) without actually needing it. If it doesn't have the permissions, the metric for the scaled object won't be resolved.

We would like to be able to run keda without the metrics-apiserver having access to secrets.

Proposed solution:

1. Resolve the target's container environment only when keys from it are referenced by the authentication mechanism
2. This is more of a workaround: do not fail when a secret can not be resolved in scale_resolver. This way the scaler should work if it doesn't need authentication, as in our case.

More details in the use-case description.

Use-Case

We're running a self-managed Kubernetes cluster where we use isolated namespaces for security and logical separation of the applications. We are using the Principle of Least privilege across our namespaces to achieve a tight security. For running Keda we plan to deploy the keda-metrics-apiserver that watches all namespaces in a separate namespace, since it can be deploied only once per cluster, and the keda-operator in the individual namespaces where we want to enable event based scaling. Having keda-metrics-apiserver being able to read the other namespaces secrets poses a big risk for us, so we trimmed down the rbac config that Keda comes with, and we removed the access to secrets for it. We accepted the fact that we won't be able to use TriggerAuthentications throught secrets & env vars, only through Hashicorp's Vault.

But we hit this limitation as keda-metrics-apiserver wants to read the secrets of the targetted deployment, although the ScaledObject doesn't require any authentication for the scaler, and it doesn't work without it. Due to this we are not able to use scalers on targets that rerefence secrets.

Anything else?

No response

[tomkerkhove]

That's a fair ask, but I don't know if we can do that. @zroubalik ?

[zroubalik]

Reading Secrets from KEDA Operator is acceptable for you?

I think it is a fair ask, I prefer to 1. solution, the latter is not ideal imho.

[sbuliarca]

Reading Secrets from KEDA Operator is acceptable for you?

Indeed this is acceptable, as the operator would run in the namespace it manages, so it would be ok to have access to the secrets in that namespace

[tomkerkhove]

That's not possible though, see https://github.com/kedacore/keda/issues/2654 where we are tracking this.

But I presume you are interested in the multi-tenancy model there?

[sbuliarca]

Indeed, we're after the multi-tenancy model.

And we almost got to an acceptable solution with the current code, this being the only issue & the limitation of not being able to use TriggerAuthentications throught secrets & env vars, only through Hashicorp's Vault, as stated before.

[stale[bot]]

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.

[stale[bot]]

This issue has been automatically closed due to inactivity.

[stale[bot]]

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.

[tomkerkhove]

@sbuliarca Can you check if https://github.com/kedacore/keda/issues/3668 helps you? This feels like a duplicate

[sbuliarca]

Hey @tomkerkhove ! Indeed I think that issue would solve ours too. Thank you for pointing it out

[tomkerkhove]

Duplicate of https://github.com/kedacore/keda/issues/3668