Keda and Hashiorp Vault Authtication using serviceAccount as Auth method

[btwseeu78]

I am currently Testing Hashicorp Vault authentication for keda, we noticed the way keda uses is it directly uses serviceaccount token for keda for keda operator now i am getting some issues with and definitely need better examples on authentication.

I found the Architecture is quote troublesome.

Since the triggers or all the triggers will use operator service account to communicate that means we need a key than can read creds from all paths , that itself is problematic to have, and also this can not used at all in shared cluster where there are multiple project hosted since it mean violation of policy.

Suggestion would handling it how external secret operator does since its one of the standardized way to pull secret from vault.

Also we need more logs for Auth errors seems very limited.

for now im getting token not found error on my trigger,

also we are seeing this error as well for some reason.

2023-06-01T10:13:28Z    INFO    Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference                            {"controller": "scaledobject", "controllerGroup": "keda.sh", "controllerKind": "ScaledObject", "ScaledObject": {"name":"kedalab-scaled-vault","namespace":"monitoring"}, "namespace": "monitoring", "name": "kedalab-scaled-vault", "reconcileID": "021a8854-1a92-4b9b-bed5-d08ca2e6a605"}
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x2f61695]
``

[btwseeu78]

For now i need to test i believe the nil pointer due to not providinghashiCorpVault.Credentials field as blank and also that field does not make good use as service account mountPath is fixed in pod.

now more question what should be the data in vault is it should be in plain text or it will be in base64 encoded inside vault,
sole love about authentication doc would help us maybe :)

[JorTurFer]

FYI @kedacore/keda-core-contributors

[JorTurFer]

I get your point about access segmentation and it makes sense but I think that it's already supported (or at least almost supported). If you use token as hashiCorpVault.authentication you can provide a token with scoped privileges.

In any case @kedacore/keda-core-contributors , I have noticed that the token is placed in the TriggerAuthentication and not in a secret. IMO we should deprecate this approach in favor of reading them from a secret. WDYT?

About the panic, definitively we should figure out why it has happened and fix it

[btwseeu78]

Yes with JWT it's fine,but since keda will be used by kuberntes and vault already support the binding,it would probably be a good feature,
Also the service account based bind is much hassle free for user since they don't need to manage the token they just need to know the serviceaccount name bound to vault for that namespace,also it uses api server so it's easier and secure.
Also I'm not in favour of using creds from operator pod, since we have a separate object to deal with authentication,it should not refer operators service account details or any env variable in my belief. Maybe I will wait what others think of this case.

[JorTurFer]

let's wait until other folks share their thoughts

[ksemele]

I am not an expert in development, but it seems to me that we could consider working in a way similar to https://github.com/bank-vaults/vault-secrets-webhook ? There are sidecars spawned with every Pod and use the Pod service account.

Or something similar, so as not to be tied to the service account of the KEDA operator. Let a small pod with the necessary service account be raised for each trigger and request secrets in the vault...

[btwseeu78]

A better example as I said would be External Secret Operator. Just to make sure we don't fail the pod in case the sidecar fails

…

On Thu, 8 Aug, 2024, 11:22 am Aleksei Krugliak, ***@***.***> wrote: I am not an expert in development, but it seems to me that we could consider working in a way similar to https://github.com/bank-vaults/vault-secrets-webhook ? There are sidecars spawned with every Pod and use the Pod service account. Or something similar, so as not to be tied to the service account of the KEDA operator. Let a small pod with the necessary service account be raised for each trigger and request secrets in the vault... — Reply to this email directly, view it on GitHub <#4601 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIGKDGU7YWTYQBB4C4YN33ZQMBSRAVCNFSM6AAAAABMFXTU62VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRXGEZTONI> . You are receiving this because you authored the thread.Message ID: ***@***.***>