You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
The text was updated successfully, but these errors were encountered:
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.
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.
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:
Cons:
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:
Cons:
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 ofWrite
role.Pros:
Admin
role to the existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teamsCons:
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:
Cons:
The text was updated successfully, but these errors were encountered: