Add kms wrapper authentication using kubernetes service-account

[fafg]

this PR add a possibility to boundary pod uses its kubernetes service-account to authenticate against vault to consume kms transit keys.

4 new parameters was introduced:

        // internal vault role bound to the k8s service account
	withRoleName                string

        // where the kubernetes auth method is mounted (default kubernetes)
	withKubernetesMountPath     string

        // where vault sdk should looking for the jwt service account token (ENV or PATH)
	withServiceAccountTokenEnv  string
	withServiceAccountTokenPath string

with these parameters the wrapper can authenticate against vault without specify: token, credentials or neither client certificates.

[hashicorp-cla]

All committers have signed the CLA.

[marcelosf89]

That feature will help me a lot , great job ❤️

[jefferai]

Apologies, but I am not inclined to accept this.

Starting down this path of adding Vault authentication methods directly into the transit wrapper means pulling in more and more transitive dependencies (especially cloud libraries). One of the benefits to v2 of this library is that we have minimal/required dependencies in each wrapper since they are split into separate Go modules.

Additionally, this means more code that has to be maintained, when the Vault team already maintains the login code within Vault Agent. It adds significant complexity to the wrapper. The wrapper then has to be responsible for reauthentication as well.

As I noted in the Boundary issue, I think the right approach is to enhance the wrapper to accept a file. There are already libraries that Boundary uses to accept value from file/env/directly so it could even maintain the existing config token and env token values but allow env/file prefixes (I can point to the right location to find this library if you're interested). Then Vault Agent can be responsible for maintaining the token, including reauthenticaiton, and the existing logic could be enhanced to re-read new values from this location on disk periodically to ensure the token in use is kept up-to-date.

[fafg]

Apologies, but I am not inclined to accept this.

Starting down this path of adding Vault authentication methods directly into the transit wrapper means pulling in more and more transitive dependencies (especially cloud libraries). One of the benefits to v2 of this library is that we have minimal/required dependencies in each wrapper since they are split into separate Go modules.

Additionally, this means more code that has to be maintained, when the Vault team already maintains the login code within Vault Agent. It adds significant complexity to the wrapper. The wrapper then has to be responsible for reauthentication as well.

As I noted in the Boundary issue, I think the right approach is to enhance the wrapper to accept a file. There are already libraries that Boundary uses to accept value from file/env/directly so it could even maintain the existing config token and env token values but allow env/file prefixes (I can point to the right location to find this library if you're interested). Then Vault Agent can be responsible for maintaining the token, including reauthenticaiton, and the existing logic could be enhanced to re-read new values from this location on disk periodically to ensure the token in use is kept up-to-date.

Hi @jefferai, it makes sense to me. Thank you for reaching out back.

Maybe a new wrapper?

what about adding a K8s as a new one to this list?

In my current setup, I have Vault already, and my applications connect using the Vault Kubernetes auth method. It would be easier to keep Boundary as an application to connect to my Vault similarly, instead of a vault agent setup (which I am not using).

[jefferai]

Kubernetes isn't a wrapper though -- it's not providing encryption and/or signing.

One possibility, if you wanted to maintain your forked transit and use it, is we could enable loading KMS plugins from somewhere other than the built-in set. We generally have plans in Boundary to enable an external plugin ecosystem (along with a million other things :-) ) and there's a lot needed for that, but we might be able to scope out something small for plugins located on-disk. Can't make promises -- if you want to see how quickly we could go down that route then I'd make a feature request on the Boundary tracker and reference this comment here so that the product team gets state.

[hb9cwp]

... we could enable loading KMS plugins from somewhere other than the built-in set.
We generally have plans in Boundary to enable an external plugin ecosystem ... we might be able to scope out something small for plugins located on-disk [see https://github.com/hashicorp/boundary/issues/2454].

This would also come in handy to integrate other KMS wrappers that others develop and maintain, such as #262, or hashicorp/vault#25025 .
KMS plugins would not only decouple source code, but also isolate Vault from processes of these plugins.
@jefferai Is work in progress to enable loading KMS wrappers as plugins into Vault? Thank you.