GitHub Enterprise and Organization IP Allow Lists
Make sure you understand and manage all of them
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: GitHub Security | Application Security | Secure Code
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At some point GitHub popped up a message when I logged in and asked me if I wanted to create an “Enterprise” or something to that effect.
What’s this? Sure why not if it doesn’t cost anything. I imagine it’s a way to have an enterprise with different GitHub organizations for different lines of business. That makes sense. You might want to allow different people to control the GitHub settings for different parts of the organization.
I do these things to test configuring and security of certain products like GitHub, Okta, AWS and other cloud services. I didn’t know what would happen to my account when I clicked that button.
What it did was to create an enterprise level context above my existing organization. When you login you switch to whichever context you want to manage at the top of the screen.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*RxskrncGI0bjhvrKXzFb4A.png)
What I also did not initially realize is that I had two different IP allow lists and somehow I ended up with IPs in both lists. I’m not sure how pushing that button determined which IPs should be in what list or I didn’t realize what context I was in when I added some new IPs.
I wrote about using an AWS EIP with GitHub here:
So it could be that once you set up an enterprise in GitHub you are looking at the enterprise context and thinking you know all the IPs that have access to your account, but that might not be the case. You also have to look at each individual organization context for that information.
One thing I don’t understand is why GitHub puts this under “Authentication Security” instead of “Network Security” but that’s where you’ll find it once you switch to your organization or enterprise context:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*NtlPN8ZYcE49tfhsDtHGog.png)
The other thing is, you can’t enable or disable IP AllowLists using your organizational context. You have to do that from the Enterprise context:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*qti7ZYq-5sVr1K7cxbXAeg.png)
I also don’t know why it says my IdP is not supported since I did not add an IdP but that’s another story.
If you head over to your Enterprise context it looks similar but slightly different and you can check or uncheck the boxes related to the IP Allow List. But be aware that others may be able to add additional IP addresses under the organization settings as well.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*yjrXJxmKEe_QFWCjocxkww.png)
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2024
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg)