Clarify how access is controlled (to CI, machines etc.)

[gibfahn]

Having just joined the build team, I'm a little unclear on how accesses are managed.

It'd be good to clarify and set out how everything is managed. Obviously for things like CI access there will be overlap with other groups like CitGM and libuv.

Based on discussion with @jbergstroem in IRC, permissions are as follows:

• nodejs/build: allows you to configure machines in CI, also grants access to the secrets and build-private repos. This is what you join when you join the build team.
• nodejs/jenkins-admins: gives full admin access to the test ci. Most of the build team are in here, but I suspect it's not part of build team access.

I'm not sure whether there is any other level of Jenkins related access.

[jbergstroem]

I think the "issue" with jenkins-admins is that the majority of that groups inherits ownership as part of other groups, such as the TSC. The idea was to have a small circle have "full" access to jenkins since having that gives you access to things like ci-release and similar.

I think one way forward would be elevating control for the build group so they can configure jobs in CI; we just need to check that it doesn't violate any security limits we have (for instance node-private jobs that are related to security).

[gibfahn]

@jbergstroem Does that mean that jenkins-admins should be a subset of nodejs/release?

I agree saying that build != jenkins-admins is a good idea, it means we can have more people in the build group!

[jbergstroem]

@gibfahn nodejs/release have access to ci-release but cannot modify the jobs. jenkins-admins are the highest level of access we have.

Edit: the idea being that the release group can create releases but not necessarily meddle with infra.

[gibfahn]

@jbergstroem Is there anything I can do to help out with this? Maybe check which jobs are node-private?

[jbergstroem]

@gibfahn I'd hate for this to sstall progress, so I'll just add you to all citgm jobs; but we should probably still figure out userlevels in jenkins. We also have finer grain control over things like libuv so their team can access it, so it would make sense.

[mhdawson]

I'm thinking we could do something along the following lines:

1. when necessary for a particular WG, set so that they can control who can run/configure etc along the lines of what we did for libuv
2. Ask that the follow something along the lines of: https://github.com/nodejs/build/blob/master/doc/process/special_access_to_build_resources.md in terms of ensuring a level of trust in those that are given access and for how long. If necessary it might even include an audit after jobs have been created to sanity check that they are not doing anything unexpected.

[mhdawson]

I'll add I can see this being useful for the benchmarking WG as well.

[gibfahn]

I know that @nodejs/citgm were interested in this as well (for giving non-build members access to the citgm jobs).

[mhdawson]

@jbergstroem if you think what I've suggested could make sense, I'd volunteer to write up a first cut at what we might document as the policy/requirements for granting people access to be able to

• run a specific job
• be able to configure jobs in a particular category.

[jbergstroem]

I think we can be more generous with providing access to specific groups for certain jobs. It will probably even make more sense if they are named consistently (citgm, libuv, etc).

When it comes to specific people to for instance test-commit or test-pr, that would probably benefit to similar documentation as what we have for temporary ssh access.

[gibfahn]

Fixed by 1fcbba2