Yes, sadly https://12factor.net/ has a lot of currency.
The first time I read that config section I thought 1. it doesn't answer the question; how/where/when do those env vars get defined? 2. it's not secure Matt On Tue, 13 Nov 2018 at 21:20, Tomasz Torcz <[email protected]> wrote: > On Wed, Nov 14, 2018 at 02:17:02AM +0100, Marek Howard wrote: > > Marek Howard píše v St 14. 11. 2018 v 01:35 +0100: > > > Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100: > > > > On Di, 13.11.18 07:49, David Parsley ([email protected]) wrote: > > > > Well, you are of course welcome to ignore whatever I say, but again, > > > > environment blocks are leaky, they propagate down the process tree, > > > > and are *not* generally understood as being secret. > > > > > > It is not *that* common to pass secrets via environment variable but > > > it's nothing unusual, and many programs offer this interface. OpenVPN > > > comes to bind. Where such interface is offered, propagating down the > > > process tree is usually not a concern, because such programs usually > > > don't fork "untrusted" programs. > > > > > > It's quite handy way to pass secrets and as I said above, there's > > > really no risk if it's done in cases where it makes sense. Of course > > > systemd leaking it to everyone makes it not usable with systemd, but > > > that's not really a problem with environment variables. > > > > If you want some examples: > > > > borgbackup - BORG_PASSPHRASE > > restic - RESTIC_PASSWORD > > openssl - env:var > > rsync - RSYNC_PASSWORD > > hub - GITHUB_PASSWORD, GITHUB_TOKEN > > rclone - RCLONE_CONFIG_PASS > > smbclient - PASSWD > > > > Again, it's not so common, but it's not unusual and it's not insecure > > if you know what you're doing (which you usually are when you have > > powers to create system services). > > Generally, storing secret data in environment is common in > web microservices world, popularised by https://12factor.net/config > But those apps are supposed to be run by Kubernetes or other > container runtime - with dedicated clusters, PID namespaces and so on. > Running them as plain unix (systemd) services is the wrong way > to run them ;) > > -- > Tomasz Torcz There exists no separation between gods and men: > xmpp: [email protected] one blends softly casual into the other. > > _______________________________________________ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
