Enhance Security and Self-Service by Allowing Service Account Specification in Target Namespace for Workload Identity

Proposal

Allow the TriggerAuthentication resource in KEDA to specify a service account from the target namespace for workload identity, enhancing security and enabling a self-service model for managing scaling resources.

Use-Case

In multi-tenant Kubernetes environments, teams often manage their own namespaces and the resources within them, including service accounts. The current approach, where KEDA uses a service account from the keda-operator namespace for scaling operations, presents a challenge for these teams. It limits their ability to apply namespace-specific security policies or manage the lifecycle of these accounts independently. By allowing the specification of a service account in the target namespace, teams would gain the ability to manage their scaling operations more securely and autonomously.

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

This proposal aims to strike a balance between security, flexibility, and operational efficiency in managing scaling operations with KEDA. I believe that implementing this feature will benefit many users operating in environments with strict security policies and those who advocate for a more self-service oriented approach to resource management.