Feedback on 3.5.2 to 4.0.4 upgrade; security access issues

[luther_miller]

Just upgraded our vault server from 3.5.2 to 4.0.4. The upgrade itself went quickly and smoothly.

We have a 6 GB database with about 40 users (27 active) and about 75 repositories. Access rights are VERY important to us. We work with many different clients and have full-time staff as well as contractors. One of our reasons for upgrading was that 3.5 and previous versions would default to grant access to a new user to all repositories and to a new respository to all users...

I haven't done too much with 4.0.4 yet, but I did notice that the security model has changed.

1. Even though several of us are Vault Admins, we kept the number of repositories we "see" down by not granting access to ourselves to all of them -- only the ones that we are currently working with. With the new Vault, I have all 75 repositories in my personal list now. How should we address this?

2. After upgrading, I checked security on several repositories and noticed that users that did not and should not have access now had access. So the upgrade actually granted access to people. I did not expect this. So I changed the "Default" repository settings to deny access and then applied that to all repositories. Now I am pretty sure that some users that had access before no longer do (but I'd rather err on that side). I do not want to go an fix 75 repositories x 30ish users ... it would have been nice if the existing permissions had been preserved.

3. The new UI for security is clunky. Not that the old UI was great (seeing only three users or repositories at a time, for example, in the checked list box). But when I choose a particular repository and view the access, the list of users starts about half way down the screen and scrolls way off -- and then instead of checking users on and off quickly with the keyboard, I have to click the edit button, then choose a drop down selection, and save... doing this for 30-40 users is a real pain.

Anyway, maybe this will be less of an issue now that we can default everyone to no access for new repositories / new users... but I just can't help but have the feeling that the UI wasn't designed for firms using so many repositories and users (and having to actually adminster them).

Hopefully things with 4.0.4 will be very smooth going forward, but I wanted to share my initial feedback while it was fresh.

Thanks
-Luther

[jeremy_sg]

Luther,

We've yet to reproduce any security upgrade problems in house, so I would definitely like to know more about what your situation was like before the upgrade.

The major change that you're seeing is that all global admins can see and administer all repositories. One change that we made in Vault 4.0 is the ability to give a user or group admin access to just one repository. Perhaps this might serve you better than your old way of working. A repository-only admin will be able to change settings on that repository, but not on any others. In fact, if they are denied access to another repository, they should never see it.

I agree that if you have a lot of users, clicking each one is a pain. That's why we added the ability to set repository access by group, as well as the ability to set default access to a repository. We did the UI this way, because it was very important to be able to show, for each user, exactly what the current rights are (which can no longer just be conveyed with a check box).

Thanks for the feedback, and I hope that as you get in to the new 4.0 features, our new features can make your life easier than it was before, not just different.

[luther_miller]

1. What else would you like to know about the security? After the upgrade, some users who did not have access to certain repositories did after the upgrade. Then we made the default to be no access, applied that, then it went in the other direction --- fewer users had access than before.

2. We have several folks in the organization that are allowed to add/remove users from any repository as well as create new repositories. Those folks on a daily basis however only work with a few repositories. We don't want to give them the admin account password... so the old model seemed to work well in this situation.

3. New feedback: I wanted to activate a couple inactive users and had to scroll down, click the user, change the setting, then it goes back to the list of users again. It doesn't remember the scroll position, so you have scroll down and do it all again... this is not too bad because this is not a common use case.

4. What a more common use case is is working with a repository, but every action reset the scroll position of the list of repositories on the left, so you have to scroll all the way back down to it again...

There are some pros with the new admin interface -- e.g., access from anywhere without the UI Admin tool installed, but performance and things like losing the scroll position are downsides over the GUI tool.

[luther_miller]

I have an existing user that was inactive (in this an ex employee coming back as a contractor) and I need to go through and remove access for that user from most repositories and add access to one new one.

The Overview shows me which repositories the user has access to, but how should I go about removing access from each one? Do I need to go into each repository and do it there? That will take forever. Am I missing a simple screen for doing this?

Thanks

[jeremy_sg]

You're right, there's no easy way to edit the user across multiple repositories.

Just to be sure, would making the Overview page editable do most of what you want?

In response to 2 above, if the users could log in to the admin tool, then they were global admins and could do everything that the "admin" user can do.

I can definitely understand your complaint about the scroll position being lost. We'll make sure to address that soon.

[luther_miller]

Yes, making the overview editable would be helpful. Also, a "remove all access" would be cool, too, for those of us that are paranoid about the Active flag not being set properly, or for bringing back an old contractor for new work, etc.

For the adming thing -- yes, we are cool that several people are global admins and can access the adming page using their own user ID and password, its just that those folks now are burdened with 75 repositories (and growing) whenever they log into the client to do work now. Is there way to keep the users as global admins without them seeing every repository when they use the vault client?

Thanks!
-Luther