Allow KEDA to access secrets to other Namespace

[sdiamond2]

Proposal

Hi Keda developers!!! :)

I would like to make a request to allow KEDA access secret to other namespaces.

Context:

This is in relation to the change that happened with this issue: #3668

Since the default for KEDA is to have access to all secrets, there was a request for restricting access to all secrets and use permissions.operator.restrict.secret = true (in the Helm Chart). I appreciate that this remove the secret access in the Cluster Role, but it also adds the environment variable: KEDA_RESTRICT_SECRET_ACCESS which then prevent KEDA to access secrets in other namespaces.

The idea here that I am requesting is that I would like to be able to create my own namespaced role that would give access to the secret with a namespaced role binding to the keda-operator.

For example, I have the following:

keda-operator running under its own namespace (keda)

I have namespace test-application where I have a deployment that I want to autoscale using KEDA.

I would like to do this when I enable permissions.operator.restrict.secret = true:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: test-application
  name: test-application-secret-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list","watch"]

---

apiVersion: rbac.authorization.k8.io/v1
kind: RoleBinding
metadata:
  namespace: test-application
  name: test-application-secret-rb
subjects:
- kind: ServiceAccount
  name: keda-operator
  apiGroup: rbac.authorization.k8s.io

Currently if I attempt this with having permissions.operator.restrict.secret = true, I get the following error when debug is enabled:

scale_handler Secret Access is restricted to be in Cluster Object Namespace, please use ClusterTriggerAuthentication instead of TriggerAuthentication.

I am running a multi tenant Kubernetes on premise cluster. I am not interested in putting secrets in the Keda-operator's namespace.

If I manually remove the environment variable KEDA_RESTRICT_SECRET_ACCESS and try again. I keep getting this error

Failed to watch/list *v1.Secret: secrets is forbidden: User "system:serviceaccount:keda:keda-operator" cannot list resource "secrets" in API group "" at the cluster scope

The only this error goes away is if I allow access to ALL secrets. Even if I try to point to a specific secret in the ClusterRole definition, this error persists.

I hope this gives enough information for you guys! Thank you for you help!

Use-Case

This would help me tremendously, since I appreciate this project and like what it does. Sadly, I can't seem to be able to share secrets between the keda-operator and application namespaces.

Is this a feature you are interested in implementing yourself?

No

Anything else?

If you need any testing, I would be more than happy to get it tested for you!

Thank you so much!

[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.

[sdiamond2]

Any status on this? :)

[sdiamond2]

Status on this please?

[tomkerkhove]

@JorTurFer Don't we already support this?

[JorTurFer]

This would help me tremendously, since I appreciate this project and like what it does. Sadly, I can't seem to be able to share secrets between the keda-operator and application namespaces.

Actually you can, currently you can't limit the supported namespaces and it's or KEDA namespace or all namespaces, but this can be a good improvement. Are you willing to contribute with the feature?

[zroubalik]

Agree, let's have this configurable.

[sdiamond2]

I wish I could, but I am not sure where to start. I thought it was a simple change. If this is not going to be implemented anytime soon, I may have to look into it or look for another alternative.

[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.

[joebowbeer]

To be clear, KEDA 2.13.0/2.13.1 still has "get" access to all secrets by way of this permissive rule in the keda-operator ClusterRole:

- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get

kubectl auth can-i get secrets --as=system:serviceaccount:keda:keda-operator
yes

See: kedacore/keda-docs#1307

[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.

[stale]

This issue has been automatically closed due to inactivity.