I am not sure if this considered an anti-pattern, but in one of my teams, we wrote a lightweight generic Secrets library with configurable/pluggable backends (such as AWS Secrets Manager). It had a configurable local cache, with per-parameter overrides to bypass the cache. It meant vendor specific fetch logic was in the pluggable backends, while the app and the secrets lib remained vendor neutral.

When we moved it to Vault, it was seamless. Just meant adding our Vault backend wrapper as a dependency and updating the config to use the Vault backend.

How is the kubernetes secret API lock in? Genuinely wondering - were you trying to use that deployment yaml for something other than a kubernetes deployment? For most applications, you should be mounting the secret on your application, then you can inject it as either an environment variable or a json file that your application reads in an environment agnostic way.

Then, on the backend, you can configure etcd to use whatever KMS provider you like for encryption.

+1 to all of this.

This is why I continue to use env vars and dotenv for configuration. They are extremely simple, work well, and are compatible with secrets managers and other secrets tooling.

Though lately I've been veering into sOps the last few years. YAML is just so nice for expressing how an app should be configured, and sops makes encrypting chunks of it so easy. Dealing with GPG keys can be challenging though, which Vault/OpenBao solve, but then lock-in becomes an issue (though less so with OpenBao).

> Getting secrets from Kubernetes Secrets API I've seen done but lock in again.

I don't get this part. Why would you use Kubernetes secrets alone for storing secrets if they are not encrypted by default? Using k8s secrets only makes sense if (0) you are using k8s, (1) you already did some groundwork like encryption at rest for the control plane, and (2) you are actually using a solution like Secrets Store CSI Driver (or alternatives - just don't depend on k8s secret being actually more secret than a ConfigMap by default).

And then, it's the opposite of lock-in as the Secrets Store CSI Driver uspports multiple backends, including open source Conjur.

You can have a command setting that is invoked to get the string. This way you don't have vendor login, but also don't need a separate template step.

I think it's worth specifically calling out that the right way to set environment variables is in execve() only, as communication across an exec() is the precise niche for which they are the right tool.

Why would you ever call setenv in library code to begin with?

AFAIK Solaris solved that problem but Linux refuses to copy their solution.

NetBSD has had getenv_r() for ages, [0] and I believe FreeBSD has very recently copied it. [1] If FreeBSD has it, macOS might eventually adopt it too. People tried already to get it into both glibc and POSIX, and it was rejected, but if it becomes more common on other platforms, that increases the chance they’ll both eventually accept it.

[0] https://man.netbsd.org/getenv_r.3

[1] https://github.com/freebsd/freebsd-src/commit/873420ca1e6e8a...

Since at least 2012, environment variables have been at least as secure as ordinary memory:

    commit b409e578d9a4ec95913e06d8fea2a33f1754ea69
    Author: Cong Wang <xiyou.wangcong@gmail.com>
    Date:   Thu May 31 16:26:17 2012 -0700
    
        proc: clean up /proc/<pid>/environ handling

cmdline is a different story.

> Any good solutions for passing secrets around that don't involve environment variables or regular plain text files?

memfd_secret comes to mind https://man7.org/linux/man-pages/man2/memfd_secret.2.html

I haven't seen much language support for it, though. On one part maybe because it's Linux only.

People that write in Rust (and maybe Go, depends how easy FFI is) should give it a try.

I wanted for a time to get some support for it in PHP, since wrapping a C function should be easy, but the thought of having to also modify php-fpm put a dent in that. I can't and don't want to hack on C code.

In practice it'd be great if the process manager spawn children after opening a secret file descriptor, and pass those on. Not in visible memory, not in /proc/*/environ

> - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer.

Here's the thing though, the security model of most operating systems means that running a process as a user is acting as that user. There are some caveats (FreeBSD has capsicum, Linux has landlock, SELinux, AppArmor, Windows has integrity labels), but in the general case, if you can convince someone to run something, the program has delegated authority to act on behalf of that user. (And some user accounts on many systems may have authority to impersonate others.)

While it's by no means the only security model (there exists fully capability based operating systems out there), it's the security model that is used for most forms of computing, for better or worse. One of the consequences of this is that you can control anything within your domain. I can kill my own processes, put them to sleep, and most importantly for this, debug them. Anything I own that has secrets can grab them my ptrace/process_vm_readv/ReadProcessMemory/etc.

--passphrase-fd was always the correct thing to do (gpg has had it for ages), but support for that is very meager. I mean, you can’t even kubectl login using environment variables, you pretty much have to pass tokens through command-line arguments and we’ve known that’s terrible for around forty-five years.

You've described the classic Unix security model, with minor improvements. While decent for the time it is showing its age. Specifically the difficulty in adapting to cheap, ubiquitous computing which it wasn't designed for.

If you need to keep secrets from other processes—don't run them under the same user account. Or access them remotely, although that brings other tradeoffs and difficulties.

> Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice:

I think environment variables are recommended to pass configuration parameters, and also secrets, in containerized applications managed by container orchestration systems.

By design, other processes cannot inspect what environment variables are running in a container.

Also, environment variables are passed to child processes because, by design, the goal is to run child processes in the same environment (i.e., same values) as the parent process, or with minor tweaks. Also, the process that spawns child processes is the one responsible for set it's environment variables, which means it already has at least read access to those secrets.

All in all I think all your concerns are based on specious reasoning, but I'll gladly discuss them in finer detail.

Any good cross-platform and easy ways to share secrets without using environment variables?

Linux security model is pretty broken without namespaces. systemd has some bells and whistles that help but if you want something better than environment variables you're naturally going to reach for cgroups.

Not an answer, but I do wish there was a low level primitive and a corresponding high level language construct to pass around secrets.

Something like: my_secret = create_secret(value)

Then ideally it's an opaque value from that point on

> Any good solutions for passing secrets around that don't involve environment variables or regular plain text files?

Plain text files are fine, it's the permissions on that file that is a problem.

The best way is to be in control of the source to the program you want to run then you can make a change to always protect against leaking secrets by starting the program as a user that can read the secrets field. After startup the program reads the whole file and immediately drops privileges by switching to a user that cannot read the secrets file.

Works for more than just secrets too.

> On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer.

This is a very good point I'd never realised! I'm not sure how you get around it, though, as if that program can even find a credential and decrypt a file, if it runs as the user then everything else can go find that credential as well.

> Any good solutions for passing secrets around that don't involve environment variables or regular plain text files?

Honestly, my answer is still systemd-creds. It's easy to use and avoids the problem that plain environment variables have. It's a few years old by now, should be available on popular distros. Although credential support for user-level systemd services was added just a few weeks ago.

A TL;DR example of systemd-creds for anyone reading this:

    # Run the initial setup
    systemd-creds setup

    # This dir should have permissions set to 700 (rwx------).
    credstore_dir=/etc/credstore.encrypted
    # For user-level services:
    # credstore_dir="$HOME/.config/credstore.encrypted"
    
    # Set the secret.
    secret=$(systemd-ask-password -n)
    
    # Encrypt the secret.
    # For user-level services, add `--user --uid uidhere`.
    # A TPM2 chip is used for encryption by default if available.
    echo "$secret" | systemd-creds encrypt \
        --name mypw - "$credstore_dir/mypw.cred"
    chmod 600 "$credstore_dir/mypw.cred"

    [Service]
    LoadCredentialEncrypted=mypw:/etc/credstore.encrypted/mypw.cred

At least systemd v250 is required for this. v258 for user-level service support.

I've used keyring, but ultimately does not solve the issue of every application running under the same user.

https://pypi.org/project/keyring/

If are like most users you have secrets stored in read-protected files in ~/.ssh. There's nothing wrong with that.

I use https://mise.jdx.dev/

Not sure if any other high level languages have it, but Node.js has just added command line flags to trace precisely all env var accesses and modifications:

https://nodejs.org/api/cli.html#--trace-env

Since you can set/unset/modify env vars in so many ways with different APIs, this sounds super useful in complex debugging scenarios.

"One namespace ought to be enough for anybody".

Heh, you can put hjkl in that neo conservatism bucket. Vi hjkl are the way they are because of a dumb terminal from 40+ years ago, which had fewer units sold than the Nokia N9 smartphone.

> but the usual procedures you find online stops working once you reboot (or close the terminal I think?)

The environment isn't persistent between sessions. That means you need to make the change in a way that runs on every new session (login or new terminal window).

Depending on how your system is configured:

.bash_profile gets run once on every login

.bashrc gets run once on every non-login new session (i.e. a new terminal window)

It's typical, if using these files, to do something like this:

    if [ -f ~/.bashrc ]; then
        source ~/.bashrc
    fi

If you're not even using bash or bash-likes at all, but instead something like Zsh, fish, etc you'll need to set things the way they want to be set there.

> They should add a simple env var GUI like Windows has that just works, and isn't terminal-specific

This doesn't exist in linux, because there isn't "one place" that all possible terminals draw from. Conceivably, it's possible to write a GUI tool that reads your .bashrc file, looks for anything that resembles a variable, parses the bash code to look for ways it is set, and then present a GUI tool that could update it in common cases, but... it's way easier to just write the change in a text editor.

Funny, as a primarily linux user the windows behaviour irks me to no end, it's the cause of so many recurrent problems on end-user machines with so many apps that pollute environment.. and then you wonder why something doesn't work and then it turns out that for some reason you're using $SOFTWARE from c:\Perl64\bin instead of its proper place

On systemd systems you can just either set KEY=VALUE pairs in `/etc/environment` or any file in `/etc/environment.d/` (and technically a few other places [0]). In theory it should be relatively easy to write a GUI for it by manually parsing the files.

The application restarting part can't really be fixed, since environment variables aren't ever injected to a running process and can only be changed by the process itself (terms and conditions may apply) and even changes during runtime could be ignored since the program itself may have cached some already computed value based on the variable.

[0]: https://www.freedesktop.org/software/systemd/man/latest/envi...

https://xkcd.com/927/ - Standards

Situation: There are 14 competing ways to set environment variables on Linux

We should create a universal way that just works and isn't terminal specific to set environment variables!

Situation: There are 15 competing ways to set environment variables on Linux

...you just put them in your shell RC file??

This is much simpler than having to remember where the dang environment variables button is in "advanced system settings" or whatever awful command prompt syntax sets it permanently.

In a shell script, set -u. It’ll terminate if you reference an unset variable.

In other languages, check that the var you pulled in isn’t falsey before proceeding.

You couldn't pay me enough to go back to doing dev work on Windows.

As if Windows isn’t its own legacy mess..

I feel that Windows Registry is similar legacy cruft as environment variables. Worse yet, most software doesn't document which registry keys it's using, so you have to find them on some ancient forum comment or do the detective work by yourself.

It is, there’s just a limit set by the kernel for the number of pages the command line as a whole can occupy or something like that.

The xargs command was designed to address this. From this perspective, it is a kludge.

If you need realtime scheduling pam_env was the only way to do it until rtkit came out (and it still does it better than rtkit does, annoyingly).

Change your browser settings. You can tell the browser what font you prefer to use, and set minimum font sizes. You can also turn off remote fonts, so that pages can only use fonts you already have. Then you can just uninstall any fonts you don’t like or that you cannot read easily.

Huh... Guess it's what you're used to.

First thing that struck me about the site is how beautiful I found it. I even inspected the font: Iosevka Web, apparently.

I'm surprised you say that. Iosevka is quite beloved as a monospace font. I use it for all my terminals, etc.

Command-line arguments aren't passed to subprocesseses, can't be inspected by arbitrary functions in the same process, and don't leak memory if they are changed.

This problem is also removed by just not exporting the variables. Also you can just pass an envp to execvE.

Depending on your system, passing secrets via environment can be more secure than passing secrets via a command line. Command line arguments of all running processes can be visible to other users of the system, environment variables are usually not.

They're the standard for Docker container configuration tho. Otherwise I do agree.

> environment variables are to programs (especially chains of programs, parent processes, sub processes and sub-sub processes, etc.) what parameters are to functions -- and/or what command-line parameters are... they're sort of like global variables that get passed around a lot...

They're not globals, since they're copied into sub-processes; so mutation doesn't propagate upwards.

My own opinion is that environment variables are dynamically scoped keyword arguments http://www.chriswarbo.net/blog/2021-04-08-env_vars.html

The RSS feed has an attribute that suggests Hugo.