Governance: update maintainer Admin exception rule#28859
Conversation
|
+1 |
|
Note that this only gives access to org-wide CI configs. I don't have access to maintain repos that I'm not a maintainer of, ie buildah, skopeo. It might be a good idea to create a CI/CD repo role to give to those who need it. |
Ah I thought the org thing trumps repo rules but I guess not, I guess we need to create custom per repo rule then with "CI/CD Admin" access and then can assign users to that as well. |
|
[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore. |
|
Does this really give secrets access? Huh. |
So wait reading the github docs the ability to edit secrets should already be there with the write access So this role is really only about for org wide secrets/runner management. I don't think this role per repo would make sense. Looking into the role settings there seem to be difference between actions secrets which you get with write access
and
which the extra CI/CD role adds, totally not confusing... I know @ashley-cui needs the org wide role for the org wide runner management but for the per repo actions secrets we use it does not seem to be needed |
|
Ok this seems to be related to the environment feature Seems like something worth investigating to further harden release workflows |
|
updated the wording to mention both org and repo level rules, hopefully this is not to confusing |
Luap99
changed the title
|
LGTM |
| * Have a voice, but not a vote, in Core Maintainer decision-making meetings | ||
| * For repositories hosted on GitHub, Maintainers receive Maintain privileges by default by being added to the `<repo-name>-maintainers` team and removed from the `<repo-name>-reviewers` teams. | ||
| If they have a legitimate reason to require Admin privileges (e.g. working on project CI systems), a Maintainer can petition a Core Maintainer to be granted these additional privileges in GitHub. | ||
| If a Maintainer needs or wants to work on the CI/CD pipelines and requires elevated access to manage things like secrets or the github runners they |
There was a problem hiding this comment.
I think this should probably be a separate paragraph - newline before, no indentation
| If they have a legitimate reason to require Admin privileges (e.g. working on project CI systems), a Maintainer can petition a Core Maintainer to be granted these additional privileges in GitHub. | ||
| If a Maintainer needs or wants to work on the CI/CD pipelines and requires elevated access to manage things like secrets or the github runners they | ||
| can petition a Core Maintainer to be granted these additional privileges in GitHub. Depending on what kind of access is required they can be given | ||
| the "CI/CD Admin" *Organization* role which enables them access to organization wide runners or secret configuration or they can get the "CI/CD Admin" *Repository* role (must be granted per repository) to access the repository level runners or secrets. |
There was a problem hiding this comment.
"to organization-wide runner and secret configuration, or they can ask for the 'CI/CD Admin'..."
|
I'm LGTM either wording. |
Instead of granting people outright admin access we should limit the scope. Github offers us a org wide "CI/CD Admin" rule that can be used to manage all the import CI configs. In particular I assigned that role to Ashley as she requires that access to manage the macos worker pool. Using the roles to limit access is better for security as we do not have to give out Admin or org wide Owner access then. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
|
LGTM |
6 participants
Instead of granting people outright admin access we should limit the scope. Github offers us a org wide "CI/CD Admin" rule that can be used to manage all the import CI configs. In particular I assigned that role to Ashley as she requires that access to manage the macos worker pool.
Using the roles to limit access is better for security as we do not have to give out Admin or org wide Owner access then.
Does this PR introduce a user-facing change?