Retrieve shared item by CLI doesnt seem to work
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
Comments
-
I have the exact same use case and found out the following:
If you use
op item get some-example --share-linkthen 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-linkand 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
0 -
I have the exact same use case and found out the following:
If you use
op item get some-example --share-linkthen 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-linkand 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
0 -
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-onceoption doesn't make sense...Anyway, did you find a solution?
0 -
Unfortunately, I did not find a solution. I am now working with manual workarounds and unfortunately they interrupt the automation.
0 -
Hi,
Unfortunately, the
op item shareCLI 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 sharecommand. 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,
Mike0 -
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
1 -
That'll be a mention for @michael.c_1P instead ☺️
1
