You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently support appRole and kubernetes auth method to authenticate with Vault.
The main problem with kubernetes is that the serviceaccount token being present on the filesystem has to be read and it makes it hard to test. The way we've tested the kubernetes authentication method is by using an io.Reader that the vaultLogin method passes to the actual method.
This is a clean and frequently used approach to test pieces of code that depend on filesystem calls, but on the other hand it moves the problem to a different method vaultLogin which selects the authentication method.
This issue aims to open a discussion on how to tackle this moving forward.
Some ideas:
Open the file in main.go pass it as a config value. We already pass the roleID and secretID as config, but those are external identity attributes. What I mean by this, is that secrets-manager it's already running as a k8s pod, so it's already possible to read the token and there's no need to pass it as a Config attribute... it's not a flag so it feels weird to me.
We currently support
appRole
andkubernetes
auth method to authenticate with Vault.The main problem with
kubernetes
is that theserviceaccount
token being present on the filesystem has to be read and it makes it hard to test. The way we've tested thekubernetes
authentication method is by using anio.Reader
that thevaultLogin
method passes to the actual method.This is a clean and frequently used approach to test pieces of code that depend on filesystem calls, but on the other hand it moves the problem to a different method
vaultLogin
which selects the authentication method.This issue aims to open a discussion on how to tackle this moving forward.
Some ideas:
main.go
pass it as a config value. We already pass theroleID
andsecretID
as config, but those are external identity attributes. What I mean by this, is thatsecrets-manager
it's already running as a k8s pod, so it's already possible to read the token and there's no need to pass it as aConfig
attribute... it's not a flag so it feels weird to me.cc @eduardogr
The text was updated successfully, but these errors were encountered: