Skip to content
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

Closed
bnoordhuis opened this issue May 31, 2017 · 9 comments
Closed

rfc: revoke collaborator CI access after $x months inactivity #744

bnoordhuis opened this issue May 31, 2017 · 9 comments

Comments

@bnoordhuis
Copy link
Member

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?

@gibfahn
Copy link
Member

gibfahn commented May 31, 2017

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.

@bnoordhuis
Copy link
Member Author

This seems related to the CTC emeritus labels, maybe we should have an inactive collaborator group.

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.

@mhdawson
Copy link
Member

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.

@bnoordhuis
Copy link
Member Author

Yes.

I think that is all regular collaborators can do in the CI over what unauthorized users can do.

That and use authenticated exploits as a jumping board. :-)

@jbergstroem
Copy link
Member

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.

@piccoloaiutante
Copy link
Member

@jbergstroem a 6 month window seems a more appropriate time window to understand if someone become inactive. +1 for the build-alumni group @gibfahn so we can move them back quickly if they become active again.

@bnoordhuis
Copy link
Member Author

@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 <span> tags.)

@Trott
Copy link
Member

Trott commented Jul 10, 2017

@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 <span> tags.)

@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.

@gibfahn
Copy link
Member

gibfahn commented Oct 22, 2017

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 emeritus and remove them from nodejs/collaborators more quickly.

Strawman proposal: $x == 3

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants