On Di, 26.09.23 04:39, chandler (s...@riseup.net) wrote:
> Hi all,
>
> I'm not quite grasping something here... I've just learned about
> `systemd-creds` and now trying to utilize it with a service which
> depends on a secret stored in an environment variable (or passed as a
> CLI option).
>
> Normally I could use a line like:
>
> `Environment=SEC=1234`
>
> Now I've:
>
> 1) Given "1234" to `systemd-ask-password -n | systemd-creds encrypt
> --name=secret --pretty - -`
> 2) Put the resulting `SetCredentialEncrypted=secret: ...` under the
> [Service] section
> 3) Failing with `Environment=SEC=%d/secret`
>
> Now `SEC=/run/credentials/myService.service/secret` but I need the value
> from the file, which I verified with a simple `ExecStart=checkEnv.sh`
> which runs `cat ${SEC}` which prints `1234`.
>
> Also tried putting the secret, e.g. "1234", into a temp file `/tmp/sec`
> and ran:
>
> `systemd-creds encrypt --name=secret --pretty /tmp/sec -`
>
> but the results are the same.
>
> How to get `SEC=1234` basically?
The credentials logic is supposed to be used *in* *place* of
environment variables. Environment variables are an awful way to pass
credentials to services, since their are inherited down the process
tree even across security boundaries by default, and there's zero
access control on them. (and they are not really compatible with
binary data or larger data, and so on)
Hence, what you are looking for is not supported and we won't support
it, because it defeats one main design goal of credentials: to require
access control on access, and not allow "greedy" inheritance down the
process tree.
Sorry if that's disappointing!
If a service insists on reading its credentials from an env var or
cmdline and supports nothing else this is of course disappointing, but
it's simply not compatible with the credentials logic, without manual
glue scripting.
We generally recommend that services support reading the credentials
from files (in which case you can point them to
$CREDENTIALS_DIRECTORY/<cred> to read what they want), or even better:
just natively support credentials by looking at $CREDENTIALS_DIRECTORY
on their own, without being told so.
If you have an app that doesn't allow either, and really and only
wants env vars or cmdline params, then you can script around this,
with a script like this:
```c
#!/bin/bash
read -r MYCRED < "$CREDENTIALS_DIRECTORY"/mycred
export MYCRED
exec mybinary
```
you get the idea.
Lennart
--
Lennart Poettering, Berlin
