Migrate Github Protected Branch/Tag Rules rules to Github Repository Rules rulesets #38
Description
Github Repository Rules, which has reached general-availability, is an evolution of Github Protected Branch/Tag. This issue is to track:
- Converting existing Github Protected Branch/Tag rules to Github Repository Rules rulesets
- Disabling the older branch protection rules and api
Further discussions
With this new solution, we should also consider the new potentials for enforcing repository security.
Org-wide enforcement
Enforcing an org-wide Github Repository Rules ruleset is only available for Github Enterprise users. However, we can consider creating a Github Action workflow in https://github.com/loopbackio/cicd to periodically poll and enforce. This would be of similar concept to our potential adoption of Peribolos (loopbackio/cicd#26).
Although the adoption of the OpenSSF Scorecard Action (#25) would allow us to detect non-compliance, it is not granular enough, does not have auditable self-remediation capabilities, and does not provide a single pane of glass.
Restricting bots' branches
TLDR: This is not fully possible.
Bots such as Renovate require push-rights to our Github repositories. However, this opens us up to third-party vendor risk where misused bot credentials can cause unwanted, destructive commit and tag modification to our repositories.
This is already partially-alleviated with the older Github Protected Branch/Tag feature, where we're able to mandate the creation of a pull request and restrict who can push new Git tags. However, we are not able to enforce this for the non-publishing (i.e. work-in-progress) branches which are created and deleted day-to-day.
Although Github Repository Rules allows layering and creation of bypass lists, it does not have an "apply to select bots/people only". This means that, even with a bypass list with non-bot members, we would still need to "bypass " the rules (i.e. "override" the rule) via the pull request page every time we want to merge. This is not ideal.