Re: Environment-variable security?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <tomek@xxxxxxxxxxxxxx> 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 (parsley@xxxxxxxxxxxxx) 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: zdzichubg@xxxxxxxxx   one blends softly casual into the other.

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux