Feature request: Integrate better with Systemd Credentials

s3rj1k

As per https://systemd.io/CREDENTIALS/ the only way of using systemd credentials is via it's built in store, that is essentially a on-demand encrypted folder where each file in it has secret value.

This is unusable is simple way with 1Password Service account as CLI expected that token to be inside environ but Systemd Credentials can only expose that token as content of file.

Would be nice to have additional option to pass Service account token into CLI as value from file content in addition to OP_SERVICE_ACCOUNT_TOKEN environment variable.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser: Not Provided

Eldan

Just wanted to share my approach to using the CLI with a systemd mount unit. It may not be exactly what you want because it creates a credential file on disk for the duration of the mount, but with root ownership and tight permissions I personally think that's an acceptable risk.

Essentially, you encrypt the service account token in systemd and create a systemd service that uses the CLI to create a credentials file for the mount command, then modify the mount unit by adding a requirement for that service.

Steps

Create a temporary text file containing the service account token, encrypt it with systemd to another file, the contents of which you can use in the service unit:

$ sudo systemd-creds encrypt --name=service-account --pretty token.txt out.cred
$ shred -u token.txt

Create a template of the mount credentials file (e.g. /usr/local/etc/myshare-mount-creds-template.txt):

username=op://secrets-vault/myshare-mount-user/username
password=op://secrets-vault/myshare-mount-user/password
domain=op://secrets-vault/myshare-mount-user/domain

Use the contents of out.cred to create a service unit (e.g. mnt-myshare-credentials.service):

[Unit]
Description=Inject myshare mount credentials file

[Service]
Type=oneshot
RemainAfterExit=yes
SetCredentialEncrypted=service-account: \
    nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn \
    ... this is the contents of out.cred ...

ExecStart=/usr/bin/bash -c "mkdir -p /var/run/myshare"
ExecStart=/usr/bin/bash -c "OP_SERVICE_ACCOUNT_TOKEN=$(cat %d/service-account) op inject -i /usr/local/etc/myshare-mount-creds-template.txt -o /var/run/myshare/creds.txt"
ExecStart=/usr/bin/bash -c "chmod 0600 /var/run/myshare/creds.txt"
ExecStop=/usr/bin/bash -c "rm /var/run/myshare/creds.txt"

[Install]
WantedBy=multi-user.target

Add the service requirement and credential file reference to the mount unit:

[Unit]
Description=Mount my SMB share
Requires=mnt-myshare-credentials.service

[Mount]
What=//smb-server/myshare
Where=/mnt/myshare
Type=cifs
Options=rw,credentials=/var/run/myshare/creds.txt,uid=1000

...

The credential file should be removed with a dismount or a reboot.

If anyone has a way to improve on this please comment.

s3rj1k

@Eldan I use similar approach, still don't like it.
Even systemd-creds have issues, decrypted passwords files are accessible from current user.

Not sure even how to solve this one without native TPM decryption support from op

(op + TPM, in this case op could directly use local TPM provider to decrypt passwords from ENV)