Skip to content

Github project administration for WG areas #700

@stephanme

Description

@stephanme

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Inbox

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions