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

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

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?

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

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

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

That'll be a mention for @michael_c_1P instead ☺️