OnePassword CLI over Connect

sshipway

Using onepassword-cli 2.6.0

In order to use 1Password from AZDO pipelines, we've added the onepassword-cli package to our worker nodes. However it seems very limited in what it can do.

I'm setting the OP_CONNECT_HOST and OP_CONNECT_TOKEN environment variables for authentication to the onepassword-connect service, and then calling 'op read' from the build pipeline Bash task.

The problems I have are

• It seems to be read-only - no way to save a secret from the commandline?
• No way to extract file attachments from secrets
• No way to search for secrets
• It seems to be unable to retrieve secrets with ':' or '@' in their name, even if these are URL-encoded?

The last one in particular is a big issue as our naming standard requires these and we have hundreds of secrets containing these characters. I can't use the secret internal ID instead of the name, because I don't know what they are and it would be very problematic to have to work it out for every secret.

The API, though, seems to quite happily support all of these (well, no way to write file attachements, but thats a lot closer)

I don't want to have to write my own tool to call the API when the onepassword-cli is supposed to do the job. Is there a way to achieve this? Otherwise the CLI tool seems hopelessly limited and underdeveloped.

---

1Password Version: onepassword-cli 2.6.0
Extension Version: n/a
OS Version: Linux
Browser:_ n/a

Justin.Yoon_1P

Hey there @sshipway - I think I can help with some of your questions!

It seems to be read-only - no way to save a secret from the commandline?

Yes - Connect only exposes read operations to access secrets. If would like to perform write operations in CICD environments, we do have a service account feature coming. The feature will allow provisioning of service account tokens that can be set to perform most CLI commands, including creating and editing items. Stay tuned!

No way to extract file attachments from secrets

The most recent versions of the CLI and Connect server allow fetching file attachments from items, whether they are Document items or file fields.

The syntax to reference a Document or file field would be: op://<vault>/<item>/[<section>/]<fileName>

If such syntax does not work, please let us know and we can begin a bug investigation on our end.

No way to search for secrets

No, unfortunately even naive commands like op item list seem to be blocked in Connect - I am interested in your use case for searching items in automated environments to get a better idea for any improvements we can make.

It seems to be unable to retrieve secrets with ':' or '@' in their name, even if these are URL-encoded?

Are you using op read with a secret reference? This is a validation in the secrets reference syntax. Using URL encoding on such chars, or allowing to escape them by preceding such chars with a backslash may be a good way to address items containing those chars in their names, and we will look into it.

For now, you can use the op item get command instead, eg. op item get "my:item @ AZDO" --fields="mySection.myField" --format=json --vault="My Vault".
The command will return a JSON object of the field, and the value key must be extracted with a tool such as jq. It is a bit of a roundabout way to get a field’s value - but hopefully it suits your use case for now.

sshipway

Thanks for the information. I had thought that "service accounts" were just another name for the automation tokens so I'll wait to see what new comes along.
I've noticed our Connect server API does allow downloading file attachments (though not uploading), but the CLI did not previously. I've obtained the latest version and can now successfully download attachments with op read, though of course I'm still limited by being unable to use nonalphanumerics in the secret url and the filename has to match exactly.
In our pipelines, we're trying to read secrets by their name, which for us has a standard form of [app:][user@]hostname[/version]. So searching by the reference is out as this would be problematic to identify in every case. Being able to search would allow us to identify by partial name matches (such as where people created a secret with a nonstandard name format) and give a more helpful error message.
I've tried using escapes and URL encoding on the secret names with op read but this does not appear to be supported. The op item get works as well as op read apart from file attachments, and a JSON output is more flexible anyway. The inefficiency of it doing a local sort may be an issue for any rate limiting though, hopefully the OP_CACHE=true will help with that.
Steve