Signing back into the Community for the first time? You'll need to reset your password to access your account. Find out more.
Forum Discussion
s3rj1k
8 months agoNew Contributor
Feature request: Integrate better with Systemd Credentials
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
- EldanNew Contributor
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:
txt
$ 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
):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
):```txt
[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:
```txt
[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.
- s3rj1kNew Contributor
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 caseop
could directly use local TPM provider to decrypt passwords from ENV)