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

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?

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?

@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)?

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.

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)

@Backspaze

That's right. With service accounts, we're aiming to make the benefits of Secrets Automation available without needing to host a Connect server. As you said, there's a learning curve and setup cost to using Connect and we want to make it as easy as possible for you to get started with securing your automated processes.

What we currently have in mind would be that human accounts, service accounts and Connect servers are interchangeable.
When you use op run, op inject, op read and op item get in the beta you're currently testing, you'll already be able to use either your personal account or a Connect server (configured through OP_CONNECT_HOST and OP_CONNECT_TOKEN environment variables). With the addition of service accounts, you'd be able to those at least for the same commands, for example by configuring OP_CREDENTIAL environment variable.

This interchangeability allows for a couple things:
- You can use a different authentication method depending on where your service is running. For example, you can run your application locally using op run with your personal account and on a webserver in production using a Connect server with op run. You could run your end-to-end tests (that require API keys to authenticate to third-party services) locally using op run with your personal account and in a CI/CD pipeline using op run with a service account credential. This allows you to re-use the script/Docker container/environment file (with https://developer.1password.com/docs/cli/secrets-environment-variables#step-3-differentiate-between-environments) achieving https://12factor.net/dev-prod-parity.
- You can get started locally using your personal account, publish to production using a service account and upgrade to a Connect server when you have the need for lower latency and/or more control.

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?

In our current idea, you would be able to manage service accounts using https://my.1password.com. Is this important to you? What would you like to be able to configure and manage?

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 have no information to share about that yet. As a developer, I'm focused on achieving your goals and adding value for you. If there's any way in which we can add more value for you, please let me know!

Maybe @ag_tyler has an update about pricing, but I believe this hasn't been evaluated yet. The project is still early stage.

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).

Thank you! I'll let the team working on this project know about your use case. Thanks for letting us know! ❤️

@1P_Simon Managing the service accounts using https://my.1password.com sounds great and I'd like as much granularity as possible, just as @XIII mentioned.

As far as I know there's a cap at five or 20 guest accounts depending on what plan you're on, and that's a hard cap so it can't be expanded. You can however, even on the Family plan, invite more than five regular members at a cost. I'm just guessing that you'll also set some kind of limit for service accounts, if so, I'd like to see similar limits but no hard cap, so you can create as many as you need with a cost for more than five accounts or something. The reason for not setting a hard cap is for us to be able to adhere to the principle of least privilege.

There are also quite a few differences in the amount of settings available for Family plans vs Teams/Business plans so I'm guessing there will be similar limitations for configuring the service accounts on a Family plan vs a Teams/Business plan? Hopefully you can provide a decent amount of configuration options on the Family plan as well, but I know it's also a balancing act as to not overwhelm those who have no interest in these features. If it were up to me we'd be on a Teams or Business plan as I'd like to have some of the features available there but it would be next to impossible to persuade the other family members to sign up for that.

I understand that it's probably too early to be talking pricing, but I appreciate all the information you are able to provide, so we'll see if @ag_tyler has anything more to add at the moment. It all sounds very promising though and I've been planning for a while to take Secrets Automation for spin but haven't got around to it yet, so maybe I'll hold off on that and see what becomes of the service accounts.

Appreciate it @Backspaze!

I agree that you should be able to create as many service accounts as needed (whether that's at cost or not) as you should be able to adhere to the principle of least privilege.

I'd love to understand a bit better how you'd be using the service account feature in your Family account. Is this for a side-project? Are you running scripts or a server or something else? Is it just you who would be working on these automations or would other family members manage the service accounts as well?

As you said, the feature may not be relevant to all users, so I'm hoping this background from you and other users will give us insight in how and where we should deliver the functionality.

Thanks again for taking part in this Early Access round and providing us your feedback! It's tremendously valuable to us.

I'm running all kinds of services, scripts and other automations on my desktop and my NAS. All of those would benefit from integrating with 1Password, instead of having credentials to email accounts (and other accounts) in plain text or encrypted using a convoluted process which requires some work if I were to change a password somewhere. If I could use 1Password for this I'd only need to update the password(s) in 1Password and the scripts would just keep on running without issues.

At the moment it's just me in my family who would be using this, partly because I've not been able to get more people on board the password manager train (something I think many here can relate to) and the pandemic didn't make it any easier. But with time I expect there to be more who'll join our family account who'd want (or need) to use these kind of features. I could help them automate some thing(s) at their place and teach them how to troubleshoot when something goes wrong and put the documentation in 1Password. Then they'd have their own service account(s) to manage and could contact me if there's an issue they couldn't resolve by themselves.

My closest family are spread out in different cities and if I manage to reach my goal of getting everyone on board 1Password, then we'd be a bunch of Family Organizers, of which a smaller group work in IT in some capacity and who would benefit from being able to use 1Password for more than just storing credentials. Let's say we have some automation that requires a script to be run locally at each person's home but the script should leverage the same credentials. If the script references credentials in 1Password, then we can store those in a shared vault and edit those whenever needed without needing to update the script.

In 1Password Families you're either a member or a organizer, so either a regular user or a global admin. There's no granularity there (I wish there was), so I'm guessing creating and managing service accounts will only be possible for Family Organizers, just like for the other account types? In any case, it would be nice to automate the storing of the credentials for the service accounts somehow. Like if you create a service account, a login item gets created with it and it would either be stored in the creator's private vault by default, or there could be a modal with a question of where to store it. You could then move the login item around between vaults as you please, but, if possible, there could be a permanent link between the service account and the login item, so if you change the password for the account, the password stored in the login item gets updated automatically. Or perhaps creating a service account should work like many services handle API keys; you only get to see the credential(key) when the account is created and it's up to you if you want to store it and where, and if you need to replace it, you either generate a new credential or create a new service account and remove the old one.