Prod Vault Optimization & Vault for Tests

Hey @Florian!

Sorry for the VERY VERY slow reply - super busy time of year! Let me do my best to reply :).

So in general: What is the point of using secrets and vault if there is no solutions for storing secrets in a safe way?
-> is there a way to store secrets in a safe way? Like External Authentication methods or something like that?

The tricky thing about secrets is that you can hide/encrypt all of them... but eventually, your application is going to need access to at least ONE key to "unlock" them. So using something like a vault allows you to minimize the number of secrets that you need to manually worry about from "many" (i.e. trying to handle all of your secret stuff individually) down to just one thing. But yea, it's still ONE thing you need to worry about. But yes, there may be some services that work around this on an infrastructure level - by deploying your decrypted secrets to your server for you in a way where only your server can access them. For example, in platform.sh, you can store secrets directly in their system (e.g. you could literally go to their web gui and "add a new secret"). These are then made available to you unencrypted in your final, deployed environment.

The "first" way to access the vault would be storing the base64 encoded decryption key generated locally to a env variable?

Yup!

-> So everytime a variable for example %env(DEFUSE_SECRET)% would be accessed, symfony would use the stored decryption key in ENV file to decrypt the secret in the vault?

Right again

-> As result of that there is a huge lack of performance in big projects - so the suggestion is: Changing the deployment pipeline to deploy the decryption key -> decrypt the secrets to a env file on the prod server -> deleting the decryption key..

I'm not sure about huge. But yes, since there's some overhead to decrypting, Symfony gives you a performance "escape hatch" so you have the option to avoid that penalty. However, I'd modify tour statement a little bit to this:

Changing the deployment pipeline to decrypt the secrets to a env file using the decryption key during a "build" step. Then, deploy the .env.prod.local file that was created (the secrets files and decryption key do not need to be deployed at this point).

This ultimately gives you a situation very much like platform.sh: when you get up to production, boom! Your secrets are waiting for you in a decrypted format.

What is the point of deleting the decryption key ?

The decryption key isn't needed at this point, so no purpose of having it on production. And since it's highly sensitive, better to not include it (if someone gets root access to your server, you have problems no matter what - but the less you have there the better).

Cheers!

Yo Kevin B.!

Oh man, nice question. I shouldn't be surprised ;). Honestly, this hadn't occurred to me. BUT, it probably occurred to Nicolas Grekas, because it appears to work correctly in this order:

# creates .env.prod.local
bin/console secrets:decrypt-to-local --force --env=prod

# creates .env.local.php which will take "into account" the new values in .env.prod.local
composer dump-env prod

I just tested this - and the final .env.prod.local will contain the plain-text secrets as expected. If you do it in the "wrong" order, .env.local.php simply won't contain the secret... and since the other .env files aren't loaded when .env.local.php is present, the env var won't exist and it will try to load your secrets from the "vault"... which will only work if the decrypt key is present.

So, it looks like all works as expected. But if you see anything different, let me know!

Cheers!