does CLI support beta feature Item sharing: send a copy of an item to a team member?

paulpharr

I understand there may be some reluctance to spread support for item sharing too broadly because you may be evolving better ways to handle this problem, but item sharing could be vastly more useful and secure for us if we could invoke it from the CLI so we could build automated processes around it that do not involve human admin staff

I am wondering if the CLI tool currently supports item sharing, and if not, are you willing to add it as beta functionality until there is a better way?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

ag_yaron

Hey @paulpharr ,

Can you please elaborate on how/why/when you'd like to share an item via the CLI? More details here would definitely help understand the use case and if this can/should be implemented :)

ag_yaron

@paulpharr Perhaps you mean the --share-link flag?

For example: op get item [item name/UID] --share-link?

The items link is basically this feature: https://support.1password.com/item-links/
And it is also mentioned in the CLI docs: https://support.1password.com/command-line-reference/#get-item

paulpharr

Hi Ag,

It's not sharing links - it's the send item functionality described here:

https://1password.community/discussion/92722/beta-feature-item-sharing-how-to-send-a-copy-of-an-item-to-a-team-member

We want to be able to create a new secure item or document, then send it to a user using the CLI, then delete it.

An example use case is if, for example, we wanted to automatically generate a VPN certificate during our new employee onboarding process and send it from an administrative 1password account directly into the new employee's 1password vault. We can do this now in the web GUI using your beta feature, but since it needs to be done by a human, the employee needs to trust not only the system, but the human who sent it.

If we could automate the process of creating this certificate, we could send it to the new employee and destroy it, so they are the only one who has it & no other human has ever seen it.

Coincidentally, just a half an hour ago, another of your business users posted this question asking for exactly the same functionality for exactly the same reason: https://1password.community/discussion/116553/is-there-a-write-only-api-we-could-use-to-only-push-secrets-into-our-business-account

We have wanted this for a long time, but have never asked - primarily because it was not so important before COVID WFH. Now all of our new employee onboarding is remote & often new employees never even show up in an office. The ability to privately & securely send things straight to their 1password vault has huge benefits.

Thanks!

Paul

ag_yaron

Thanks for clarifying, Paul.

This feature is not available in the CLI at the moment, but I'll definitely bring it up with the team and see if it can be added as a feature request!

jbrownEP

Any chance of this becoming a feature some time soon? I agree with @paulpharr that it would be incredibly useful for exactly that use case, and it's kind of tedious to have to do it through the GUI en masse.

paulpharr

I have been watching the CLI version recently thinking it's time for an update. I think it's likely that this is not technically difficult to do in a secure way from the CLI and from my POV it has huge value in enabling new 1password use cases in our environment.

For us it could enable some really difficult automated workflows that are manual now because of their security sensitivity.

I will sheepishly admit I have even just hired someone with the expectation they will be able to work on some of these workflows in the next few months.

Fingers crossed!
Paul

ag_yaron

Thanks for checking in on this.
We currently do not have immediate plans or timeline for this specific feature, but I'll let the team know more users are asking for it, which is great! :+1:

ref: dev/b5/op#1116

phatmandrake

Seconded... or third'ed.

ag_ana

:+1: :)

Kennyties

Hey @paulpharr, have you considered automation of a shared vault, adding the new member to that vault, along with HR if need be, adding the password to that vault, then after a set time autodelete?

paulpharr

To be honest, I had not thought of that. I believe I have the impression that vaults are not so lightweight and in the back of my mind I am worried that creating and deleting them potentially by the hundreds over time in our team account would run the risk of having side effects (performance, security, or otherwise).

Nevertheless, thanks for the suggestion! It would accomplish my existing need, and I expect would be manageable in the short term. For that matter, I could create a 'company dropbox' vault for each employee that they were permanently connected with and use it for passing any credentials they needed.

Having all those vaults in the GUI might be a pain for admins though.

I wonder if my speculation on how I might abuse their system is giving the 1Password team indigestion?

ag_yaron

Thanks for the idea @Kennyties.

I think you should give it a try @paulpharr and return with some feedback on it :)

Kennyties

You are very welcome @paulpharr. I can see how creating hundreds would strain the system. You could also look at the Secrets Management module. @ag_yaron no problem!

ag_yaron

:+1:

Kennyties

Hey @ag_yaron I do actually have a follow up question, I am trying to automate 1password but I am not sure how to get around the prompt for password. Is there some instructions on that or should I just send a task to the CLI every 20 minutes or so to keep it open?

ag_yaron

Hey @Kennyties ,

You're not supposed to get around the password prompt :)
You can either keep the session alive by sending a command every 29 minutes or less, or you can include the op signin command in your script with your Master Password, which I wouldn't recommend.

Kennyties

Hey @ag_yaron,

That is a very valid point. I think my best bet is to work a manually login into my daily tasks.

ag_yaron

Sounds like the right way to go :+1:

paulpharr

I have had a chance to explore the proposed method of using a shared vault in order to pass secrets and credentials from our automated systems to individual users with no human intervention. All of the essential pieces are there, but there are a couple of rough edges I'll bring up here to get advice or maybe request adjustments in functionality.

First I will say that from a user workflow point of view, we considered both creating these "handoff vaults" on demand and cleaning them up after the transaction as well as creating them and making them permanent for reuse as necessary. From the user point of view, we think a permanent one is better - making training easier & to avoid surprising the users. Having said that, we can probably make either approach work and most of the rough edges surround how to manage these vaults.

Issue 1:

The first issue, that's really more annoying than it sounds, is that 1pass seems to assign a (randomly chosen?) avatar icon to new vaults created by either the user or CLI. The user can at least adjust it if they notice it, but the CLI can't set it or edit it AFAICT.

It seems from my experience that we are in for confusion if employees get requested credentials delivered into a vault with grandparents or airplanes, or cruise ships, or galaxys on their avatar icon. I would love to have the CLI just use a generic lock icon or allow the avatar to be specified during the OP CLI vault creation process.

Even in the user vault creation GUI, the list of predefined icons for vaults has nothing generic. I'm all for entertaining icons, but I feel like when creating a new vault, there is rarely a good choice in the menu. Can we have just one generic lock? Or a custom option uploaded once & available to all users?

Issue2:

If we create and maintain vaults for all staff, we will have several hundred that will be visible to the account owner (currently myself) and vault admins. We can live with this for now, but would really like to see some kind of mechanism that would allow us to tag these so they are hidden from most vault management contexts without making them inaccessible.

ag_yaron

Hey @paulpharr ,
Thank you kindly for the detailed feedback! I have forwarded it to the dev team.

There are a couple of workarounds to the issues you wrote about straight from the top of my head though:

• While the CLI can't assign vault icons, users (and you) can assign icons from the native desktop Mac app or via our web app. The default icon I use is the vault door icon. You can also upload your own icon if you'd like.

• In the native desktop apps, you can also choose which vaults to show and which ones to hide, to make it easier to manage. Open the desktop app's preferences -> Vaults, and remove the check mark from each vault you don't want to show up in the app. You can do the same in the 1Password browser extension if needed.

I hope you'll find this helpful for now.

paulpharr

Hi @ag_yaron

thanks for your suggestions - I can work with what we've got right now. the biggest annoyance is the random vault icon for seemingly all vaults created by CLI. This is both annoying from an aesthetic POV and random behaviors from security focused software definitely sends the user the wrong message - this is one i'd love to see a resolution for.

As an editorial comment, I will add that I love the focus on consistent brand design & user friendly imagery I see from 1pass. It extends from your public web, to your GUI, to your icons, to your blog - i really think it's great. Having paid you this well deserved complement, I will say that the vault icon you proposed above as a good generic security icon looks more like the wheel on a pirate ship to me than a bank vault - i want an option even more generic and boring for our automated systems to use :-)

paulpharr

We have started using the automated shared vaults process in our new employee onboarding process and it is working great. I see lots of opportunities and few problems other than those that have been discussed

one small problem that feels like a bug, though im not sure:

when we create logins using CLI, the password quality rating displayed by 1pass seems different that when the login is created by hand. The screenshot shows a record created by CLI with a 9 digit random alphanumeric login with upper and lower case. It shows the password quality as 'Terrible'. If I create the same record by hand, the password quality displays as 'Fair'

not a huge deal, but for brand new users who are seeing 1password for the first time, I'd rather not be sending them passwords labeled as 'Terrible' by the system.

In this case, the password is for their new machine login that they need to type by hand, and I really don't want it to be 20 characters long even if it did get around this problem. Is it possible that CLI created logins are always considered 'Terrible' password quality? Can this be improved?

ag_yaron

Hey @paulpharr ,
Thank you kindly for the additional feedback and kind words :)

The issue with the password's strength was already fixed internally and should arrive to you in the next CLI update!

ref: dev/b5/op#1099

paulpharr

I just switched to CLI 1.12.2 and the icon control is perfect - thanks for listening & keep up the good work!

I can tell that 90% of the effort was coming up with all the names:

art-supplies, green-backpack, large-ship, round-door, doughnut - LOL

I see you gave up before four-person-family-with-glasses-and-mustache-and-brown-hair

ag_yaron

We're glad to hear you love the new features :)

And yes, descriptive names are hard :lol:

jscarle

Would have been nicer if they had just left the default icon as the default icon instead of assigning a random icon everytime and make a custom icon an opt-in feature instead of a forced feature. But at least now there's an alternative to programmatically avoid that!

ag_April

Hey @jscarle

Thanks for sharing your thoughts on preferring to have a default icon with custom icons as an opt-in feature. I will be sure to bring it up with the team. It's also good to hear that the ability to control which icon is used via the CLI has been a helpful alternative. :)

mmell

Shared vaults are just a workaround and a messy one in my opinion.

The feature request is As an Administrator, with proper permissions, I should be able to create a record in another user's personal vault. This must me an extremely common use case and perfect for a CLI solution.

The manual process is really cumbersome:

• run our internal automation script to create some login account and, as the op operator, save the credentials to my Personal Vault
• login to the 1Password website
• navigate to my Personal vault
• find the record that I have cleverly named with the receiver's name and account
• click "Send a copy ..."
• search for the user
• select them and send
• click edit on my copy
• click delete
• confirm

Something like a --copy-link seems like an obvious missing feature. Please?

mmell

There's also a slight risk that I make a mistake and send the wrong creds to the wrong person when I'm doing many of these in one sitting.

Justin.Yoon_1P

Hey there @paulpharr , @mmell , @jbrownEP , @phatmandrake ,

We will not be implementing the "send a copy.." beta feature in the CLI, however, we will be supporting the new item sharing feature.

If you have not heard about it, it allows a 1Password item to be securely shared by e-mail or direct link to people who are both within or outside of your 1Password account.

If the item recipient has a 1Password account, they will be able to save a copy of that item in their 1Password account - including their own Private vault.

The command structure is op item share <ITEM> along with some flags to specify which, if any, emails to send the item to, and for how long the shared item is valid for.

This feature is actually already available in the CLI 2 beta. If you are interested in trying it out among many other features like biometric unlock, ssh key fields, and enhanced UX, I encourage you to sign up in the beta thread and our product manager would be happy to have you on board.