One of the things I dislike about 1Password’s approach to Password storing and grouping is their monolithic “vault” system. I couldn’t say for sure why they designed it that way (since we’re can’t see their code), but I suspect that either the entire vault is encrypted as a discrete entity, or it’s an intentional simplification designed to avoid the complexities of group permissions. I initially leaned toward the former (since that’s similar to how traditional file-based password safes work), but have started to give more thought to the latter now that I’m running into those complexities myself.
Let’s start by looking at some of the shortcomings of the vault system. One of the first things I did when I set up my vaults was create one to hold credentials that had just been passed over to us by another vendor from whom we were being transferred a new client. We had this great dump of credentials given to us in an excel spreadsheet (I know, right?), so before tossing it into a burning dumpster I created a single new vault for the client and saved them all there. This worked great, until I needed to share some information about a dev environment with one of our programmers.
I couldn’t give them access to the entire vault without giving them production credentials they shouldn’t have, so I had to delete the dev credentials and set up a second vault (so I now have “Client Prod” and “Client Dev”). Later, I needed to share a site login from that dev vault with QA, but they shouldn’t really have server info. Since I didn’t want to add a duplicate of the credentials in the QA vault, I had to choose between giving them the full Dev credential access, or splitting it again into three separate vaults. Of course most of these problems are solvable by setting up everyone with their own accounts, but sometimes that’s either impossible or impractical, and best practices of that sort are a subject for another day, so let’s address the issue at hand.
The approach I’ve been taking so far is to use a grouping system instead of a monolithic vault system. I’d create a Dev group, a QA group, and a Prod group. That allows us to tag a secret as something like “QA, Dev” and it would give access to the appropriate groups. This is a much better system, since I can reuse the same secrets between groups, and assure that any updates made will be reflected and you don’t end up with stale data as a result of duplication. But what about the client? If I create a Client group and add them all to that group, I end up with too much overlap (having a QA person added to that client group will give them access to the Dev and Prod secrets in the Client group as well).
Exclusive grouping solves that problem, by which I mean a user must be a member of every linked group instead of just needing to be in any group. So if a secret is grouped as Client and Prod, someone with Client access but not Prod access won’t see it. This isn’t a great solution either, because it means you need to add everyone to a ton of different groups. Particularly when you add a new group, you have to go back and make sure everyone is included in it.
Of course you could get into hybrid solutions, like groups themselves being flagged as inclusive or exclusive (so adding QA as an inclusive group will add everyone in QA to it, but adding Prod as an exclusive group will lock out anyone who isn’t in Prod), but then you end up with a system far too complex to be useful. You could also have an inclusive master group with exclusive subgroups (so Client might be a master group, giving anyone access, but Prod could be a subgroup added that locks down only certain items), or vise-versa.
All things considered, the best solution for now is the one that gets the job done with the least complexity and the most clarity. Looking over the options, I think inclusive grouping is the way to go, but I understand now why someone might choose the monolithic vault structure for simplicity’s sake.