Feature Request: Groups of team members and vault permissions per group

zauerkraut

Hi 1Password team,

We're currently evaluating 1Password as a replacement for LastPass. We're at the scale of 100s of employees with anywhere from 2-15 employees grouped into teams that have various overlapping permissions in LastPass folders. Employees change teams frequently (2-6 months, on average). When an employee changes teams this results in the need to change permissions on on up to ~15 vaults (or LastPass folders) individually, a great inconvenience.

We would like to be able to group employees into smaller teams and set vault permissions on those teams. This way changing the correct vault permissions is as simple as moving the employee from one team to another in 1P, without having to change the permissions on individual vaults.

I understand the language here is a bit confusing due to the overlap of 1P's concept of the "team" and my use of "team" to denote an internal sub-group of employees. Please feel free to clarify as necessary

Best,
Zachary Auerbach

---

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

rickfillion

Hi @zauerkraut,

Your request is crystal clear. For sake of clarity, let's use the term "group" to define a grouping of users whose permissions would be the same for a given vault. Could you do us a favor and include an example vault/group/user structure? This might sound like a silly thing to request but it'd actually go a long way towards helping us define a better solution to this problem. The problem as we see it is that in most cases we've looked at, there ends up being an almost exactly one to one matching between vaults and groups. It's possible that we're just not thinking about the correct scenarios. Would love to hear how you would use this functionality if it was present.

Rick

zauerkraut

Hey @rickfillion,

Here's an example:

My Group, Release Integration, is responsible for a number of AWS environments that contain CI pipelines. We are nominally the owner of these environments, however there are a few groups that need access to the AWS console for debugging purposes. Similarly we are responsible for credentials to our cluster management VM (a service we deploy to each environment, called a Director). Other groups need access to our directors, but not all of them.

The breakdown looks like this
(Creds:Groups)
Alfredo Director: Release Integration, Infrastructure, CAPI
A1 Director: Release Integration, Infrastructure, CAPI
Batman Director: Routing, Infrastructure

In this case Alfredo and A1 would belong in the Release Integration vault, and Batman would belong to the Routing vault.

Furthermore, given the number of vaults that a group might need access to, the ability to set group permissions on vaults means that changing internal teams is a single action for our Admin team in the 1P console, rather than changing permissions for a single user on a large set of vaults. For instance: Release Integration currently has access to 10 folders in LastPass, one of which is technically "owned" by us (I.E. we are responsible for rotating credentials on those accounts in the case of a leak).

Zachary Auerbach
(Edited for clarity)

rickfillion

Thanks for the run-down, @zauerkraut. Much appreciated.

Rick

zauerkraut

To be more specific, @rickfillion, the overlapping vault->group mapping does exist, but this request exists mostly to facilitate our admin team moving members around without having to individually edit a large number of vaults.

bcefalo

+1 on this request

Jacob

Thanks folks. :) :+1:

emilr

+1 on this request

rickfillion

To anyone +1'ing this request, I'd love to hear how you'd use Groups it in a way that doesn't end up with groups being 1 to 1 with vaults. As Zachary pointed out, there's clearly good uses cases. I would just like to hear more of them. The more information we have, the best solution we can come up with.

Cheers

Rick

emilr

In our case we have multiple groups working with different technologies when the projects are in active development. When a project is done the responsibility is transferred to a support team. As long as the project are in active development and the particular group have to share credentials we have a 1 to 1 with vaults. But when the responsibility transfers to the support team, we want both the original group and the support team to have access.

This could be solved with having a "Support team" group that had access to multiple vaults.

To sum it up, we want a class of people to have more access than others, but without having them as admins.

rickfillion

Thanks for the explanation @emilr.

Rick

daveriddler

+1

Jacob

:wink:

random_31731ec7aea

Hey @rickfillion,

I think a simple group & permission pattern would be enough flexibiliety in the beginning.

group to vault = n to n
Including permissions option for groups like for users
user to group = n to n

As a state on a different post, see how boxcryptor.com enabled group support.

Random

rickfillion

@random_31731ec7aea Right. that's definitely how it would work. We're just trying to understand how teams would use this so that we can tailor the UI in such a way that doesn't add too much complexity. :)

Rick

random_31731ec7aea

@rickfillion

But this is exactly what your gui needa to support otherwise it might be easy but it wouldn't allow flexibiliety.

zauerkraut

@rickfillion et al,

I'd also like to point out that a 1 to 1 mapping of groups to vaults is not always redundant. Even in our situation where we have hundreds of users who each need access to sets of vaults and change permissions on vaults as often as once a month this makes sense. It's much easier to change permissions for a user from one group to another rather than from 10 vaults to 10 other vaults once a month for 400 users.

Perhaps an argument can be made that if there is a 1-1 mapping of groups to vaults then there should simply be 1 vault for group. We would like to have multiple vaults for our own organizational sanity, as well as our own attempt to come up with best practices around the storage and organization of credentials. I'd love to discuss this further if you're interested, we're still working on practices around this and would value discussion/input.

rickfillion

Thanks for the feedback @random_31731ec7aea and @zauerkraut. :)

Rick