Proposal: Implement Automated GitHub Permission Control via CLOWarden (GitOps)

[riaankleinhans]

The Problem: Manual "Ad-Hoc" Governance

For several years, OpenSSF GitHub teams and permissions have been managed manually by a rotating group of trusted individuals. While this worked in the early stages, it has led to several critical pain points:

The "Off-boarding" Gap: Everyone ♥️ onboarding, but nobody is great at off-boarding. This leads to "permission creep" where former contributors retain access indefinitely.

Lack of Transparency: There is currently no centralized, searchable audit trail explaining why a specific person was added to a specific team.

Manual Toil: Administering a massive open-source ecosystem through the GitHub UI is not scalable and is prone to human error.

The Solution: CLOWarden

To move toward a more secure and scalable model, I propose adopting CLOWarden. Developed by the CNCF team behind Gitvote and the Landscape tool, CLOWarden brings GitOps principles to organization management.

Executive Summary
Declarative Infrastructure: All users, teams, and permissions are defined in YAML configuration files.

Automated Reconciliation: The tool continuously syncs the Desired State (Git) with the Actual State (GitHub), automatically reverting any manual, out-of-band changes.

Peer-Reviewed Access: Permission changes are proposed via Pull Requests. This ensures every access grant is validated by peers and documented before deployment.

Audit & Transparency: Maintains a searchable history of all changes, linking every access grant to a specific PR and approver.

Implementation Details & Developer Feedback

We have engaged with the CLOWarden developers, and they have provided the following insights regarding deployment:

Ease of Install: A Helm chart is available for Kubernetes deployment.

Low Overhead: The service is lightweight—essentially a small web service talking to a PostgreSQL database.

Proven Reliability: Projects like Karmada have been running their own instance for months without issues.

Support: The maintainers are available to answer questions during our installation process.

[!IMPORTANT] Operational Note: While the resource footprint is small, the service requires an owner. If the service goes down, automated syncing stops, requiring troubleshooting by the infrastructure/ops team. This is a critical consideration for a service managing organization-wide permissions.

Presented in OpenSSF TAC meeting on Feb 3, 2026
Related document

[justaugustus]

Copying in the TAC meeting notes from 2026-02-03:

OpenSSF GitHub Permissions [Riaan]

• Example: https://github.com/cncf/people/blob/main/config.yaml
• Proposal: https://docs.google.com/document/d/1oDf495yJ8e11IZZIg0DrdVGgAA2H8OfNIBSZuX72hgE/edit?tab=t.0
• Riaan currently manages OpenSSF GitHub access manually. There are some with permissions that do not need them anymore, but there isn’t an efficient way to manage this.
• Riaan recommends using CLOWarden, developed by CNCF. This would allow us to manage access using YAML configuration files. This would require an instance running in a cluster and there would be some monitoring/maintenance required.
• [Stephen questions]
  • Who will maintain the instance?
  • Where will we run it?
    • Kubernetes cluster
  • Federating approvals via subdirs + CODEOWNERS?
• Some concerns were raised about the value add vs. time needed to implement CLOWarden.
• Riaan will open an issue in the TAC repo for further discussion. - PR #572

---

As I mentioned on the TAC call, I'm very much in favor of a publicly auditable workflow for GitHub org management.
Having said that, we need to discuss and come to decisions on the following questions...

Who will maintain this instance?

For CNCF, staff is ultimately responsible for maintaining this infrastructure.
For Kubernetes (who uses peribolos), there is the GitHub Management subproject, which is part of their Contributor Experience Special Interest Group

I'm not sure that we have an equivalent function as a foundation?

Where will we run it?

Someone mentioned "Kubernetes cluster" in the notes, but I'm less concerned about the implementation details, and more interested in our ethos.
While this is lower cost infrastructure in the grand scheme of things, there is a position that the OpenSSF should not be paying for long-lived infrastructure (and this is very much long-lived infra).

Federated approvals

Can CLOWarden support sharding the org config into separate subdirectories, so that user/team modifications can be handled by the governance groups who are best-positioned to understand who should be a member? i.e., staff or a small maintainer pool should not be a bottleneck to make non-admin changes