-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Provide support for Azure Key Vault in TriggerAuthentication. #2727
Conversation
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Can we also support managed identity or not? |
Some quick feedback on |
I am not really sure how to go about this. Need some guidance. |
Which secret ref approach are you referring to? |
The native Kubernetes approach - https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables: valueFrom:
secretKeyRef:
name: mysecret
key: username |
So, when you say align with it, you mean just renaming the object to use |
I would go with this: apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: triggerAuthName
namespace: default
spec:
azureKeyVault:
vaultUri: <vault-address>
credentials:
clientId: <azureAD-clientID>
clientSecret:
valueFrom:
secretKeyRef:
name: mysecret
key: username
tenantId: <azureAD-tenantID>
secrets:
- parameter: <param-name-for-authenticating>
name: <secret-name-in-key-vault>
version: <secret-version> # Optional |
I'll make the changes. |
Also, could you point me to where all do I need to make changes for the helm charts (besides the YAMLs for the CRDs)? I am not too familiar with those. |
Since this is our data plane I don't think we need any |
What about these, 02-crd-clustertriggerauthentications.yaml, 05-crd-triggerauthentications.keda.sh.yaml? |
CRDs is a different story but I'll need @zroubalik for this. |
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Also, would you mind opening a documentation PR for this nice addition please? |
Yeah, I am in the middle of doing it. |
As the helm charts need to be updated due to the CRD changes, what version, appVersion do I use here? |
It's very kind but you don't have to do anything, CRD updates are part of our release process: https://github.com/kedacore/keda/blob/main/RELEASE-PROCESS.MD#6-prepare-our-helm-chart |
Raised a PR for the documentation - kedacore/keda-docs#704 |
I'm not an expert in Azure Key Vault, but the code looks good. |
Certainly, we can store a Service Bus connection string in the vault to ensure it can authenticate to it. That way, we can re-use existing SB tests - What do you think? |
I'd do another test only for checking this. AFAIR, if the connection string fails, KEDA doesn't create the HPA, we could store one connection string on KeyVault and try to use it. Or maybe doing the query manually just for checking that response is not an error. But I'd go with another test |
Let's do this:
|
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
I don't think it makes sense to have unit test considering the |
I don't think this can hurt, no? |
The struct exposes only two methods, Initialize, Read. Not really sure how to test those without providing actual uri, creds and try to fetch a secret. But that would not be a unit test. |
Fine by me if it's fine for the others |
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, just some minor nits
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com>
/run-e2e azure-keyvault-queue.test.ts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Last question for me. Does this support also managed identity as requested or does this come later? |
@SebastianSchuetze It doesn't currently, it will have to be taken up later. |
…re#2727) Signed-off-by: Vighnesh Shenoy <vshenoy@microsoft.com> Signed-off-by: Ram Cohen <ram.cohen@gmail.com>
Looking into using this once released, but will this also be supported for ClusterTriggerAuthentication? The updated documentation doesn't make any exception to exclude this feature. If so where will it get the credentials for the clientSecret: clientSecret:
valueFrom:
secretKeyRef: # Where is this secret coming from in a ClusterTriggerAuthentication?
name: <secret-name>
key: <key-within-secret> |
That's something we should improve in our docs indeed, @v-shenoy I presume this would be from a secret in the same namespace as the ClusterTriggerAuthentication itself, right? |
Yes, it would be. Do we add this to the documentation, or should we have cluster trigger authentication be able to fetch secrets from other namespaces as well by specifying a namespace key in the object? (Only for Cluster, not normal trigger auth) |
No, I think the current approach is perfect but let's improve the docs a bit. |
While this thread is active, @SebastianSchuetze Pod Identity support is being added to key vault, along with workload identity. |
Added clarification - kedacore/keda-docs#753 |
Merged, thanks! |
Authentication via Azure Key Vault is now supported.
Sample for the new TriggerAuthenticationSpec -
Edit 1 - Updated spec and checklist.
Edit 2- Raised documentation PR.
Edit 3 - Update checklist with tests added.
Checklist
Fixes #900