Add support for loading env variables from secret files

[Radiergummi]

Preface

Currently, Laravel can be configured via environment variables, and to a lesser extent, via default values passed to the env() utility directly in config files.

This is an issue, though: Confidential values provided to applications via the process environment is openly readable by other processes, and thus not always secure. Additionally, the ecosystem conventions promote not modifying the configuration files themselves; Laravel Shift, for example, will downright revert any modifications to default values to the factory value. In our projects, we try to have non-confidential production values in the config defaults, and keep the .env files as small as possible; they have a tendency to grow uncontrollably otherwise.

In container orchestration platforms such as Kubernetes or Docker Swarm, we have a more robust alternative to environment variables: Secret files. That is, sensitive values will be stored securely by the orchestrator, and mounted as files on the application container's file system. Using secret files in Laravel is possible right now by using a replacement env() function (albeit it must be named different due to PHP's function loading..). This, however, must be implemented independently, requires changes in all config files, and breaks e.g. Shift's assumptions.

Suggested solution

By adding the capability to read secret files to Laravel, it would become better integrated with containerised environments and improve the security posture of Laravel apps at once. I believe this is possible in a minimal invasive way, and without adding much overhead to Laravel.

I can see three strategies here:

1. Do the right thing automatically: If a variable isn't defined in the environment, attempt to read the appropriate secret file. If that doesn't exist, fall back to the default.
2. Do the right thing if prompted to: If a variable FOO isn't defined in the environment, but FOO_PATH is, attempt to read it from that path; fall back to the default if that isn't possible (this is what MySQL does, for example).
3. Help users do the right thing: With a new secret() utility that can be passed as the default value to env(), users could recreate the behaviour from 1. and 2. manually: 'key' => env('APP_KEY', secret('/path/to/file.txt')) would perform ordinary env variable lookup, and fall back to reading a secret file.

Option 1 and 2 could be implemented by creating a Laravel-specific env repository that incorporates secret file lookup.
In all cases, this wouldn't be a breaking change: At worst, with option one, an additional disk access will be made, once during startup/caching, to read a missing file. At best, seamless secret support is added to Laravel.

I'd be happy to contribute a PR for this.

---

For reference, here's the secret helper we use right now instead of env in our config files:

function secret(string $name, mixed $default = null): mixed
{
    $secret = static function () use ($name, $default): mixed {
        $name = strtolower($name);
        $path = "/run/secrets/{$name}";

        if (!is_readable($path)) {
            return $default;
        }

        $value = file_get_contents($path);

        if ($value && ($value = trim($value))) {
            return $value;
        }

        return $default;
    };

    return Env::get($name, $secret);
}

[henzeb]

Would this not do what you want? Or am I mistaken?
https://blog.laravel.com/laravel-new-environment-encryption-commands

[Radiergummi]

Not quite, no. I even think storing an encrypted copy of all your secrets in source control is the worst thing you can do: You're essentially granting anyone that gets their hand on your source code infinite attempts at guessing your encryption key.
Even worse, if you happen to rotate the key, all previous (possibly compromised) versions are still present in the source repository; so you need to rotate all secrets within the .env file too to be sure.

Now, we could follow the Vapor workaround, that is, create an encrypted .env file on the fly during CI deployment and mount that as a secret. This voids all the neat benefits of real, separate secrets, though: You cannot rotate individual values anymore.

[Angel5a]

I can clearly see one problem with this approach: What should be the root path for all secrets? We can't just hardcode "/run/secrets/" it's totally wrong. So we need a config or .env, to pass this path. Kinda loop dependency.

[Radiergummi]

Yup, that's an opportunity for a BC, although the example is a little contrived: For an existing application that'd employ such a combination of variables, a .env file or at least a set of somehow-defined environment variables would exist, so the Env loader would never reach the path-checking default handling code.

Still, I'd also expect this to be part of a new major version.

[Angel5a]

I think, for sure it can be easily done via separate package. Take your secret function improve it as described, wrap it and suggest in laravel blog/news/here. Would it be required, why not?

[Radiergummi]

I think, for sure it can be easily done via separate package. Take your secret function improve it as described, wrap it and suggest in laravel blog/news/here. Would it be required, why not?

For one, Laravel Shift will remove any modifications to env calls in configuration files, which is a massive hassle on every version migration. This means we can't just use a custom alternative to env in config files.

We also cannot replace the env function from a package, because autoloading does not support that.

And we can't configure dotenv properly, because Laravel uses static methods instead of injecting it properly.
The only thing that could work is attempting to override the config binding in the container, but that sounds like poor design.

Besides, I would really like to see native support for more secure configuration methods in containerised environments in Laravel, if only for the sake of holding up the batteries included promise it always held up.

[Radiergummi]

On closer scrutiny, there is no way to hook into environment variable loading at all: The Env class is not initialised from the container and creates an immutable repository.
I don't understand why people go to such great lengths to prevent extensions...

[Angel5a]

Yes. It's not friendly enough.
Definition of env function is wrapped into function_exists, so we can redefine it by placing our definition before any other package autoload (can be done with extra composer plugin). But ones you forget to add an extra record to composer.json - you'll get a bad time with order depend behavior.

[sca1235]

Agreed there needs to be something. Been searching and found no great solutions yet. Was looking at doing something like this https://github.com/preciousaang/laravel-gcp-secret-injector and https://gist.github.com/koistya/5fb986553efd21796e330f67cd660b2e

[motdotla]

have you evaluated dotenvx ?

[sca1235]

Not a fan of committing env to git even if encrypted. Separation increases security. Also doesn't solve the problem with containers.

[bryceray1121]

Following. This would instantly simplify our environment configuration.

[wfjsw]

I believe you can extend this behavior by writing a service provider and inject your secret into the config tree in the register function, so you don't have to touch env at all, though this probably looks dirty....

On the other hand, I am thinking about connecting Laravel to some centralized secret facility (for example, Infisical) where it fetches secrets dynamically from a remote host. Putting the API logic into config dir looks like bad practice, and it apparently will break config:cache. I believe I could hack in environment variables to php-fpm through fastcgi_param by using lua wires on the OpenResty gateway, but it also works against config:cache in some way that I will have to use env helper instead in the code.

[Radiergummi]

You can do all kinds of shenanigans to hack support for this into your application, but I think it would be better to have support in the framework—or at least a configuration component that allowed us to do it elegantly ourselves.

[wfjsw]

Idk I can't come up with a more tailored way to handle this situation because everyone has their own way for doing the secrets. If writing PHP is required in the end then service providers actually are simple enough to justify all use cases.

[Radiergummi]

I respectfully disagree. You can make that argument for everything, but abstracting common functionality is why we use a framework like Laravel in the first place. Secret files are a widespread mechanism of injecting secret values into applications, and extending the Laravel configuration system to accommodate for them is a great way to improve security across the entire Laravel user base. Everyone having their own way of doing this is exactly the problem.
Given that it touches a security-related issue, and it would be so easy to do this, I don't think advertising rolling your own is the way to go, especially given all the pitfalls you may run into.

[wfjsw]

My fault. We are probably looking at this problem in different aspects.

I have reviewed your first argument and this article again and it seems what you want is not to put the .env files into OS process env list.

There's a much undocumented helper in the framework currently doing this (lots of funny stuff in Laravel are undocumented extensively, so I will take it seriously):

\Illuminate\Support\Env::disablePutenv();

By putting it into AppServiceProvider your env file will no longer be put into OS env list, making the .env file a secret file in its entirety.

Also you can have .env and .env.production should you want to separate regular env and secrets into 2 files.