How is vault better than env file in terms of security?

Vault
1

Hi,
I’m learning Vault to see if I’d like to use it in my service. My main question about Vault is: how does it advance security of credentials?
I understand that managing credentials in one place is good and I see it has fancy functions.
But in my case, I consider using it to replace .env file on my web server. .env file is vulnerable when access to my server is somehow snatched by an attacker. The attacker can access to filesystem then attacker can get all credentials.
Let’s say I’m gonna introduce Vault to my system.

  • Then all the credentials in .env file will be moved to Vault.
  • my server will only hold credential for my server to access to Vault in filesystem. Let’s call this credential Foo.
  • there should be a process to initialize all credentials before starting service, which will be retrieved from Vault by Foo.

So, if an attacker can get Foo from filesystem, then all credentials are at risk anyway. I don’t see benefits using Vault in security aspect.
Please correct me if I got something wrong. :slight_smile:

2

Every secret in Vault is encrypted using the encryption key which is encrypted by the master key. The master key is somehow “splitted up”. To get secrets out of vault you will need to have the right token with the corresponding policy and vault must be unsealed using x out of y unseal keys to reconstruct the master key. These unseal keys should be hand out to several person seperatly.

If the attacker gets Foo, but Foo is not the root token, only things the policy for Foo allows will be open for the attacker. You’ll have to restrict and permit access by fine grained policies. The advantage is, that your env file will hold every secret open for everyone with access. Vault will give you the secrets you are allowed to get.

3

Thanks for the answer @Wolfsrudel.
So, what I understood is, using Vault makes sense only if permission policy on Vault is well defined, and server holds credential that has access to credentials in Vault only it needs.
But in the real world, main web server should have an access to main database, which means it needs database credentials, and that means access to web server makes free pass to database.
So, my thought is like this:

  1. Securing web server access it the most important, and I have to make all my effort to prevent it compromised.
  2. If web server access is compromised, other security effort is not much meaningful. Using Vault doesn’t help much.

Do you have other opinions?

4

Hi, @jooddang,
I have some thoughts, but to give an answer to your questions I’d need to know a bit more so i have a couple of questions regarding the case you mentioned.
How do credentials get to the .env file? Is the .env file stored on the server or is it generated during deployment?
If you decide to change credentials, what would the process be?

5

Hi @rebrendov , thanks for the interest to my question.

  1. Currently, yes, credentials reside in .env. And, the web server is running on one instance on a cloud service. I add/update credentials manually when needed by ssh through my VPN server. ssh inbound is limited to the VPN server IP address. (I think it’s the best security practice in current situation)

  2. Is there any added value of Vault for current situation?

  3. I’m thinking to move on to CI/CD service like CircleCI, then they should have config settings, where credentials are stored, then the service will deploy new build to the web server with the credentials.

  4. In #3 flow, probably I can make a shell script to get credentials from Vault before server restarts. Then, config settings of CI/CD service will have credential for Vault access only. Is this better than #3 in security perspective? If the CI/CD service is compromised, security implication would be the same - attacker will acquire credentials from both CI/CD and Vault anyway.

6

Thank you for your answer @jooddang,

  1. For your current case there’s something that can be improved with Vault, but it would require a code change. You can store your credentials in Vault, and add vault integration in the application code so it would watch for credentials change and update it if needed.

    • To not expose access to Vault in case your server is compromised, you could create a token[1] with ttl=1h and after your application started - update a token to a new one through Vault API. The initial token will become invalid after an hour - so even if an attacker will get access to your server - he will only find stale token from Vault that can’t be used to access the secrets.

  2. About CI/CD pipeline - same principal applies, instead of storing in CI/CD service credentials from Vault that allow you to access secrets, you can store a token that will allow you to generate child tokens. In the case your CI/CD is compromised - the attacker would need to know the address of Vault to generate a token and then use it to access Vault’s secrets. And also you can revoke parent token to revoke access of all children tokens.

[1] More about tokens here