Vault token usage

I am a beginner at Vault and trying to integrate it for my company. I see that vault can be accessed through APIs via Tokens.

My question is, if I use this token in my application to fetch credentials, and if token get compromised, anyone can use it or call the api in another application/local or view the credentials. So, how it is helpful or how can we overcome this every time ?

1 Like

Tokens are the same type of secrets like passwords, which you need to keep in a safe place.
There are some technics to improve security when working with tokens:

  • minimize tokens TTL
  • minimize privilegies, assigned to the attached policies
  • use wrapping tokens to minimize tokens exposure
  • enable audit and alerting on suspicious activities
  • for Vault Enterprise you can leverage Sentinel policies to implement complex conditions, like source IPs filtering, schedule etc.
1 Like

I understand and appreciate your response. However,

  • minimize tokens TTL - this will expire the token and devs need to generate and store that new token (always) in the code. Changing code often for this purpose is not feasable.

  • minimize privilegies, assigned to the attached policies - So, we have generated token only for a specific user and the same is being passed in the app code, point is, if someone runs that code, apart from that user, his credentials will be taken in account. How to avoid that!?

On an whole, my devs asks that what is point of using Vault as an additional application to call from code, if that can also be compromised or can be used to get the ‘actual credentials’. Instead, if they store the credential directly in the code, serves the same purpose.

P.S Being an implementor, I am trying to maximise the security and solve these for my team. Kindly excuse if I said anything incorrect.

1 Like

You should avoid storing and using long-lived credentials. Try to leverage dynamic and short-lived instead. This is the whole point of such tools like Vault.
For example, you can use K8s service account JWT token and authenticate against Vault using K8s auth method. Thus you will always have a fresh and short-lived (1h) Vault access token.
For VMs you can use a workload identity token, provided by a cloud provider.

1 Like

Apologies again but again we’re deflecting from the point of using Hashicorp Vault. Why do we need another auth method (k8s) to support hashicorp vault.
Yes, we do not use K8s & cloud providers for our application but rather would like to use vault for storing our credentials in a secured way rather in plain text in the app code.

Also, we are open to use any other Hashicorp vault’s auth method apart from ‘tokens’ .

Back to square one : If I pass that auth method in my code still someone who has access to code (stash/github) will able to get through it and get actual secrets from vault.

1 Like

Not sure that I understood the question… You should not keep any credentials in you source code, of course. Auth method config without credentials (e.g. approle secret or JWT) is completely safe.
You mentioned GitHub, if you use GHA you can configure JWT auth method as GHA can generate JWT tokens.
If not, you can use approles with short lived approle secrets, the concrete configuration depends on you orchestrators and workflow.


@sumit.gupta7060, read this:


Appreciate your suggestions @muzzy & @Joffrey .

I shall check on these and get back after integration. Thank you!

1 Like

As per my knowledge,

  1. Use Short-Lived Tokens: Minimize lifespan to reduce risk.
  2. Dynamic Secrets: Generate on-demand, time-limited credentials.
  3. Token Renewal: Regularly renew tokens without extending their lifespan.
  4. Minimal Permissions: Assign least privilege with strict policies.
  5. Environment-Specific Tokens: Limit tokens to specific environments.
  6. Logging and Monitoring: Detect and respond to unusual activity.
  7. Secure Application: Protect your code and infrastructure.
  8. Revocation: Be ready to quickly revoke compromised tokens.
    I hope this will help you,
    Thank you
1 Like