Extend search scope of kubernetes workload scaler to all namespaces about keda

[tomkerkhove]

Interesting, mind sharing what scenario you have this for system components? How are they impacted when scaling is not happening?

[sonwan2020]

We have a real scenario requires this 'cross namespace search' feature
As a platform service provider, we put managed component in one namespace and cx workload in another.
Some features require extra backend services, like our metrics collector.

• When there are pods emit metrics, we need a pod to collect and emit metrics.
• When no user pod enable the metrics flag, we don't need that pod.
  Currently the watched resource & scaledobject & the target deployment must stay in the same namespace.

[sonwan2020]

@SpiritZhou for the proposed options, I prefer option 2.

And should the 'workload' include more resource, not only the pods? like deployment, and even CRDs.

[JorTurFer]

We discussed limiting or not the scope to the namespace or not, and just to share the reasons behind the limitation, we basically saw a potential vector attack for getting sensible information about workloads running on other namespaces where you could not have access by your own RBAC.

My concerns related with extending the resources you can query or the namespaces have to be authorized by cluster admins somehow or a malicious attacker can use KEDA for getting information about resources which wouldn't be accessible to them.

I see the advantages of supporting this, but we should be aware about how to secure it too

[SpiritZhou]

@JorTurFer Could you provide more details or some specific scenario regarding the security concern? One of the scenario is that a ScaledObject in namespace A could use a label selector to retrieve the number of resources in namespace B through KEDA. We can explore potential solutions to address this issue.

[JorTurFer]

I can start a DDoS attack, adding an attacker pod per victim pod. I can do brute force attacks for receiving information about the pods in the cluster, for example, I can get information about if the cluster uses an specific service I know is vulnerable querying about its common labels, and then start an attack based on that specific vulnerability.

An example of this, let's say that cert-manager has a know vulnerability in the version 1.12.0, I can use the fact of cert-manager chart sets some specific labels to detect which version is deployed in the cluster just adding a selector like:
app.kubernetes.io/instance=cert-manager,helm.sh/chart=cert-manager-v1.12.0.
This is a potential risk IMHO