Retrieve shared item by CLI doesnt seem to work

danpr

The documentation here: https://developer.1password.com/docs/cli/reference/management-commands/item/#item-get suggest one possible way to get an item is by shareLink, which I imagine is the URL that is produced either when sharing an item using either the GUI or the https://developer.1password.com/docs/cli/reference/management-commands/item#item-share CLI command. However whenever I try this the CLI produces the error:

# op item get "<some share link produced by `op item share`>"
[ERROR] 2023/08/02 19:26:54 "<whatever share link I inserted>" isn't an item. Specify the item with its UUID, name, or domain.

It makes no difference whether I put the URL between doublequotes or not.
I am investigating possible ways to do secret management in our infrastructure and considering 1password as an option. One thing we will need in our setup is the ability to pass secrets around using one-time-readable 'tokens'. 1password doesn't seem to have this functionality per se, but creating share links with the '--view-once' flag seems to be a feasible alternative - if they work.

---

1Password Version: CLI 2.19.0
Extension Version: Not Provided
OS Version: Ubuntu 22.04
Browser: n/a

cecaaabdaa

I have the exact same use case and found out the following:

If you use op item get some-example --share-link then the CLI won't return a shared link, but a private link. Private links require the recipient to be authenticated and permitted to read the item whereas shared links include a token.

The wording of the flag --share-link and the placeholder <shareLink> used in the CLI documentation seem to be misleading (or maybe this feature was incorrectly implemented in the CLI because they intended shared links).

Support Documentation

Private Item Link: https://support.1password.com/item-links/

Shared Item Link: https://support.1password.com/share-items/

Private Link

Shared Link

cecaaabdaa

I have the exact same use case and found out the following:

If you use op item get some-example --share-link then the CLI won't return a shared link, but a private link. Private links require the recipient to be authenticated and permitted to read the item whereas shared links include a token.

The wording of the flag --share-link and the placeholder <shareLink> used in the CLI documentation seem to be misleading (or maybe this feature was incorrectly implemented in the CLI because they intended shared links).

Support Documentation

Private Item Link: https://support.1password.com/item-links/

Shared Item Link: https://support.1password.com/share-items/

Private Link

Shared Link

danpr

Aah, at least that makes it clear whats happening. Sadly it seems that these 'private links' are not suitable for my/our use-case, as still needing the client to be authenticated and authorized to view the item would defeat the purpose. Also it seems that for these private link the --view-once option doesn't make sense...

Anyway, did you find a solution?

cecaaabdaa

Unfortunately, I did not find a solution. I am now working with manual workarounds and unfortunately they interrupt the automation.

michael.c_1P

Hi,

Unfortunately, the op item share CLI command is not currently supported with Connect.

You could try using a service account, however the service account must create the vault to have access to the op item share command. You can read more about service accounts here.

We do plan to expand the feature set of service accounts in the near future. Please send me a DM if you'd like to hop on a call to chat more about the feature.

Thanks,
Mike

danpr

Hi @Michael_1P ,

Thanks for clarifying this! I didn't get an alert of your response (it seems that by default no email-notifications are sent for replies to topic created) otherwise I would have jumped on your offer to have a call immediately ;) Right now I have a call scheduled with your colleague Alex tomorrow, I hope we can clear up some things then.

For my use-case it would be fine to use a service account since this is just needed for somewhat infrequent events (spinning up new VMs). In my testing I also worked with a service account. However the issue is still that the CLI doesn't seem to support getting items by share-links, even though the documentation looks like it should.

I'm also fine if we can retrieve the item by share-link using the API directly. I've looked a bit into how the share page works, which just gets the item from your API, however the item details in the response are encoded. Give that the page itself has everything it needs to decode this information I should obviously be able to figure out how to do it given enough time and effort but it would of course be very helpful if I could get some pointers in the right direction for this ;)

Just a bit of background: what this would allow us to do is provision new VMs (or containers or whatever) without needing to store 1password credentials on that VM's filesystem. Current guides seem to rely doing just that but from my perspective that would not be much better than storing the secrets I'm trying to protect themselves on the FS, as those 1password credentials would allow access to those secrets (and possibly more) anyway. So from my perspective that set-up defeats the purpose.
If we could use share links then what we can do is this: When spinning up a new machine (or container or whatever), our provisioning process creates a one-time share link for that machines 1pwd credentials, and write that to the new FS image. Then when the machine spins up some parent/governor process can read the share-link and use it to retrieve the actual credentials, which it will keep in memory for when needed.
Worst thing that could happen in this scenario is that an attacked obtains (and uses) the share-link in the short window of time between creating it and the new machine starting up, which would be a really tricky attack to craft But even if that happens we will notice very quickly by the machine being unable to use the link, in which case we can act accordingly.

Thanks,

Daniel

Michael_1P

That'll be a mention for @michael.c_1P instead ☺️