Cleanup / sort / re-organize Baloise Github Orga Groups, permissions, memberships, ...

[MarkusTiede]

KISS

[MarkusTiede]

[MarkusTiede]

idea(s)

open question(s)

• Outside Collaborators : supported by Peribolos? ❌
  • It seems like the kubernetes org disabled outside repo collaborators on the org level (only possible with enterprise: https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/setting-permissions-for-adding-outside-collaborators) and made them org members instead (see discussions in https://github.com/kubernetes/community/issues/3178 and https://github.com/kubernetes/test-infra/issues/1050)
• Alumni : transfer to outside collaborator on Orga?
• Team "All" --> Write Access : who can access / add / modify e.g. secrets?
• every operation via gitops / Peribolos : e.g. creation of new repos and default via template repository?

current state

• https://github.com/baloise/org/blob/master/.github/workflows/apply-org-config.yaml#L27
• additional information: https://github.com/kubernetes/test-infra/blob/master/prow/cmd/peribolos/main.go#L79

next step : ✅

v0

Organization ✅

• Owner - Has full administrative access to the entire organization: CoP Open-Source
• Member - Can see every member and non-secret team in the organization, and can create new repositories.
• ~Outside Collaborators~ (not supported by peribolos)

Teams ✅

• All
  • IT-CH_SECC_CM_Open-Source --> CoP Open-Source
  • ~CM_Monitoring~
  • ~IT-CH_SECC_CM_Java~
  • ~this-or-that~
  • ~Developers~ -->All
  • CICD pipeline --> IT-Group_CICD_pipeline
  • IT-CH_Bets
  • technical user(s)
  • ...
• Alumni

Repository ❌

• Setting (good) base permissions for an organization
  • All --> Write Access
  • CoP_Open-Source --> Admin
• avoid individual Repository permission levels for an organization

[christiansiegel]

How does the kubernetes project use peribolos?:

Even the kubernetes org doesn't seem to sync repo permissions via peribolos: https://github.com/kubernetes/org/blob/e1e8ec86d24aab7998a9804c7e996c6ca99117f7/admin/BUILD.bazel#L10-L13 Instead, they have 1..n teams per repo (could also be a group of repos): e.g. here https://github.com/kubernetes/org/blob/e1e8ec86d24aab7998a9804c7e996c6ca99117f7/config/kubernetes/org.yaml#L1563 Only admins (or bot admins) can create new repos. Default member repo permission is read. Probably the admins assign the team to the repos manually (or via the api) on creation.

Another interesting approach is to have only one org repo for all kubernetes github organizations. We could move the baloise-incubator config in here to reduce duplicated automation code. Also, having a dedicated baloise-retired org for alumni (or/and archived repos) may be a solution to restrict access.