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.