Feature Request: Administrative Privilege Elevation ("sudo") for GitHub Enterprise #200847
Replies: 1 comment
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🏷️ Discussion Type
Product Feedback
Body
🚀 Feature Request: Administrative Privilege Elevation ("sudo") for GitHub Enterprise
I'd love to see GitHub adopt a privilege elevation model similar to Linux
sudofor Enterprise, Organization, and Repository administrators.Many enterprise customers authenticate through an IdP such as Okta, Entra ID, or Active Directory. In our environment, we intentionally maintain a single identity for each administrator. I don't want separate admin accounts, different browser profiles, or other workarounds just to perform administrative tasks.
Today, the experience largely assumes that if you're an administrator, you're operating with administrative privileges all the time. I don't think that's the ideal balance between usability and security.
👀 Administrative Browsing Mode
My suggestion is that administrators should always be able to navigate every administrative page they have access to. Let me inspect Enterprise settings, Organization settings, Repository settings, Actions policies, runner configuration, and everything else.
The difference is that, until I elevate my privileges, those controls would simply be read-only. Buttons would be disabled, editable fields would be locked, and GitHub could display a subtle indication that privilege elevation is required before changes can be made.
A large percentage of administration isn't making changes—it's answering questions, verifying configuration, or troubleshooting. Viewing configuration shouldn't require operating in an elevated administrative context.
🔑 Elevate Only When Necessary
The first time I attempt to change a protected setting, GitHub would prompt me to elevate my privileges.
Depending on enterprise policy, that could mean re-authenticating with my IdP, completing MFA, using a passkey, or satisfying whatever authentication policy my organization has configured.
Once verified, GitHub grants me a short-lived elevated session, very similar to running:
💻 Administrative Mode
Sometimes I'm making several related changes and don't want to re-authenticate for every click.
It would be great to have an Enter Administrative Mode option under the profile avatar—essentially the GitHub equivalent of
sudo -s.GitHub could make it obvious that I'm currently operating with elevated privileges by changing the UI in some way, and that elevated session could automatically expire after a configurable amount of time. I should also be able to leave Administrative Mode whenever I'm finished.
🌎 This Shouldn't Stop at Enterprise
I think this would be valuable everywhere administrative privileges exist: Enterprise settings, Organization administration, Repository administration, and eventually even the GitHub CLI and APIs.
The web UI is probably the easiest place to start, but having a consistent privilege elevation model across GitHub would be fantastic.
🎯 Why I Think This Matters
One of the principles many of us try to follow is least privilege. Ironically, today's experience can encourage the opposite because it's simply more convenient to remain fully privileged all day than it is to constantly switch contexts.
A privilege elevation model would encourage administrators to spend most of their day in a read-only administrative context and elevate only when they actually need to modify something.
It would also make accidental changes less likely. We've all clicked the wrong button before. Having a deliberate elevation step before modifying Enterprise settings adds a natural pause that makes those actions more intentional.
Finally, I think the audit trail becomes much richer. Instead of simply recording that an administrator changed a setting, GitHub could record the privilege elevation event, the authentication method used, the administrative actions performed during that elevated session, and when the session expired.
💭 Closing Thoughts
Linux solved this problem decades ago.
Modern cloud platforms are increasingly moving toward just-in-time privilege elevation.
I'd love to see GitHub adopt a similar philosophy.
Let administrators inspect everything they have permission to administer. Require elevation when it's time to make changes.
To me, that feels like a better balance between security, usability, and day-to-day administration.
.
Beta Was this translation helpful? Give feedback.
All reactions