-
Notifications
You must be signed in to change notification settings - Fork 228
Description
Dev teams want to use github actions for CI and PR status checks. With the current Github plan, Admin access to the repository is required at least for the maintenance of secrets. According to rfc-0014-github-teams-and-access only WG leads and TOC members have admin access for github repositories.
This blocks dev teams as they have to wait for a WG lead to apply the needed configuration. Several dev teams created temporary admin teams for their WG area as workaround (configured in https://github.com/cloudfoundry/community/blob/main/org/cloudfoundry.yml).
The following options shall be discussed to solve this problem.
1. Manually configured temporary admin teams
This is the current situation.
Pros:
- works today
Cons:
- cumbersome configuration, not well integrated in org automation
- approvers with full admin rights can delete repositories and bypass the intended access management
2. Github Custom Roles for WG area approvers
Idea is to grant WG area approvers all the necessary rights that are needed to maintain PR status checks and secrets without granting full admin access to the repositories.
The role would probably be close to Maintain with some additional selected permissions.
Pros:
- simple implementation, need just to assign additional permissions to the existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams
- no additional community roles and processes needed
Cons:
- requires a more costly Github plan
- unclear if custom roles allow to fulfill the requirements (secret management), needs a POC
3. Grant all WG area approvers admin rights
The existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams would get assigned to Admin role instead of Write role.
Pros:
- simple implementation, need just to assign
Adminrole to the existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams - no additional community roles and processes needed
- works with existing Github plan
Cons:
- approvers with full admin rights can delete repositories and bypass the intended access management
4. Additional community role 'WG area admin'
An additional community role (on top of reviewer and approver) is introduced that can be configured in the WG charter.
The org automation generates a new github teams wg-[WORKING-GROUP-NAME]-[AREA-NAME]-admins for each WG area and the members of the WG area admin teams get assigned to the github Admin role.
Pros:
- potentially dangerous admin access is granted to selected WG area members only (won't help for very small WG areas)
- works with existing Github plan
Cons:
- requires a new community role and related processes
- WG area admins can delete repositories and bypass the intended access management
Metadata
Metadata
Assignees
Labels
Type
Projects
Status