[Feedback] Custom Organization Roles

[hpsin]

Custom organization roles let you delegate administrative permissions to users in your organization. This feature is limited to GitHub Enterprise Cloud organizations.

If you have requests for permissions that should be added, please let us know here, and that'll help us prioritize better. Likewise, if you have any feedback or encounter bugs, you can let your account team know or let us know here.

Upcoming changes

• Ability to see indirect assignment of roles to users (i.e. a user has a role through a team - that role can be seen from the user's role assignment UI)
• Ability to see the net permissions that a user has (the union of their roles)
• Filtering the assignment UI by permission, not just role

Known issues

[pragmaticivan]

Hi @hpsin I see Github has a huge gap in ViewOnly permissions. We often need to pick between individual contribution roles and admins because there's no way to set ViewOnly both on org level (for all the settings) and repository level (for all the settings). Are there plans to include granular and individual ViewOnly permissions in this list?

[hpsin]

Hey @pragmaticivan , that's not the main goal, but it's something we can include in our guidance to teams. Do you have particular settings that you want to allow ViewOnly access to? Right now teams are mostly focused on allowing granular settings management permissions - i.e. "Manage SAML/SCIM settings", as opposed to "View SAML/SCIM settings".

For the example above, I could imagine a "View SAML/SCIM settings" being useful for a troubleshooting team wanting to see and diagnose SCIM sync issues - but in many cases I'd then want that team to also be able to fix the problem, with the management permission.

[pragmaticivan]

Everything under this list would be a good start:

• Actions
• Webhooks

But in general, the gap happens under the Repository settings most of the time, and less in the org, so maybe I'm inflating by posting about both in this thread, sorry about that :D

[congon4tor]

Hi all, I'm a Cloud Security engineer and spend a lot of time auditing company's github accounts (org settings, repo settings, github actions...).
Currently there is no way for these companies to grant me read-only access to everything (except secrets). Most end up granting me org admin which is less than ideal.
An overall org wide viewonly role would be super helpful.

[rbability]

It would be useful for us to have permissions that

• allow Users to create Repos in an organization
• manage / assign secrets in the organization settings to repos
• manage / assign runners or runner groups in the organization settings to repos

Reason: Currently we do not allow creating / managing these settings for the whole enterprise. But for the dev teams to stay flexible and still make sure that naming conventions and other organizational topics are met, the only option currently is to give a subset of our employees Organization Owner permissions. And that is much more than is needed to create new Repos, Assign Runner Groups and Organizational Secrets / Variables to these new repos.

[hpsin]

Thanks! Runners group management is currently under development, and secrets management is a recognized need.

For repo creation, you don't have to be an org admin to create a repo: https://docs.github.com/en/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization

Are you looking to grant that permission to only a subset of the users in your organization?

[rbability]

@hpsin Sounds all good, thanks for the update about the Runners group management and secrets management. I am really looking forward to it :-)

Regarding your quesion: Indeed, that is exactly what we can not do at the moment without granting them Organisational permissions. For us it is not just about "that a repo exists". When a project starts, a Code repo is one of many pieces in our organization that have to work together. Projects are created, Plans, stuff in the ERP system, Documentations... and Code repositories. We have to tie these pieces together as good as we can (partly through naming conventions that needs to be obeyed) and make sure that developers have repos that behave in the same or similar way, so they can just code and not need to take care of DevOps stuff too much. And we found out that it works reliable when a small subset of your employees is responsible for certain tasks. Leads of our Dev Teams are allowed to create the repos and they do it according to our standards / rules. They know how to create them, what settings we want, which secrets / actions are needed for certain repos etc. But currently they need Organizational Admin permissions to do just that and these are a lot of permissions that are not needed to do this job. Following the pricinple of least permissions ist not possible for us at the moment and this would be a huge improvement.

[hpsin]

FYI, runner management permissions shipped!
https://github.blog/changelog/2024-03-06-actions-fine-grained-permissions/

[tmabbott-hbs]

We would benefit from permissions that allowed us to create a role for someone to invite/remove members of the org. Currently we can only do this will full owner access, which is too much.

[hpsin]

ACK, it's on the list, thank you!

[nearlythere]

@hpsin re: Invitation and membership permissions - Can we follow along in a public roadmap item? I'd like to know if it meets the expectations we have.

[bchase-humana]

Ability to assign a team with permissions to manage Org Secrets would be beneficial if that is possible.

[hpsin]

The org secrets permission was just shipped - check it out!
https://github.blog/changelog/2024-03-06-actions-fine-grained-permissions/

[bchase-humana]

awesome

[mariusfilipowski]

Currently we would see the need for those functionality in GHES:

• Creation and managing a single (!) GitHub App in an org - not all
• Installation of a GitHub App to an ORG and manage the repos assigned to it
• Check messages sent to WebHooks of a single GitHub App (e.g. self-hosted runners)
• Refining permissions for a single GitHub App
• Managing Organization secrets / variables for a subset or repos, not all at once
• WhiteList GitHub Actions for an ORG
• Define or Change Security Settings for Github Actions
• Check status of GitHub Action Runners (readonly)
• Adjust settings for Advanced Security
• Change default Member permissions
• Check audit logs

[sandstrom]

A few granular permissions for Organization roles that we'd find helpful:

• View-only access to ruleset insights
• Read/write access to 'Whitelisted GitHub Actions for an org'

Also, I second a previous comment, that overall Github should provide more read-only permissions. Those are generally useful for providing insight, without giving too much access.

---

Also, related to permissions, It would be nice if we could completely disable these things org-wide:

• Deploy keys (we aren't using them)
• Webhooks (or at least somehow whitelist domains/recipients?)
• Disable 'Branch protection rules' org-wide (since we've moved to Rulesets, we don't need them)

[Timmmy-nlb]

I would like to be able to delegate the following rights:

• Insert/remove org members
• Check status of GitHub Action Runners (readonly) (shared/self hosted)
• View Billing usage (readonly)
• View/Edit Organization secrets & variables
• Edit Announcement

[hpsin]

View/edit org secrets and variables is now a permission! The runners one may or may not be granular enough for your desires. https://github.blog/changelog/2024-03-06-actions-fine-grained-permissions/

[Timmmy-nlb]

Thank you for the hint! 👍

[Timmmy-nlb]

But a "View (only) GitHub Runner at org level" I'm missing...

[bchase-humana]

• org secret management but have support for

  • restrict access to a specific set of secrets
  • block access to a specific set of secrets - effectively ensure that key secrets can only be managed by org owners but allow for privileges to create new secrets

• repo admin privileges across all repositories within a given org - avoids provisioning org owner privileges

[balusena]

View/edit org secrets and variables are now a permission The runners one may or may not be granular enough for this case.
see this link for reference ===> https://github.blog/changelog/2024-03-06-actions-fine-grained-permissions/

[balusena]

Response #1

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[ojintoad]

I am unsure if this is the correct community spot to leave this feedback as this isn't specifically related to custom community roles but rather the built in ones.

The documentation for assigning teams as pull request reviewers requires that a team have direct read access assigned to the repository:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews

Repository owners and collaborators can request a pull request review from a specific person. Organization members can also request a pull request review from a team with read access to the repository. For more information, see "Requesting a pull request review." You can specify a subset of team members to be automatically assigned in the place of the whole team. For more information, see "Managing code review settings for your team."

That is:

1. If a team is assigned the organization wide read role to all repositories, they can not be assigned as a reviewer to a pull request
2. If a team is assigned as a read role directly to a single repository, the can be assigned as a reviewer to a pull request for that repository only

We desire an ability to have a user assign a team to a pull request review by only have 1 assigned and not having 2 assigned.

Can this be accomplished somehow?

Please let me know if there is a better location for this request.

[hpsin]

Thanks! This is definitely the right place for that feedback. This is a known issue with PR review assignment and the team is working on a fix.

[ojintoad]

Thanks for the positive response @hpsin . Do you have any ETA? Currently my plan is to roll out a lot of direct team access links to repositories with IaC but I would prefer to try to avoid that if at all possible.

[Rymania]

We used custom roles in our org (e.g. role to manage org rulesets only). One thing we've found is missing is a permission to approve/manage fine-grained PATs - right now this is only possible for Org Owners. Are there any plans to expand the available custom permissions?

[hpsin]

Definitely something we plan to build, but not in the next 6 months. I'll link the work item to this though so we remember to let you know when it's on the way.