Closed Bug 1502186 Opened 6 years ago Closed 6 years ago

Change scopes to use non-VPN groups

Categories

(Taskcluster :: Operations and Service Requests, task)

Product:
Taskcluster
Component:
Operations and Service Requests
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jabba, Assigned: dustin)

References

Details

Attachments

(1 file)

Bug 1502186 - replace some groups vpn_foo with foo in grants r=tomprince
47 bytes, text/x-phabricator-request
Details | Review
In https://bugzilla.mozilla.org/show_bug.cgi?id=1501762 it became evident that taskcluster should probably not use vpn_* groups for authentication scopes (at least maybe in some cases), since, in that instance, we found a group that had no IP ACLs and assumed it wasn't being used for anything, so removed it. We've restored it for now, but going forward, it probably makes sense to leave vpn_* groups solely to the VPN and create separate groups for other things. In the case of vpn_treestatus, I'd be fine with creating just a "treestatus" group, or even a "tc_treestatus" or similar, if it's to be used just by taskcluster. There are likely other groups like this that I'm not aware of, vpn_treestatus is just an example that came up.
See Also: → 1498408
I'm happy to make whatever changes you'd like. What groups will be getting new names?
Component: Authentication → Service Request
QA Contact: dustin
Can you list out the scopes you currently use in Taskcluster, and then I can go check each of those for whether they are valid VPN groups, and then I'll go ahead and make clones of them with different names and let you know what they are?
If you search for mozilla-group:vpn_ in https://tools.taskcluster.net/auth/roles you'll see the full set.

Jabba, do you want to carry on with this? Or, we can close up..

Flags: needinfo?(jdow)

:gcox - I think we still want this?

Looking through the link in comment 3, it looks like:

vpn_releasemgt
vpn_sheriff
vpn_tooltooleditor
vpn_treeherder
vpn_treestatus

which we'd want to clone into:

tc_releasemgt
tc_sheriff
tc_tooltooleditor
tc_treeherder
tc_treestatus

Does that sound right? Then the vpn_* groups will be solely for VPN access rules alone and we could remove the ones that have no actual IP rules in them.

Flags: needinfo?(jdow)

If the idea is that e.g., a new sheriff would need to be added to dozens of groups, one for each RP (tc_sheriff, treeherder_sheriff, vpn_sheriff, activedata_sheriff, etc.), then the tc_ prefix makes sense -- but then why have multiple groups? Why not just a single sheriff group that each of those RPs consults?

IMO, yes, I still want these - anywhere you're using a vpn_blah group and it's not using the VPN, I'd rather see a new group.

From comment 5:
vpn_releasemgt - refers to a datacenter VM, ok as is.
vpn_sheriff - Just a list of people, replace.
vpn_tooltooleditor - Just a list of people, replace.
vpn_treeherder - Does not exist in LDAP, remove from the TC side.
vpn_treestatus - Just a list of people, replace.

So, clone those 3 groups, sheriff/tooltooleditor/treestatus?

Component: Service Request → Operations and Service Requests

I've cloned vpn_sheriff -> sheriff, vpn_tooltooleditor -> tooltooleditor and vpn_treestatus -> treestatus.

The downside here is that people in these groups probably won't reflect the new group name in their profile until their Auth0 session has fully expired and they do a complete re-login flow (like when they actually have to enter their password into Auth0, rather than just refreshing an existing session), and this could take as long as 30 days.

So, to actually complete this, we know that :dustin will need to reconfigure TC to look for these new names, before I can remove the old groups, and if done right away, all the users would need to force a logout at sso.mozilla.com and log back in, which might be an unneeded inconvenience, if instead you'd like to just wait about 30 days from now before making the change, then all of the users should show up in both old and new groups and there shouldn't be any problems in the user experience.

Either way, I'll wait until after you confirm that TC has been reconfigured before I'll remove the old groups.

Group membership should be reflected as soon as the People API sync process puts that information into Auth0. TC credentials based on login are only good for 15 minutes at a time and auto-renew based on the Auth0 profile. That would get updated pretty quickly, right?

That said, I don't see "tooltooleditor" in https://tools.taskcluster.net/credentials, where I do see vpn_tooltooleditor, so apparently this hasn't synced enough yet :)

Yeah, I think that currently the people API sync process just handles mozillians.org groups. I think the LDAP groups for now are still only synced to Auth0 during a login involving a user typing in their password, at least that has been my experience so far, although I believe it is on the roadmap for "very soon" to happen on a timed interval, but it's waiting for some CIS profile v2 stuff to hit production.

Ah, OK. That kind of stinks! But for this non-urgent bug, I guess we can just wait the 30 days?

Yeah, I think waiting the 30 days is the least invasive. The only alternative I can come up with is to announce to all users that they need to log out of Auth0 and back in in order to retain their permissions, but since it's not urgent, I don't think we need to do that.

Jabba, should we get back on this?

Flags: needinfo?(jdow)

yeah, I think it'd be safe to proceed with the config change on your end, since everyone will have had to re-auth at least once by now so all the groups should be mirrored in Auth0.

Flags: needinfo?(jdow)
Assignee: nobody → dustin

vpn_releasemgt - refers to a datacenter VM, ok as is.

no change (note that we do use this group as well)

vpn_sheriff - Just a list of people, replace.

replaced with https://tools.taskcluster.net/auth/roles/mozilla-group%3Asheriff

edited to include both ci-group sheriff and vpn_sheriff, pending ci-configuration change landing

vpn_tooltooleditor - Just a list of people, replace.

added https://tools.taskcluster.net/auth/roles/mozilla-group%3Atooltooleditor

edited to include both ci-group tooltooleditor and vpn_tooltooleditor, pending ci-configuration change landing

vpn_treeherder - Does not exist in LDAP, remove from the TC side.

https://tools.taskcluster.net/auth/roles/mozilla-group%3Avpn_treeherder deleted (was assume:project-admin:treeherder)

vpn_treestatus - Just a list of people, replace.

replaced with https://tools.taskcluster.net/auth/roles/mozilla-group%3Atreestatus

Greg -- I see vpn_hg_admin now. I assume that's VPN-linked and thus shouldn't be touched?

I'm fine with a group that's called 'vpn_x', where it's "vpn access to things" and also "a list of people who need related access". We do that for "you have vpn access to something" combined with telling puppet "these people have ssh accounts there".

What I don't want is a group called 'vpn_x' where it has no bearing on the VPN anymore (because someone migrated services away/decomed services), and that list of people is still being used somewhere else, because someone may carelessly delete a group, "because it has no use in the VPN anymore."

vpn_releasemgmt and vpn_hg_admin all have VPN uses, so they're fine as is.
If you want to perform the same split of groups and move releasemgmt/hg admins to some new group, I won't resist, but I'm also not pushing you to do so.

If this bug is at the point of "we'll land this change, wait a couple of days to make sure nothing breaks, and then you can delete vpn_sheriff, vpn_tooltooleditor, vpn_treestatus" then I am totally happy. I'm sure we'll have more of these as time goes on, but I'm happy for now.

Sounds good. And, it's at that point, yep.

Landed, and

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

vpn_sheriff, vpn_tooltooleditor, vpn_treestatus deleted from LDAP 2019-05-07 20:25 UTC.
Thanks!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: