конфигурация среды выполнения (Execution environment configuration)
Учетные данные (Credentials)
LoadCredential=ID[:PATH], LoadCredentialEncrypted=ID[:PATH]
Pass a credential to the unit. Credentials are limited-size
binary or textual objects that may be passed to unit
processes. They are primarily used for passing cryptographic
keys (both public and private) or certificates, user account
information or identity information from host to services.
The data is accessible from the unit's processes via the file
system, at a read-only location that (if possible and
permitted) is backed by non-swappable memory. The data is
only accessible to the user associated with the unit, via the
User=/DynamicUser= settings (as well as the superuser). When
available, the location of credentials is exported as the
$CREDENTIALS_DIRECTORY environment variable to the unit's
processes.
The LoadCredential= setting takes a textual ID to use as name
for a credential plus a file system path, separated by a
colon. The ID must be a short ASCII string suitable as
filename in the filesystem, and may be chosen freely by the
user. If the specified path is absolute it is opened as
regular file and the credential data is read from it. If the
absolute path refers to an AF_UNIX stream socket in the file
system a connection is made to it (only once at unit
start-up) and the credential data read from the connection,
providing an easy IPC integration point for dynamically
providing credentials from other services. If the specified
path is not absolute and itself qualifies as valid credential
identifier it is understood to refer to a credential that the
service manager itself received via the
$CREDENTIALS_DIRECTORY environment variable, which may be
used to propagate credentials from an invoking environment
(e.g. a container manager that invoked the service manager)
into a service. The contents of the file/socket may be
arbitrary binary or textual data, including newline
characters and NUL bytes. If the file system path is omitted
it is chosen identical to the credential name, i.e. this is a
terse way do declare credentials to inherit from the service
manager into a service. This option may be used multiple
times, each time defining an additional credential to pass to
the unit.
The LoadCredentialEncrypted= setting is identical to
LoadCredential=, except that the credential data is decrypted
before being passed on to the executed processes.
Specifically, the referenced path should refer to a file or
socket with an encrypted credential, as implemented by
systemd-creds(1). This credential is loaded, decrypted and
then passed to the application in decrypted plaintext form,
in the same way a regular credential specified via
LoadCredential= would be. A credential configured this way
may encrypted with a secret key derived from the system's
TPM2 security chip, or with a secret key stored in
/var/lib/systemd/credentials.secret, or with both. Using
encrypted credentials improves security as credentials are
not stored in plaintext and only decrypted into plaintext the
moment a service requiring them is started. Moreover,
credentials may be bound to the local hardware and
installations, so that they cannot easily be analyzed
offline.
The credential files/IPC sockets must be accessible to the
service manager, but don't have to be directly accessible to
the unit's processes: the credential data is read and copied
into separate, read-only copies for the unit that are
accessible to appropriately privileged processes. This is
particularly useful in combination with DynamicUser= as this
way privileged data can be made available to processes
running under a dynamic UID (i.e. not a previously known one)
without having to open up access to all users.
In order to reference the path a credential may be read from
within a ExecStart= command line use
"${CREDENTIALS_DIRECTORY}/mycred", e.g. "ExecStart=cat
${CREDENTIALS_DIRECTORY}/mycred".
Currently, an accumulated credential size limit of 1 MB per
unit is enforced.
If referencing an AF_UNIX stream socket to connect to, the
connection will originate from an abstract namespace socket,
that includes information about the unit and the credential
ID in its socket name. Use getpeername(2) to query this
information. The returned socket name is formatted as NUL
RANDOM "/unit/" UNIT "/" ID, i.e. a NUL byte (as required for
abstract namespace socket names), followed by a random string
(consisting of alphadecimal characters), followed by the
literal string "/unit/", followed by the requesting unit
name, followed by the literal character "/", followed by the
textual credential ID requested. Example:
"\0adf9d86b6eda275e/unit/foobar.service/credx" in case the
credential "credx" is requested for a unit "foobar.service".
This functionality is useful for using a single listening
socket to serve credentials to multiple consumers.
SetCredential=ID:VALUE, SetCredentialEncrypted=ID:VALUE
The SetCredential= setting is similar to LoadCredential= but
accepts a literal value to use as data for the credential,
instead of a file system path to read the data from. Do not
use this option for data that is supposed to be secret, as it
is accessible to unprivileged processes via IPC. It's only
safe to use this for user IDs, public key material and
similar non-sensitive data. For everything else use
LoadCredential=. In order to embed binary data into the
credential data use C-style escaping (i.e. "\n" to embed a
newline, or "\x00" to embed a NUL byte).
The SetCredentialEncrypted= setting is identical to
SetCredential= but expects an encrypted credential in literal
form as value. This allows embedding confidential credentials
securely directly in unit files. Use systemd-creds(1)' -p
switch to generate suitable SetCredentialEncrypted= lines
directly from plaintext credentials. For further details see
LoadCredentialEncrypted= above.
If a credential of the same ID is listed in both
LoadCredential= and SetCredential=, the latter will act as
default if the former cannot be retrieved. In this case not
being able to retrieve the credential from the path specified
in LoadCredential= is not considered fatal.
