It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Forum Discussion
Solved
`op account add` with `Integrate with 1Password CLI`
We have a significant amount of automation around `op`, we use a shared service account (not a service account token, a real 1password account with an email and a secret key) to do perform this automation.
We occasionally need to run this automation from developer machines and recently noticed that some developers had `Integrate with 1Password CLI` enabled.
This had several effects that caused our automation to do the wrong thing.
Our automation starts by doing `op account add --address=… --email=… --secret-key=… --signin --raw` which is expected to print a session token to stdout.
We then pass that session token back to `op` with `--session`.
However when this is run on a machine with `Integrate with 1password CLI` enabled, `op account add` prints the following message to stderr:
1Password CLI is now connected with the 1Password app. Add an account through the 1Password app.
To learn how to add an account to the 1Password app, visit: https://support.1password.com/add-account
And exits with an exit code of `0`.
At this point our automation believes it has a valid session for the account it tried to add and we pass that session w/ `op --session` to all future operations.
However the `--session` argument appears to be completely ignored if the 1password app integration is enabled, so it will actually perform actions using the account from the developer's 1password app.
This causes some operations (such as creating vaults) to succeed but for permissions to access and manage the vault to be incorrect.
There does not appear to be any way for our automation to override or bypass the 1password app integration from the CLI.
Ideally it would be possible for us to force the 1password CLI to not use the app integration in this case, however it'd also be good if `op account add` didn't exit with a code of `0` in this case, since it was not able to add the account.
> There does not appear to be any way for our automation to override or bypass the 1password app integration from the CLI.
I believe you're looking for https://developer.1password.com/docs/cli/app-integration/#optional-set-the-biometric-unlock-environment-variable
You can add this to your script
```
export OP_BIOMETRIC_UNLOCK_ENABLED=false
```that will overwrite the user setting.
5 Replies
Hi 1P_Phil,
We have thousands of vaults managed by this automation.
At the moment it is just the effort of migrating from our service user (which predates service account tokens) to a service account token is too great for too little benefit.
Specifically since we can't give the service account tokens access to vaults after they are created we have a bit of a migration problem, my understanding is that we'll have to stop allowing vaults to be created for a while when we create the service account token giving it access to all existing vaults, and then turn vault creation back on with the new service account token.
We also need to be able to automatically delete these previously created vaults, so we have to maintain the automation that uses the service user to delete the vaults (since it seems like from the docs a service account token can't delete vaults it didn't create).
The carrot for that migration for us is the python SDK (instead of shelling out to `op`) but that doesn't support vault creation yet.
- 1P_Simon
1Password Team
> There does not appear to be any way for our automation to override or bypass the 1password app integration from the CLI.
I believe you're looking for https://developer.1password.com/docs/cli/app-integration/#optional-set-the-biometric-unlock-environment-variable
You can add this to your script
```
export OP_BIOMETRIC_UNLOCK_ENABLED=false
```that will overwrite the user setting.
Gosh, ok thank you.
It makes sense why that disables the 1password integration, but it's also not the kind of name I would have searched for to figure out how to disable the app integration.
- 1P_Simon
Yes fully agreed. The feature has grown far beyond biometrics and the variable name doesn't represent that well anymore. We might rename (and keep an alias of the old name for backwards compatibility). I'll track that internally. Appreciate your feedback! 🙌
- 1P_Phil
Moderator
Hi dreidpilot ,
Thanks for sharing this great write up. I'm sorry you are running into this. I have provided the feedback to the team and we are looking into a workaround. I'm curious - have you considered using Service Account Tokens to create the vaults?
export OP_SERVICE_ACCOUNT_TOKEN=<your-service-account-token>op create vault ...
Thanks,
Phil
