doc: major update to acess.md

[rvagg]

Coming out of #2005 and a discussion amongst infra via email, I thought it would be good to put down more of the reasoning behind the levels of access so it's clear to us what that is and hopefully clear to all how we deal with granting additional access (and that there is reasoning and a path for individuals who invest their time and skills here).

Some big changes but my hope is that this is you can be told to read if you want to become a member and it will all be clear how we work organisationally.

The bottom line is that we need to expand our people resources here and some of that expansion involves elevated access. But the path to elevated access is really tricky because we're dealing with security, stability, legal concerns and even concerns that are difficult to quantify like keeping our infra donors happy and not stepping on toes.

[mhdawson]

LGTM

[sam-github]

I'm very, very sympathetic to the risks of incautious access, but I worry that this veers close to a catch-22. Despite that sense that we have an intimidating mountain of work available, I'm struggling to find helpful things that can be done without access, and without doing helpful things, its hard to demonstrate competence. @richardlau and I both demonstrated competence the long way: nodejs collaboration.

[richardlau]

There are a few things that can be contributed without access, for example I have four pull requests merged into this repository that happened before I was given access ("contributing to resources in this repository where you see need"). Since collaborators can view (but not change) job configuration in Jenkins it's even possible to suggest fixes to jobs ("attempting to assist Build WG members where you are able").

I wouldn't necessarily say it's easy -- you need some idea of what is where.

[rvagg]

Agree, this is a very difficult corner but this PR is intended to clarify current thinking and open discussion for amending that thinking where we can. So if you have suggestions for how to change things then speak up!

[sam-github]

This PR reflects how it is, so I'm good with landing it.

I'm not sure if here or #1990 or somewhere else is a better place to discuss this, but I'll do it here for now. For bystanders, I don't have a handy link other than the last WG meeting, but the TSC is asking the board to ask the member companies to contribute people to the build WG.

I am concerned that it will be difficult for anyone who has time donated to the project to get enough access to actually do anything with the current policy.

At the same time, I don't want to suggest a policy of "instant access for any IBM employees", that would be unreasonable. I hope that is obvious, but I want to acknowlege that that would be totally inappropriate, and I am not trying to suggest such a thing.

But, for example, if any active WG member (@joaocgreis or @rvagg as an example) introduced someone I'd never heard of before, provided evidence they fit the "trust through employer criteria", and personally committed to mentor the individual into the WG, review their work, help them understand how the systems work, etc., I would give them a plus 1 for basic access *.

I'm willing to be told that I'm too generous with my transitive trust, and should be more cautious, but that's how I feel at the moment.

*: start/stop ci jobs and view ci config, access to view secrets repo and access to decrypt the "test" secrets -- so basically ssh access into test machines, which is sufficient to ansible them, start jobs to test correctness of machine config, and to land things in the build WG repo.

[sam-github]

Somewhere else it was suggested I could say something about how IBM manages sensitive access, in case it gives any useful context. I don't speak with authority on our policy, but what it looks like to me as a user is:

1. If I want access to a resource, there will be a website I go to to make the request. I'll be given a link to the policy for that resource, and asked why I want it, and I submit the request and reason for it.
2. (I think) behind the scenes my manager certifies my request reason is accurate, and the manager of the resource certifies (or not!) that my request meets the policy.
3. I get access, often an email with a OTP and link to instructions.
4. When I don't want it anymore, I can go back the site, and request removal. I think this usually needs less or no approval.
5. important it seems most or all resources trigger a yearly reminder to re-certify that the resource is still in use and needed, at which point if I don't reconfirm the access request, my access gets automatically removed

So the basic principle seems to be chain of trust between humans, backed up by record keeping so its always known who has access and who authorized it, and automated systems to add and remove access, and particularly to remove access after a year if its not re-requested.