Codifying organization and repositories

[haydentherapper]

At the recent community meeting, we discussed codifying the members of the SLSA organization and the settings for the repositories in the org. This provides transparency around who are org owners & who are maintainers on repositories, allows us to standardize repository security, and makes it easy to add new members or repositories. This removes the need for repository admins, as repository configuration should happen exclusively through configuration. You can also limit the org admins to only those who need to manage the Pulumi account.

With the Sigstore org, we use Pulumi, which provides a free tier for OSS projects. Our org is codified with yaml configs, mapping yaml to the Pulumi API with https://github.com/sigstore/github-sync. We manage teams, users, repositories and bot accounts through configuration. It's been a very smooth process - changes are instantly applied every merge. Only challenges are removing users (which just requires manually "unlocking" the user to allow for deletion) and importing existing repositories (which requires a manual process), but this can be documented for org admins.

@cpanato has kindly offered to help with the set up, thanks Carlos! Happy to answer any questions. Let me know if you would like us to proceed with setting this up.

[lehors]

I apologize if I'm showing a lack of understanding but I couldn't attend the latest SLSA call unfortunately and the meeting notes are quite limited, so bear with me.

I must admit to wonder what problem exactly this is meant to address and whether it is worth adding a dependency to yet another tool.

This project is pretty small and although there always are things that can be improved, adding infrastructure around it ought to be done in a controlled manner with a cost-benefit mindset. Indeed, adding more infrastructure isn't free, it adds yet another piece that needs to be maintained by a very small team with limited time.

[haydentherapper]

@lehors, the motivations are transparency and security. There is no formal process for adding org members, and moving to configuration-as-code would allow the community to audit new member requests. The community can also audit who currently has access to repos, which is helpful if you need to know who is responsible for a PR or if you would like to propose removing an inactive member. As for security, you can codify repo settings (branch protection, merge rules, etc), which would allow you to standardize repo security across the org. This also makes security transparent as well for the community to audit and verify.

Even though the org is small, doing this work now rather than later if the number of repos and org members expands sets up good process. As for cost, the Pulumi OSS plan has no cost and no added infrastructure. If we did need to move off it, we could use Terraform directly, which would require storing tfstate somewhere - either in GCS (small cost + infra), or potentially in a private GitHub repo.

[lehors]

To clarify: I didn't mean financial cost, I'm talking about technical debt. It's one more piece to maintain.

[haydentherapper]

I recognize that, though I think the added infrastructure reduces friction in other ways that make it beneficial. And if it is found to add too much friction, it would be trivial to undo, there's no lock-in.

[lehors]

ok, we can give it a try.