Help talk:Toolforge/Envvars

Needs security discussion

@David Caro, @Majavah, @Triciaburmeister: This page desperately needs a section discussing security, since e.g. Help:Toolforge/Build Service#Example: OAuth with Python + Django suggests putting secrets into Envvars Service-managed env vars.

PS. My first thought after skimming this docs page is that the approach has been a little too literally "make env vars available", including having the conceptual model be "set var = value" in an interactive shell with a somewhat hacky shell-syntax way to pull it from a file. I think it would be better to conceptually think of it as a "Runtime Environment Service" that happens to currently expose itself as environment variables on the receiving end—but could in principle also show up in sysfs/procfs or d-bus or ...—and, crucially, which is configured by a configuration file or something other more persistent (a companion to the Procfile maybe). Slightly more abstracted (and therefore more flexible and adaptable) and with a slightly more intuitive / manageable interaction model.

Or, hey, I'm just an idiot and you should ignore me. That's always a likely option. :) Xover (talk) 06:57, 2 November 2023 (UTC)

Hi Xover, thanks for your input, really appreciate it :), we might want to clarify some of those points a bit more in the docs yes, but until then, here's some clarification.

The envvars service is suitable for secrets too, there was an initial discussion of naming the service `secrets` only, though we chose to go with something broader following other existing platforms (ex. heroku, naming is hard xd).

So yes, it is a "Runtime Environment Service" but also a "Secret Environment Service".

The capability to load it from a file was something that we considered too, though we decided to follow the 12 factor app model in this case (https://12factor.net/config), and avoid things like mistakenly committing that 'secret' file to git.

So we want to encourage moving off from storing secrets in files and storing them in a secret service (with the weird name envvar service).

In that case having a way to migrate, even if it looks hackish, from a file to the envvars service is probably good enough, as it's a one-off.

About persistence, considering that the secrets are stored in etcd in k8s (as k8s secrets), their persistence is comparable or greater than files in the filesystem (that would be NFS currently, as you don't want to put them in git). It is true that backup-wise we still have to improve, and that is already in the roadmap (everything can be improved). David Caro (talk) 10:09, 6 December 2023 (UTC)

@David Caro: I wonder if it would be worthwhile to request the security team review the design, and help create a "Security considerations" section of the documentation. For example, *nix command lines are usually visible in ps output and various places in /proc and /dev/pts* so on a shared environment like the Toolforge bastions, tools.wm-lol@tools-sgebastion-10:~$ toolforge envvars create MY_CERT_KEY -- "$(cat secret.key)" looks kinda scary. With this interface you'll also get a lot of tools.wm-lol@tools-sgebastion-10:~$ toolforge envvars create PASSWORD "l1teral-p@ssword-string123" that will get saved to .history files, potentially to /var/log somewhere, etc. While having secrets files get checked into git is a real concern, so is leaking this stuff via the environment. There's a reason /sbin/passwd and friends prompt for the password rather than reading it off the command line, and don't echo the input to the terminal device. But some do sometimes support reading it from stdin so you can pipe a file to it rather than putting its contents in the command line itself, so maybe that'd be an option here too. Xover (talk) 08:57, 28 December 2023 (UTC)

The files in the filesystem issue was (and still is) an issue with the current toolforge, and as there's no prevention of you doing "echo 'mypass' > mypass.txt", so it's not a new issue.

But we can do better, and this forces you to pass the password through the cli arguments, so I created T354196 to address that, will get that sorted out soon :) David Caro (talk) 15:56, 2 January 2024 (UTC)

@Xover I have released a new version that allows you to not pass the secret as an argument (and also allows using stdin/pipes), can you try it and see if that works better for you? David Caro (talk) 11:13, 4 January 2024 (UTC)

Add read example?

This tutorial has good examples of how to create an envvar, but I missed the part about how to read an envvar. If a section about reading were to be added, it would also answer some of my other questions, such as whether envvars are best read from the command line and inserted into bash scripts, or best read from the program code itself (for example, a python file). I'd like to get an idea of the best practices. Novem Linguae (talk) 21:24, 1 April 2024 (UTC)

All of the envvar values set via toolforge envvars create ... and listed via toolforge envvars list are injected into the runtime environment of both webservice and toolforge jobs managed Pods on the Toolforge Kubernetes cluster. There is no special magic needed to read them other than whatever environment inspection mechanism is available in your implementation language.

In Python projects I am personally a fan of using the (poorly named) django-environ package to map envvars to types and supply defaults where appropriate. You can see a working example in wikibugs2's settings.py configuration. I'm not sure that documenting such personal preferences in the main help documentation will actually help many folks, but maybe I am missing your point? -- BryanDavis (talk) 23:09, 1 April 2024 (UTC)