-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rfc: revoke collaborator CI access after $x months inactivity #744
Comments
Seems like a good idea in general, but I don't see anything in Jenkins to make this work with Github auth. If we're going to do this I think it would be better to organise it with the Github teams, that way anyone who's a member can see who is in the inactive list (otherwise you could lose access and not be able to tell why). This seems related to the CTC emeritus labels, maybe we should have an inactive collaborator group. Added some labels at random. |
That's currently under discussion in the CTC but the rules around that will probably be much looser than what is appropriate for CI access, hence this issue. |
When you say CI access, you just mean the ability to start jobs right ? I think that is all regular collaborators can do in the CI over what unauthorized users can do. |
Yes.
That and use authenticated exploits as a jumping board. :-) |
I've been a fan of enforcing this for the build group seeing how we have access to a lot of machines. The tricky part is that we have to re-roll the keys (which we have an ansible script for) which means we should probably just have a purge every 6-or-so months. Sorry for potentially hijacking the thread. |
@jbergstroem a 6 month window seems a more appropriate time window to understand if someone become inactive. +1 for the |
@gibfahn Is CI access currently predicated on @nodejs/collaborators membership? (Note how I cleverly avoided cc'ing 500+ people by wrapping the at sign in |
@bnoordhuis Yes, CI access is predicated on collaborator GitHub team membership. FWIW, that's 100+ people. 500 would be the members team. The collaborators team is more like 100. |
So @Trott removed some folks in nodejs/node#16173, if we want to be more strict going forward, I think the answer is to move people to
Why not start with 12 and see how it goes? I think the usual "Raise PR, cc people, if no-one objects then go ahead" rules apply here. I don't think it's worth doing something fancy in build to basically create a subsection of collaborators that don't have CI access, so I'll close this. If there's anything build-specific that should be done please reopen. |
Strawman proposal: $x == 3
Rationale: inactive accounts are a security liability.
This need not be a sensitive, think-of-the-feels issue: a revoked account is easy to reinstate if the collaborator becomes active again.
I'm 80% sure Jenkins has the necessary functionality baked in but I don't know if it works with GitHub auth.
Also, anyone have suggestions on the appropriate labels? Infra, enhancement, something else?
The text was updated successfully, but these errors were encountered: