Use Vault token from environment when creating credential store

Boundary
,
1

I run both Vault and Boundary in Kubernetes, I have Vault setup to trust K8s ServiceAccounts so they can request tokens, is it possible when creating a Vault credential store to use the VAULT_TOKEN env var?

2

It’s called cubbyhole.

3

Boundary currently requires a Vault orphan token (with a defined set of permissions) as part of the credential store config – it won’t authenticate to Vault from the environment.

I believe one reason for this (or at least one consideration that comes into play) is that the permissions Boundary needs for itself (e.g. using Vault Transit for KMS if that’s configured, which it will do using platform identity like k8s service accounts) are distinct from those it needs to manage credentials for credential stores (the ability to manage credential leases, for example). If you used the environment to provide credential store permissions, then you’d have to give those permissions to whatever underlying platform identity you’re using for Boundary, which raises security issues. Since Boundary encrypts the token at rest, giving it an orphan token is still secure and allows the platform identity underlying Boundary to have more minimal permissions than would otherwise be the case. It also allows you to easily revoke that token (and therefore the leases associated with it) if you need to without disabling Boundary entirely.

4

Thanks for the reply, this makes sense.

5

@omkensey I can see the delineation you’re pointing out there and it makes sense. I’m attempting to get Boundary stood up in EKS and have the controller and worker pods separated. The controller pods are using Vault Agent injection to get the database credentials needed. This is authenticated to Vault using the kubernetes auth method via the service account. I’m also looking at using IRSA the AWS KMS key credentials authorizing the IAM Role attached to the service account. Which sounds like it fits with what you’re stating.

I really don’t want to define long lasting tokens and trying to use dynamically created tokens as much as possible just as I push IAM Roles vs IAM Users with Access Key ID and Secret Access Keys as much as possible. Would it not then be possible to use Vault AppRole auth method to assign credential stores? Or even still use the Kubernetes auth method but have the ability to define different roles? Even though authenticating via Kubernetes, you could still have different roles defined which have different policies applied to them.

1 Like