ADR-023: Delegate Administration of Outside Collaborators
Status
✅ Accepted
Context
A number of years ago Operations Engineering centralised the administration of outside collaborators i.e. users external to MoJ that collaborate/support MoJ projects.
The reasons for this were as follows:
Lack of joiners, leavers and movers process - Due to a lack or process outside collaborators were often left attached to MoJ repositories even after their work with MoJ had concluded. This gave these users access that they no longer required, and consumed GitHub licences.
Too many GitHub organisation owners - The organisation at the time had far too many owners which meant that there was a lack of oversight and consistency around how outside collaborators were added to the organisation, in some cases external users were being added as members, which gave them elevated privileges and access to internal repositories that they have no reason to access.
To address these problems, Operations Engineering centrallised the process for onboarding outside collaborators, reduced permission for those who could add these type of users, and started managing collaborators in code, which enabled a greater level of automation of the process.
Problems
The process has operated well, but over time a number of new problems have arisen, which has promted us to look at the current solution.
Problem - Over complicated process
Over the years additional business rules and features have been added that have made the process overly complex and difficult to maintain.
Problem - Lack of ruby knowledge
The original code is based on Ruby, and the Team no longer has sufficient Ruby expertise to maintain the existing codebase.
Problem - Increase in use of managing users in code
There has been an increase in the number of team that are managing their access and permissions to their own projects in code, which has enabled greater visibility of access and improved management through automation.
Problem - Inconsistent approach to managing access to repositories
The process for managing collaborators is inconsistent with how Service Teams manage access to their own repositories. This dilutes the security posture around managing access to a repository.
Options
1. Do nothing
Pros
- No work to do.
Cons
- Doesn’t address the emerging problems.
- Code gets staller and harder to maintain increaing risk of vulnerabilities.
2. Maintain the current process
Pros
- No new process.
Cons
- This is difficult as we have already established that we are unable to maintain the current code.
- Large amount of effort to learn how the current process works.
- Doesn’t address the emerging problems.
3. Replace the process
Pros
- Blank slate for how we manage the process.
- Reduce complexity based on what we now know about the process.
- Build code in a language that we can support.
Cons
- Doesn’t address issues around conflicts between Service Teams and Operations Engineering managing access
4. Delegate the process back to repository administrators
Pros
- Can decommission existing process.
- Reduce complexity.
- Consistent process for repository access and management.
- Service Teams can manage risks associated with access to their code.
- Doesn’t conflict with any access managed via code.
Cons
- Reliance on Service Teams to manage off-boarding process for collaborators.
Decision
We are going to implement option 4 (Delegate the process back to repository administrators).
This option addresses the emerging problems.
While this solution increases the reliance on Service Teams to remove collaborators, we now have an automated process for removing dormant users that would pick up inactive collaborators.
This solution also allows team the flexibility to manage their repository access without intervention from Operations Engineering.