Answers: <p>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.</p>
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-04-21T14:43:10.600Z
Answers: 2024-04-21T14:43:10.600Z
Answers: Vasilii Angapov
Answers: <p>As noted above in <a href="https://devops.stackexchange.com/a/19196/2845">Vasilii's answer</a>, 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).</p>
  <p>In addition, you can use the <a href="https://devops.stackexchange.com/a/19196/2845">provided drivers</a> 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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-05-21T16:13:30.207Z
Answers: 2024-05-21T16:13:30.207Z
Answers: James Shewey
Body: <p>What could be considered the most secure way of authenticating in HashiCorp Vault by an application running in a Kubernetes cluster?</p>
  <p>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.</p>
  <p>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.</p>
  <p>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: <a href="https://gitlab.tucha.ua/khmarochos/vault-client-demo/" rel="nofollow noreferrer">https://gitlab.tucha.ua/khmarochos/vault-client-demo/</a>). But, frankly speaking, I would like to find a simpler (yet still secure) solution.</p>
  <p>Would you be willing to share any ideas on that topic? What approach could be considered simpler and more secure?</p>
  <p>Thank you.</p>
  
Comments: CC BY-SA 4.0
Comments: 2024-04-06T10:14:47.397Z
Comments: AppRole is basically username:password; you need to rotate it from time to time. I would go https://developer.hashicorp.com/vault/docs/auth/kubernetes#how-to-work-with-short-lived-kubernetes-tokens 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 https://developer.hashicorp.com/vault/api-docs/relatedtools#third-party-tools 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.
Comments: Kyslik
Tags: <kubernetes><security><authentication><secret-management><hashicorp-vault>
Title: Best practices of authentication to Vault
UserDisplayName: Volodymyr Melnyk
ThreadText: # Best practices of authentication to Vault
  
  (Asked by: username_0 on 2024-04-03)
  
  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.
  
  **Tags:** kubernetes, security, authentication, secret-management, hashicorp-vault
  
  > **Comments:**
  > **username_1**: AppRole is basically username:password; you need to rotate it from time to time. I would go https://developer.hashicorp.com/vault/docs/auth/kubernetes#how-to-work-with-short-lived-kubernetes-tokens 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 https://developer.hashicorp.com/vault/api-docs/relatedtools#third-party-tools 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.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2024-04-21. Score: 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.
  
  
  ---
  
  ### Answer by username_3 on 2024-05-21. Score: 0
  
  As noted above in [username_2's answer](https://devops.stackexchange.com/a/19196/2845), 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](https://devops.stackexchange.com/a/19196/2845) 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.
  
  
  ---
  
  