Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for cluster-scoped trigger authentication #1452

Merged
merged 2 commits into from
Jan 6, 2021

Conversation

coderanger
Copy link
Contributor

@coderanger coderanger commented Dec 25, 2020

This allows creating a single authentication for Keda, for scalers where that makes sense.

ClusterTriggerAuthentication objects work just like TriggerAuthentication but are not in a specific namespace. SecretRefs in them will looked up in the namespace Keda is running in (overridable via $KEDA_CLUSTER_OBJECT_NAMESPACE for special cases). In triggers, you set kind: ClusterTriggerAuthentication.

Overall this is modeled on cert-manager's ClusterIssuer and Issuer types. Holding off on adding documentation since I'm not sure of the best way to document this since it is kind of a big feature.

Checklist

  • Commits are signed with Developer Certificate of Origin (DCO)
  • Tests have been added
  • A PR is opened to update the documentation on https://github.com/kedacore/keda-docs
  • Changelog has been updated

Relates to #1469

…Authentication.

This allows creating a single authentication for Keda, for scalers where that makes sense.

Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
@tomkerkhove
Copy link
Member

WDYT @zroubalik? I think we've explicitly gone with namespace-scoping since that is typically used as a security boundary but I can see value in having a cluster-wide auth mode.

@tomkerkhove
Copy link
Member

If we agree on this, please open a doc PR

@tomkerkhove
Copy link
Member

Thanks for the PR btw!

@coderanger
Copy link
Contributor Author

My specific use case is I want to make a single keda RabbitMQ user with access to the HTTP API without also giving all my normal clients that access. And just in general it's nice to have Keda-specific credentials for tracking and auditing, without having to copy those to every application namespace that uses RabbitMQ scaling. This could also be implemented directly into the RabbitMQ scaler but that seemed more hacky.

@tomkerkhove
Copy link
Member

Makes perfect sense, thanks!

@tomkerkhove
Copy link
Member

See kedacore/keda-docs#340 (comment) where I would move the $KEDA_CLUSTER_OBJECT_NAMESPACE environment variable to the declaration in case they want to change it

@zroubalik
Copy link
Member

Thanks for this PR, I can see the need for this feature. I like the way on how this is modelled wrt security (limiting Secrets to only one namespace).
This might be worth discussing on the community call.

@zroubalik zroubalik merged commit 79a7407 into kedacore:main Jan 6, 2021
ycabrer pushed a commit to ycabrer/keda that referenced this pull request Mar 1, 2021
…Authentication. (kedacore#1452)

This allows creating a single authentication for Keda, for scalers where that makes sense.

Signed-off-by: Noah Kantrowitz <noah@coderanger.net>

Co-authored-by: Zbynek Roubalik <726523+zroubalik@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants