2

What could be considered the most secure way of authenticating in HashiCorp Vault by an application running in a Kubernetes cluster?

The AppRole method is nice, but implementing AppRole implies that the secret_id must be passed to the application. This means that the secret_id must be saved somewhere in the Deployment's configuration or in a Secret as plain text, which doesn't seem secure because someone could steal it.

The Kubernetes method seems to be a bit better, but it implies that the application should take the ServiceAccount's token (e.g., from /var/run/secrets/kubernetes.io/serviceaccount/token), which doesn't seem to be secure as well. Someone could break into the application's container by exploiting the application's vulnerability, read this token, and authenticate in Vault with this token just the same way the application does.

I consider the JWT method a bit more secure. In this case, we could make the application generate its own RSA key, then sign a JWT token with this key and process the requests from Vault when Vault knocks back for JWKS. In this case the application keeps its private key in memory only and doesn't store the private key anywhere (here's my very simple example of implementation: https://gitlab.tucha.ua/khmarochos/vault-client-demo/). But, frankly speaking, I would like to find a simpler (yet still secure) solution.

Would you be willing to share any ideas on that topic? What approach could be considered simpler and more secure?

Thank you.

1
  • AppRole is basically username:password; you need to rotate it from time to time. I would go developer.hashicorp.com/vault/docs/auth/… and pick the one where tokens are short lived. Keep in mind that above scenarios your application needs to be HC Vault aware. An alternative like injector or other developer.hashicorp.com/vault/api-docs/… to fetch and keep secrets in sync in which case the application may consume ENV variables. First work on threat model then you can decide on the HCV approach.
    – Kyslik
    Commented Apr 6 at 10:14

2 Answers 2

1

The key factor here is that the credential that you use to authenticate to Vault should be short-lived. So in case it gets stolen the attacker will have only a very limited time to use it.

Of all the auth methods the Kubernetes auth method is the most secure since Kubernetes service account token is short-lived since Kubernetes 1.22 (1 hour TTL by default), cannot refresh itself (it's refreshed by kubelet) and is automatically invalidated on pod restart.

0

As noted above in Vasilii's answer, you should be using short lived tokens and using the vault to change credentials upon use or on a regular interval (eg, HashiCorp database drivers can rotate credentials in your database).

In addition, you can use the provided drivers to ensure that the token is used to retrieve the credentials and those go directly into application memory only and are never written out to disk.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.