cloudfoundry/community

Github project administration for WG areas

stephanme opened this issue · 2 comments

stephanme commented

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 Admin role 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
anita-flegg commented

Option 2 looks like the cleanest, safest option to me. Seems like the lowest ongoing maintenance, too, because there wouldn't be special cases that would have to be updated from time to time.

stephanme commented

I'm afraid, option 2 won't work when it comes to github secrets. I played around with custom roles (on github enterprise, not on github.com) and I did not find a permission for secrets.
Creating secrets for a repository explicitly mentions:

To create secrets or variables on GitHub for an organization repository, you must have admin access.

There is a permission Manage deploy keys but the most requested feature was to manage secrets.

  • 😕1