RFE: Member management with Peribolos

[aepfli]

Proposal

Within #174 we're already discussing the adaption of Peribolos, which makes managing memberships and repository assignments easier.

Peribolos itself offers a great variety of settings and can be used to manage not only organization management but also team assignments and repository permissions.

What do we want?

1. We want to have a GitOps way of assigning different permissions to members of our organization.
2. We want to have an easy approach with little to no duplication or too many points to edit alignment
3. We want to organize our members in teams with certain aspects.
4. We don't want to assign permissions per individual but on a team basis, so if you want specific permissions, you're part of a certain team.
5. We want to group repositories for teams, aka one team is responsible for multiple repositories - to reduce maintenance efforts
6. We also want to have overlapping teams for repositories as their might be the need to separate some access

Permission structure

Organization Level

First we do have roles on organizational level like:

Owners
Members

With respective permissions

Repository Level

Additionally if you are part of the organizational level you can also be one of those roles just for repository or repository group:

Repo-Maintainer
Repo-Approver

Proposal

In the end we can setup the repo-permissions for each repository, which means currently we would have 24 x 3 groups per github.com/keptn alone (if we need a dedicated group for all of them) but grouping would be easier and way better to handle.

Theoretically we could group the repository as follow (naive proposal)

* klt: * lifecycle-toolkit * wg-app-lifecycle * ops: (operational topics regarding how we deliver keptn) * helm-charts * helm-charts-dev * get.keptn.sh * gh-automation * dns.keptn.sh * keptn: * go-utils * keptn * examples * spec * integrations * kubernetes-utils * docs: * keptn.github.io tutorials * org: * enhancement-proposals * community * .github * toc * utils: * gh-action-extract-branch-name * keptn-on-keptn (not sure about that one) * gh-action-send-event * gh-action-build-docker-image * gh-action-ci-prepare-keptn-cluster

As the configuration file for this structure would be already quiet big and cover a lot of duplication

one config file for proposed solution without members

```yaml orgs: keptn: # org settings company: foo email: foo name: foo description: foo has_organization_projects: true has_repository_projects: true default_repository_permission: read members_can_create_repositories: false # org member settings members: - anne - bob admins: - carl # team settings teams: # Parent group for all maintainers so we do have an overview over all maintainers maintainers: # team config description: Keptn Maintainers privacy: closed repos: lifecycle-toolkit: maintain wg-app-lifecycle: maintain helm-charts: maintain helm-charts-dev: maintain get.keptn.sh: maintain gh-automation: maintain dns.keptn.sh: maintain go-utils: maintain keptn: maintain examples: maintain spec: maintain integrations: maintain kubernetes-utils: maintain keptn.github.io: maintain tutorials: maintain enhancement-proposals: maintain community: maintain .github: maintain toc: maintain gh-action-extract-branch-name: maintain keptn-on-keptn: maintain gh-action-send-event: maintain gh-action-build-docker-image: maintain gh-action-ci-prepare-keptn-cluster: maintain # Parent group for all approvers so we do have an overview over all approvers approvers: # team config description: Keptn Approvers privacy: closed repos: lifecycle-toolkit: triage wg-app-lifecycle: triage helm-charts: triage helm-charts-dev: triage get.keptn.sh: triage gh-automation: triage dns.keptn.sh: triage go-utils: triage keptn: triage examples: triage spec: triage integrations: triage kubernetes-utils: triage keptn.github.io: triage tutorials: triage enhancement-proposals: triage community: triage .github: triage toc: triage gh-action-extract-branch-name: triage keptn-on-keptn: triage gh-action-send-event: triage gh-action-build-docker-image: triage gh-action-ci-prepare-keptn-cluster: triage klt-approver: children: klt-maintainers repos: lifecycle-toolkit: triage wg-app-lifecycle: triage klt-maintainers: repos: lifecycle-toolkit: maintain wg-app-lifecycle: maintain ops-approver: children: ops-maintainers repos: helm-charts: triage helm-charts-dev: triage get.keptn.sh: triage gh-automation: triage dns.keptn.sh: triage ops-maintainers: repos: helm-charts: maintain helm-charts-dev: maintain get.keptn.sh: maintain gh-automation: maintain dns.keptn.sh: maintain keptn-approver: children: keptn-maintainers repos: go-utils: triage keptn: triage examples: triage spec: triage integrations: triage kubernetes-utils: triage keptn-maintainers: repos: go-utils: maintain keptn: maintain examples: maintain spec: maintain integrations: maintain kubernetes-utils: maintain docs-approver: children: docs-maintainers repos: keptn.github.io: triage tutorials: triage docs-maintainers: repos: keptn.github.io: maintain tutorials: maintain org-approvers: children: org-maintainers repos: enhancement-proposals: triage community: triage .github: triage toc: triage org-maintainers: repos: enhancement-proposals: maintain community: maintain .github: maintain toc: maintain utils-approvers: children: utils-maintainers repos: gh-action-extract-branch-name: triage keptn-on-keptn: triage gh-action-send-event: triage gh-action-build-docker-image: triage gh-action-ci-prepare-keptn-cluster: triage utils-maintainers: repos: gh-action-extract-branch-name: maintain keptn-on-keptn: maintain gh-action-send-event: maintain gh-action-build-docker-image: maintain gh-action-ci-prepare-keptn-cluster: maintain ```

I propose consolidating this into a leaner structure with an automatic merge (like Kubernetes is doing https://github.com/kubernetes/org) tailored to our needs. We will have an own Directory per organization we manage, either a subdirectory per group or a yaml file per group which will contain the necessary information see:

The org.yaml will contain basic information about the organization, such as general membership, description, etc. The group configuration (either within a subfolder, or directly named) will contain following configuration:

repos: # the repositories belonging to this team
  - go-utils
  - keptn

approvers: # list of users who are approvers for this group and its repos

maintainers: # list of users who are maintainers for this group and its repos

Our merger will than take all this information to generate the configuration, and apply it via GitHub Action to the defined organizations.

References

• https://github.com/keptn/community/issues/174
• https://github.com/kubernetes/org

Sponsors

• @thisthat
• @mowies
• @thschue

Checklist

• [ ] The idea is brought up for a discussion in a relevant Keptn Slack channel (use #keptn-project by default)
• [ ] Each sponsor should reply to this issue with the comment "I support".

[thisthat]

You can add me as a sponsor! I love the idea! It would also make it more transparent the additions of new community members

[mowies]

Great RFE, I support as well! One minor thing: we also have the repo keptn/lifecycle-toolkit-docs that is missing in the list above

[aepfli]

should we use the community repository for managing this?

[bradmccoydev]

This is a good idea!

[agardnerIT]

Excellent idea and should assist in getting people onboarded easier.

[mowies]

Are bot accounts handled separately in some form? Is there possibilities to have some special handling for them?

[aepfli]

Bot users are not handled separately, we can generate our own groups for bot users to be more specific - or we can also still add them as external contributors to projects where they're needed.

I do think we should take a close look at what the bots need to do, and in which manner - and do this based on their specific use case - to be honest, I don't have that much experience with bot users :) and we have to evaluate. At least I can say we're not blocking ourselves with this approach.

[aepfli]

i added a draft pull request for the logic, not for the groups etc. a warning: I am not the most proficient golang dev :) - i hope this is a good start, open for suggestions etc.

[thschue]

Added myself as a sponsor, I like the idea!

[mowies]

One thing that I suggest to add to this: It would be great to have the option of setting a group of admins on the org level, that then has admin access to all repos in the org. I don't think we'll need repo-specific options to grant admin privileges as well in the keptn org but it would be great to have for keptn-contrib and keptn-sandbox in the future.

One super-nice to have thing is also to set up repos through peribolos. It doesn't support all repo settings (i.e. branch/tag protection rules are missing) but having a single source of truth for repo settings would be super-extra-amazing!

In general, great work @aepfli !

[aepfli]

How do you think we should go about the global maintainer group? Should we put all Maintainers of Keptn and KLT in there?

As far as I know, this would also define the people with a specific voting power within this community. Beforehand it was just the Keptn repository, but now it somehow changed with KLT. just to have clarification, who do we want to put in this global group :)

As there have been no concerns issued so far, I would suggest continuing, and slowly getting this into "production" :) is this okay for everyone?

[aepfli]

223 is now ready for review:

• as this is quite a big change, i am asking for volunteers to take part in testing (we will create an own organization, and will only apply this with the participating members)
• i changed also the document regarding community membership - which i do think make sense based on the current structure (maybe we need to rethink her certain parts)

Looking forward to the reviews :)

[mowies]

I can help you with testing 👍🏼