Production Secrets

Hey Luc,

It depends on how "secret" you want to make your dev credentials. Most devs probably not worry too much about it and you can completely set them in your .env file unsecured because well, it's not prod! You may not care too much about dev. Just ask yourself, what if your dev credentials will be compromised? Any serious happened? Probably the only thing you have to do is to regenerate them and that's it.

But about prod - we definitely want to do care of them properly. So you may think of securing on prod secrets. And actually that's where Symfony secrets feature help, and it's really powerful! You may set all the secrets locally and then deploy the project to the production server where you just will need to run one command to decrypt your secrets, you won't need to set all those secrets as env vars, etc. So, it should make easier (speed up) your deployment process. The fact that your secrets are version-controlled is awesome, as we can (anybody on your team can) add new secrets to the vault even doesn't know values of the existent ones. And unlike the real env vars or .env files - secrets are encoded, so nobody can see real values of them by accident.

I don't know about your software of course, it may depends, but as I see they will have to set prod credentials anyway, whether by calling "bin/console secrets:set" or setting it via real env vars on production, or setting them in .env.prod. So, not sure if setting via the command will be more difficult.

> Wouldn't it be great to be able to ask for all defined variables with a command like php bin/console secrets:set --env=prod --read-from-dev?

Probably your secrets not so secure then? Probably easier would be to just set them in ".env" file instead and it will be read in both dev/prod envs?

Anyway, it depends on your project, and you can still continue using .env files and real env vars for this, nothing is wrong with them. So, as I said, it depends on your project. Just give it a try and see if it's something you need or no.

I hope this helps!

Cheers!

Hi Victor,

Sorry, I think I didn't write my problem clear enough, since you missed my point. I understand how the encrypted vault helps me to guard my prod secrets. My problem is, that encrypting the credentials for MY prod does not help others using my software, since they will use a DIFFERENT prod. Let my give you an example. Let us assume that my software needs the following values: DATABASE_DSN and MAILER_DSN.

Now I add the secret content for MY prod:

php bin/console secrets:set --env=prod DATABASE_DSN<br />php bin/console secrets:set --env=prod MAILER_DSN

Then I commit this to git.

Now when a different user gets my software from my gitlab repo, he cannot decrypt these values (obviously) and also doesn't need them. He has to set HIS secret values, by calling the commands from above. The problem is: how does he know that he has to do that, i.e. define exactly these two values? It would be great to have a way to read the KEYS he has to set, that what I meant by the --read-from-dev parameter. That would then work like how the parameters file was created in symfony 2: it started an interactive mode to ask the user for all needed values.

The other problem I have is that I have TWO prod environments, with different credentials. I can create only ONE prod vault and commit to git.

I think the secrets system is a great idea, but it can only be used in exactly ONE use case: I have a team of developers working on a software, which is not used by others, for which there is only ONE prod environment.

Hey Luc,

Ah, I see now... yeah, you probably don't want to share *your* production credentials with your users. :)

> he know that he has to do that, i.e. define exactly these two values?

Well, that's what your README should say I suppose. You should write a little docs about how to run your software, at least how to start it. Let your users know how in the README for example. But yeah, I agree, it would be good to have it working as parameters. Though, I think the idea behind of this is a bit different. You think about it as set all the necessary parameters at once, but good practice is to use Symfony secrets on the go, like you need a new parameter - create it and set to the vault, something like that. I mean, your job is to add new parameters to it instead of create them all at once.

> The other problem I have is that I have TWO prod environments, with different credentials. I can create only ONE prod vault and commit to git.

Hm, that's an edge case I think, but if you have 2 prod envs - you probably have 2 different symfony env? Like "prod" and "prod2"? I haven't tried this, but I'm not sure that "prod" is hardcoded somewhere in Symfony secrets mechanism that means you probably may create as many vaults as you need, just match Symfony env name, and the system will put it into different folders like "config/secrets/prod/" and "config/secrets/prod2/". I probably don't see the problem here, but I may not understand your problem completely or I just didn't have such use case so didn't see the problem personally.

> I think the secrets system is a great idea, but it can only be used in exactly ONE use case: I have a team of developers working on a software, which is not used by others

I don't know 100% the exact reasons behind this Symfony secrets feature, though I think that's the main idea behind of it. It helps with private projects where you have a team of developers working on it. Anyway, if you have your own use cases, and especially if they are not single and some users also have similar problems - please, feel free to open an issue on symfony/symfony repo describing your use cases and discuss if we can expand implementation to cover your use cases. If they are valid use cases - I think people will support this idea. Or at least you will get the exact reasons why it won't be implemented or wasn't be implemented.

Cheers!

Hey Alexey!

Totally agree! :) I fixed it in https://github.com/knpunive... . Thanks for looking over the script in advance, I see the video is not ready for this chapter yet ;)

Cheers!