[13] Can the 1Password CLI replace dotenv (on Raspberry Pi)?

Sounds good!

For my use case it would be great if there was even more granularity; I would like to configure a service account to have access to a single item (username & password).

Most of the services (Node.js scripts) that run on my Raspberry Pi that use "dotenv" contain only the WebDAV credentials (username & password) for a hosting provider that they need to write data to.

(As far as I know that hosting service does not offer tokens for this purpose)

Hi XIII, I'm sorry about the slow reply.

The idea we have for service accounts is that automated use cases such as (web) applications, CI/CD pipelines and other services that run without human intervention would run as themselves - as the service - instead of using a humans account to log in.

Just like human accounts, they'd have a couple things:
- You can grant and revoke the service access to vault(s); So you'd be able to limit access for the service to just the secrets it needs, following the https://blog.1password.com/guiding-principles-how-least-privilege-leads-to-more-security/.
- You can identify the service in https://blog.1password.com/introducing-events-api/, so you'd be able to pin down which service (app, CI pipeline etc.) had that activity.

What would be different is how you authenticate the service. A human logs in to 1Password using their secret key and account password (or with the https://1password.community/discussion/126766/biometric-unlock-is-here) and is prompted for re-authentication after 30 minutes of inactivity or 12 hours in total. A service authenticates using a credential. It's build to run without human intervention and there's no need to re-authenticate. You'd set this credential for example in an environment variable and once that's done, the service will run until you'd revoke it.

That said, I'd love to hear more about your needs and use case and what you'd like this feature to look like. We're here to listen and learn and make sure what we're building achieves your goals.

1P_Simon

I might be wrong here, but ever since you released https://support.1password.com/secrets-automation/ I thought that would be the solution for using 1Password in fully automated scenarios, and that 1Password CLI would always need some interaction from the user.

However, reading this thread (and others) it seems you're working on making it possible, or at least easier, to not have to use Secrets Automation and instead being able to accomplish some kind of automation just with the CLI. Secrets Automation does have a higher learning curve as you need to set up a 1Password Connect server and more, and it does come with a cost once you reach a certain treshold. So I'm all for better options to automate stuff on a smaller scale just using 1Password CLI.

The service accounts you mention, can you go into more detail about them? Would they be another type of account within a 1Password account that you create and manage at https://my.1password.com/ or would they be just some kind of local service accounts managed within 1Password CLI? If they are managed in the web portal, would they come with a cost or be free (up to a certain amount, like guest accounts) and would they be available for all kinds of 1Password accounts (Personal, Families, Teams etc)?

I’m not sure I understand the concept of service accounts, so I can’t answer your question.

Can you please explain a bit more?

Hi XIII,

Yes, the new environment file functionality in the op run command supports the full syntax of dotenv files. On top of that, you can replace plaintext values with https://developer.1password.com/docs/cli/secrets-reference-syntax, exactly for the reason you describe, to avoid storing credentials in plain text. Instead you'll use https://developer.1password.com/docs/cli/secrets-environment-variables to pass these secrets directly to the runtime of your scripts.

To authenticate, you currently indeed have to https://developer.1password.com/docs/cli/sign-in. This currently works the same as it did in version 1 of the CLI. We're working on making this easier for you on your own device by making it possible to log in using your fingerprint.

For automated use cases like the one you have, we're considering to add service accounts. Service accounts would represent a service and authenticate as that service using a credential. Would this be useful for you?