KubeVirt Org wide branch protection for tide managed repos

[Daniel Hiller]

Hey folks,

since we are preparing for CNCF graduation of KubeVirt, one of the open stories of this process is the requirement that all changes must occur publicly visible.

To ensure that "invisible" changes don't happen any more, reducing access levels to repositories and adding branch protection settings is required. 

Therefore we ask all repository maintainers under the KubeVirt org to revise the branch protection configuration for their repositories, revise the access level privileges to repositories, and finally create pull requests with the necessary configuration changes.

To aid in the process we have created a document [1] that describes the process. 

Please reply to this thread or add comments to the document should you have further questions.

Thank you!

[1] https://docs.google.com/document/d/11DygGJMDv_59XRfCzIHTxjPIwbdO7FJgRzsnF0shNSw/edit?usp=sharing

--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com   

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

[Fabian Deutsch]

Daniel,

see my reply inline below

On Mon, Jun 24, 2024 at 1:32 PM Daniel Hiller <dhi...@redhat.com> wrote:

Hey folks,

since we are preparing for CNCF graduation of KubeVirt, one of the open stories of this process is the requirement that all changes must occur publicly visible.

To ensure that "invisible" changes don't happen any more, reducing access levels to repositories and adding branch protection settings is required. 

Therefore we ask all repository maintainers under the KubeVirt org to revise the branch protection configuration for their repositories, revise the access level privileges to repositories, and finally create pull requests with the necessary configuration changes.

We are looking forward to see maintainers to change their configuration.

Eventually we need to decide about a policy for the org (github.com/KubeVirt) in order to have a consistent configuration i that regard.

Thus while we encourage every maintainer to start to opt into this (safe!) configuration, we should also look into how to - possibly - make this required down the road.

- faian

[Daniel Hiller]

Fabian,

On Mon, Jun 24, 2024 at 2:35 PM Fabian Deutsch <fdeu...@redhat.com> wrote:

Daniel,

see my reply inline below

On Mon, Jun 24, 2024 at 1:32 PM Daniel Hiller <dhi...@redhat.com> wrote:

Hey folks,

since we are preparing for CNCF graduation of KubeVirt, one of the open stories of this process is the requirement that all changes must occur publicly visible.

To ensure that "invisible" changes don't happen any more, reducing access levels to repositories and adding branch protection settings is required. 

Therefore we ask all repository maintainers under the KubeVirt org to revise the branch protection configuration for their repositories, revise the access level privileges to repositories, and finally create pull requests with the necessary configuration changes.

We are looking forward to see maintainers to change their configuration.

Eventually we need to decide about a policy for the org (github.com/KubeVirt) in order to have a consistent configuration i that regard.

Thus while we encourage every maintainer to start to opt into this (safe!) configuration, we should also look into how to - possibly - make this required down the road.

Good point!

I could think of creating a reporting tool that checks two things per repository:

1) whether there's accounts with write access to repositories and 

2) whether the branch protection is active for the default branch (or list of branches)

The report would then generate an html status report with all repositories under the KV org (probably filterable as the other reports). 

A variant of that would be a periodic check per repository that checks the same but fails if a repo doesn't comply - possibly messaging the repo maintainers.

The former would give a nice overview for everyone, where the latter would be a good reminder for the maintainers.

WDYT?

 

- faian

 

To aid in the process we have created a document [1] that describes the process. 

Please reply to this thread or add comments to the document should you have further questions.

Thank you!

[1] https://docs.google.com/document/d/11DygGJMDv_59XRfCzIHTxjPIwbdO7FJgRzsnF0shNSw/edit?usp=sharing

--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com   

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

--

-- 

Best,

Daniel

[Fabian Deutsch]

Daniel,

On Mon, Jun 24, 2024 at 5:27 PM Daniel Hiller <dhi...@redhat.com> wrote:

Fabian,

On Mon, Jun 24, 2024 at 2:35 PM Fabian Deutsch <fdeu...@redhat.com> wrote:

Daniel,

see my reply inline below

On Mon, Jun 24, 2024 at 1:32 PM Daniel Hiller <dhi...@redhat.com> wrote:

Hey folks,

since we are preparing for CNCF graduation of KubeVirt, one of the open stories of this process is the requirement that all changes must occur publicly visible.

To ensure that "invisible" changes don't happen any more, reducing access levels to repositories and adding branch protection settings is required. 

Therefore we ask all repository maintainers under the KubeVirt org to revise the branch protection configuration for their repositories, revise the access level privileges to repositories, and finally create pull requests with the necessary configuration changes.

We are looking forward to see maintainers to change their configuration.

Eventually we need to decide about a policy for the org (github.com/KubeVirt) in order to have a consistent configuration i that regard.

Thus while we encourage every maintainer to start to opt into this (safe!) configuration, we should also look into how to - possibly - make this required down the road.

Good point!

I could think of creating a reporting tool that checks two things per repository:

1) whether there's accounts with write access to repositories and 

2) whether the branch protection is active for the default branch (or list of branches)

The report would then generate an html status report with all repositories under the KV org (probably filterable as the other reports). 

A variant of that would be a periodic check per repository that checks the same but fails if a repo doesn't comply - possibly messaging the repo maintainers.

The former would give a nice overview for everyone, where the latter would be a good reminder for the maintainers.

WDYT?

If it is not too much work, then this is helpful.

We need to be mindful about the data and should not share it publicly.