[troad]

I really wish I could restrict CLI access to 1Password per vault (or even per item).

When I briefly tried Kamal, it made me very uncomfortable for a script to ask for access to my entire 1Password - every login, credit card, etc. While I do not think Kamal is malicious, in the context of all the constant supply chain attacks, saying yes to anything like that seems extremely irresponsible.

This seems like an area where there'd be obvious value in applying the principle of least privilege, so I was surprised when I couldn't find any granularity to the CLI permissions in 1Password.

[e40]

This is the takeaway from this disclosure. Everyone using op should create a service account and expose only the secrets that need access via the CLI. That greatly decreases the attack surface.

[halfcat]

And makes it invisible if you’re compromised in a supply chain attack.

The flip side would be, you install your dependencies, and one tries to run `op …` and you get a 1Password popup on your screen, which should surprise you because you didn’t run `op` yet. Supply chain attack mitigated (maybe).

With a service account there is no prompt and your secrets, though now more limited in scope, and exfiltrated successfully and silently.

Service accounts are definitely not the silver bullet. 1Password should just add more fine-grained permissions and prompting options to get closer to an ideal solution.

[e40]

I agree with this. It would be nice if there was an option, per item in 1PW, that allowed a popup for access via the service account.

[selinkocalar]

CLI tools have weaker security models than their GUI counterparts bc the assumption is usually that if you have terminal access, you already have elevated privileges.

But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.

[conception]

Use a service account via cli?

[halfcat]

A service account sounds like one step forward, two steps back.

It can limit the scope of accessible vaults, which can help but only if you do the legwork of keeping multiple copies of secrets in separate vaults and managing service account tokens.

But the token is just in an environment variable, which if we’re worried about this supply chain malicious library scenario, is no different than keeping your secrets in a plain text .env file.

And worse, a service account doesn’t prompt the user.

The functionality of `op run —env-file .env — some_app` which then prompts the developer is what we’d want in a dev environment, just with finer grained permissions and options to prompt every time.

But realistically, if someone can execute code on your computer, they can get to your entire 1Password account through scraping the app, key logging, sending keystrokes and screenshotting, etc.

[troad]

Oh neat, I didn't realise that was an option for personal accounts, I had incorrectly assumed they required a business sub. Thank you for the tip!

[jdpage]

One thing that's very cool about 1Password is that they expose a lot of their more enterprisey features even on regular subs. I'm able to use 1Password for secret storage on my at-home k8s cluster without any kind of special business account.