Audit tools for GitHub repo individual contributors (remove random individuals given admin on one repo and not org member unless says they should have access until )

[digitalronin]

Manage our github external collaborators in code so that we a) don't run out of slots, and b) know why, when and by whom a collaborator was added, so that we don't have lots of people with access to repos who shouldn't have it (because the project finished, or they moved on, or whatever)

• Write code to analyse our organisation and determine current external collaborators
• Create code (terraform) to manage this, and documentation to explain processes (raise a PR to add/remove collaborators, explain what information has to be provided)
• Create code to remove any external collaborators who aren't defined in the repo code

[digitalronin]

I just started to have a look at this. Step 1 is to scan our existing repos and find all the external collaborators. I think graphQL similar to that described in this thread should do what I need.

Unfortunately, I can't run the query because I don't have enough permissions:

 "message": "Your token has not been granted the required scopes to execute this query. The 'permissionSources' field requires one of the following scopes: ['admin:org']

To make progress on this, I can see a few ways forward:

• Temporarily make me an admin of our github organisation
• Generate a personal access token that I can use, with admin permissions, and revoke it later
• Set up a "scratch" organisation, which I do have admin permissions on, and I can develop the code against that

@SteveMarshall what do you think?

[digitalronin]

Relevant documentation links:

• https://www.terraform.io/docs/providers/github/r/repository_collaborator.html

[SteveMarshall]

@digitalronin I see no reason why you shouldn't have org-admin rights, honestly, so I've granted you those. Use them wisely, and let me know if/when you're happy to relinquish them (or you can revoke your own access).

There are a couple of other things that are probably outside the scope of this particular issue, but I'd like to see tackled overall as a result of this work, too:

• All manually managed collaborators are removed from all repos: all staff should get access through team membership, and outside collaborators should be managed through the process you're setting up here.
• All org members who are not MOJ staff (read: don't have @digital.justice.gov.uk or @justice.gov.uk email addresses) are made outside collaborators

[digitalronin]

I've made some progress on this. Code is here. I'll pick this up again next week. The next step is to iterate through all our repos and output a list of collaborators with access who are not members of the org.

[digitalronin]

For reference, there is some great work in managing github via terraform in this repo which we should ~totally rip off~ be heavily inspired by.

[digitalronin]

FYI, the initial list of the 313 github accounts who are not members of the ministryofjustice organision, but who have some access to our repositories is here: https://github.com/ministryofjustice/operations-engineering-github-collaborators/blob/main/non-org-collaborators.json

[digitalronin]

This is now running once per day, and posting data here

Data comes from here, and the posting is done via this github action

I think that's enough work on viewing the status of collaborators, so for the next phase I'll move on to creating terraform code to set collaborators, and some other code to remove any collaborators which are not defined in the terraform state file.

[digitalronin]

I need to add to the report so that it shows what permission the external collaborator has on the repository.

This will be necessary when it's time to import the existing collaborators and define them as terraform code: https://www.terraform.io/docs/providers/github/r/repository_collaborator.html#import

[digitalronin]

I've made more progress on this, adding code to import existing repositories' collaborators both as terraform code here, and into the terraform state for the whole repository.

So, the repo should now match the current state of this report.

The next steps are:

• Add code that looks for discrepancies between collaborators defined in the terraform code, and those which exist in github
• Set up continuous deployment on PR merge, so that teams can start to manage their collaborators in code

One thing I'm not sure about is how to get people to annotate the existing collaborators. This is both in a formatting sense - where and in what form should the information be added - and in a "how to get everyone to do it" sense. @AntonyBishop any ideas?

[digitalronin]

I've added github actions to the repo to do a terraform plan when a PR is raised/updated, and a terraform apply when it's merged to main.

Next step is to write the code to look for discrepancies between github and the terraform state, which will identify changes people have made outside of the code in the operations-engineering-github-collaborators repository terraform code.

[digitalronin]

I think I've figured out a reasonable way to manage getting people to input information about pre-existing collaborators, and moving towards an auto-delete system for "orphaned" collaborators.

I've amended the code so that each collaborator needs to be specified with:

• github_user
• permission
• name = "" # The name of the person behind github_user
• email = "" # Their email address
• org = "" # The organisation/entity they belong to
• reason = "" # Why is this person being granted access?
• added_by = "" # Who made the decision to grant them access? e.g. "Some Person some.person@digital.justice.gov.uk"
• review_after = "" # Date after which this grant should be reviewed/revoked, e.g. 2021-11-26

So, I'm going to amend this report to add some status information about the collaborator, and to only list collaborators with problems, where problems include:

• The collaborator is not in the terraform state (i.e. someone added them manually, since all the existing collaborators were imported)
• Any of the fields above are empty
• The review_date is in the past
• The review_date is too far into the future

This way, the report becomes a todo list that we can a) point people at and they can easily see where information is missing, and b) use as the basis for an automatic deleter to remove collaborators where the information hasn't been provided, or hasn't been updated recently.

[digitalronin]

Issues (i.e. problems) with collaborators are now being included in the JSON data by the reporter, and displayed on the web application:

So, I think we're ready to announce this to the organisation, and give them X weeks to fill in the missing information before we start deleting collaborators.

[digitalronin]

This is currently blocked waiting for a decision on our data privacy impact assessment. @AntonyBishop is in contact with the relevant team.

[digitalronin]

Now that we've heard back about the DPIA, I've gone ahead and posted comms in slack, giving folks until 2021-01-11 to fully define the collaborators they need.

[digitalronin]

After 2021-01-11, we should also restrict who can invite collaborators to our org: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-[…]ing-repository-management-policies-in-your-enterprise-account

Then, any collaborations will have to be created via PRs to the collaborators repo.

[digitalronin]

@AntonyBishop

I've added last commit date to the collaborators report so we can see if a given external collaborator is currently active before we delete them.

I've also added anchor tags, so we can send people URLs linking to specific repos, like this:

https://operations-engineering-reports.cloud-platform.service.justice.gov.uk/github_collaborators#bichard7-next

(To grab the URL for a repo, click the </> next to it's name, and then copy the URL from the browser address bar)

Question: What counts as "currently active"?

i.e. how recently does someone need to have committed to a repo for us to chase them rather than just remove them?

I'm thinking maybe 6 months, which would mean if they last committed before 2020-07-11, they just get removed.

What do you think?

[AntonyBishop]

Thanks @digitalronin I think 6 months is also a reasonable period of time. We can review dependant on any feedback we get.

[digitalronin]

The first iteration of this is done. I'll raise a ticket (#104) for the next steps, but those can wait a while.