Thanks for working on such an important feature.

However, creating a PR directly instead of an issue, and not providing a description makes this very difficult to review. Honestly, I don't care about the technical implementation of this feature. I only care about being easy to learn and simple to use. Please, show us how do you propose to use this feature:

• How are secrets added, edited and removed?
• Can you have multiple secret files (per environment, per "feature" or package, etc.)? If so, how?
• How do you set, edit and change the key that encrypts the secrets?
• What about deployment? How do you manage the encryption key deployment?
• How does this feature integrates with everything else? Cotnainer parameters, runtime env vars, console commands that display the value of paramenters, etc.
• How does this integrate with Docker, VMs and other virtual setups?
• Can you show us a full example of how to use this? Config needed, commands to execute to setup, etc. You can use the Symfony Demo app as an example.

I want to carefully think about all this before implementing the feature. Otherwise, we can make the same mistakes as RubyOnRails, which added secret support in 5.1, but forgot to add a command to display the secret values and they are adding it in their upcoming 5.2 version. Thanks!

@javiereguiluz I'm writing a blog post, but it will not be ready before I go in vacation. As stated in the description, some people have requested access to my POC, it's why I've opened this PR. If you think it hurt, feel free to close it for now.

This PR doesn't deal with encryption, it only load files at runtime. It's better to use a lower level layer (such as Docker or Kubernetes secrets) for encryption. The purpose of this PR is just to give access to secrets exposed as files. Tests should be self-explanatory.

For the record, and because@javiereguiluz talked about RubyOnRails, I don't see which problem it solves. Ot put another way, it's far from being a complete solution. I do understand that it allows passwords to be safely stored in a Git repository, but the master password still needs to be stored in a file or an env var on machines. So, it does not solve the most important issue to me: how to avoid passwords to be stored permanently on servers. Solutions like Hashicorp Vault (and many others) lets you "fix" that, but then why not use those solutions to store all passwords.

So, regarding this pull request, I think that a good question could be: how do Symfony integrates with solutions like Vault?

To clarify, this PR is not related at all with the secret feature of RoR.

I've updated the PR description with more information. I don't know howHashicorp Vault works, but if it can expose secrets as files, it is compatible with this PR.

To summarize:

How are secrets added, edited and removed?

It's not in the scope of this PR, use Docker or Kubernetes secrets (or anything else) for that.

Can you have multiple secret files (per environment, per "feature" or package, etc.)? If so, how?

Yes. One%secret()% per file.

How do you set, edit and change the key that encrypts the secrets?

It's not in the scope of this PR, use Docker or Kubernetes secrets (or anything else) for that.

What about deployment? How do you manage the encryption key deployment?

It's not in the scope of this PR, use Docker or Kubernetes secrets (or anything else) for that.

How does this feature integrates with everything else? Cotnainer parameters, runtime env vars, console commands that display the value of paramenters, etc.

It's the main goal of this PR, it basically works the same way that'%env()%'. There is probably some more work to do here to not display secrets in debugging tools and logs.

How does this integrate with Docker, VMs and other virtual setups?

Well, it's the main goad of this PR.

Can you show us a full example of how to use this? Config needed, commands to execute to setup, etc. You can use the Symfony Demo app as an example.

See the updated description. I'll publish a blog post and a demo app in some weeks.

%secret(env(DATABASE_PASSWORD_FILE))%

How about these syntax?
%secret(filepath)%
%secret(ENV_VARIABLE, env)% # same as %env()%
%secret(somekey, resolver.service_name)%

Second parameter is for whatever resolver.

The new "secret()" prefix allows fetching the content of a file at runtime. Is there anything specific to "secret" management? I mean, the name could be "file_content()" or some similar alternative that convey what this does actually, isn't it? Not suggesting yet this is what we should do, just wondering :)

This PR duplicates a lot of logic from env() vars management. I think there is another way to reuse the existing code infrastructure in place. I'd suggest to keep using the "env()" syntax, but add special behavior for what'sinside the brackets. "env()" would refer to a generic context, defaulting to env vars, but that we could point to another source for contextual data, like local files.

I tried something similar in#20276. Not sure the syntax nor the feature then are exactly what we want to have now, but I think it could be a good starting point.

the master password still needs to be stored in a file or an env var on machines

This is actually done by the underlying system,Kubernetes allows you to inject "secrets" inside your running container via a pseudo-filesystem. It's basically a way to do the same thing env vars do, but in a much more secure way asenv variables leak out of your app.

@dunglas props for pushing this! \o/

As@marfillaster mentioned, it seems important not having to hardcode path to secret but inject the path via env. This allows ops more flexibility with their setup.

I think the management of "env()"inside "secret()" should be removed because it adds complexity, yet looks unneeded if you allow configuring the relative prefix of paths (ie make that "kernel.project_dir" default configurable). For more advanced use cases, they should be rare (all vaults put secrets in the same root, isn't it?), then admins could use symlinks.

I like the simplicity of%secret(/path/to/file)% without forcing env vars;

parameters:secret:'%secret(/path/to/file.ext)%

I mean, the name could be "file_content()" or some similar alternative that convey what this does actually, isn't it?

Looks like it :)

@nicolas-grekas

unneeded if you allow configuring the relative prefix of paths (ie make that "kernel.project_dir" default configurable)

This is reasonable, if it's per Symfony environment, you could run development with Compose and production with Kube, having different prefix on each.

For more advanced use cases, they should be rare (all vaults put secrets in the same root, isn't it?), then admins could use symlinks.

They actuallycan't ("shouldn't need to", to be precise) because the symlink would need to beinside the container, complicating your whole runtime. You don't want the app image to need any tweaks before it gets run, it should be ready-set-go as much as possible.

For example, if you downloaded an Android APK and needed to switch a few bits around with a hex editor before running it, it wouldn't make a great UX.

Closing in favor of#23901
Thanks for pushing this@dunglas.