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.

2 Answers2

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.

James Shewey
  • 3,752
  • 1
  • 17
  • 38