Separation of Duties on GitHub
Separate fine-grained access tokens for different users and roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I showed you how to prevent caching credentials for a long time after running a particular script that accesses GitHub.
That approach also has the benefit that you can use separate fine-grained GitHub tokens with different permissions sets so you’re not providing access to all your GitHub repositories at once when you’re accessing Github.
More on fine-grained access tokens:
Create a personal access token on Github
Essentially a user clicks on their icon (photo or avatar) on the top right and clicks settings in drop down menu.
Next, scroll down and click on Developer settings.
Click on Personal Access Tokens.
Click on Fine-grained personal access tokens.
This is where you an create a token, select the repositories a user can access, an the permissions for the selected repositories.
Repository access by role, team, project, or environment
Because I only cache the credentials in memory and they are cleared at the end of the script in my last post, I can enter different credentials each time the script runs.
For example, I can update my script from the last post and ask which credential role I want to use when executing the script. Then I set the repo array accordingly. The person enters the credentials related to the group of repositories they want to access.
Let’s say you have separate repositories for development and production — something I’ve done in the past to mimic a source control system I used other than git. The code got checked into the deveopment responsitory. Then it was pushed to a QA repository. After it was tested, pushed to the production repository. This is an alternative to using branches for dev, QA, and prod. I’ll explain why someone might choose to do that in a bit.
For now let’s say you have dev and production repositories. Here’s the code change we would need to make (roughly). Let’s say I have a token for my developer repositories and one for my production repositories. I ask at the start of the script which environment they want to update.
The array is set to the GitHub repositories that the credentials the user needs to enter that have permission to access.
In other words, if I select 1, the script is going to loop through the prod repos and ask me for credentials on the first one. I have to enter my production credentials or the script will fail. At the end of the script, the cache is terminated and new git commands should require new credentials.
If I select 2, I have to enter my developer credentials or the script will fail.
Benefits of separate repositories and accounts
If you put your production and development repositories in two separate GitHub accounts, then you can require that a user must be on a particular network to operate on production repositories and vice versa. I showed you how to edit the network restrictions for GitHub here:
If you had an operation that pulled code from dev and pushed it to prod, it would first need to connect to the dev network, pull down the code, and then connect to the production network and push that code to production.
That’s related to not exposing the keys to your kingdom in the post I wrote about AWS SSO. You might want to take steps to ensure one set of credentials cannot access everything you have in your source control repository.
Yes, it’s a lot more work than simply pushing code to a new branch so you’ll need to consider if your code and assets are worth the additional complication. Complexity is often the enemy of security, if you don’t think it though and make sure your implementation is airtight. Automation is best for this scenario.
You’ll also need to make sure you have code integrity checking in place to ensure no changes are made to the code as it migrates from development to production. You could have a separate read-only tokens accessible from one IP that checks that the development branch pushed to production matches production, for example.
This is the process I used when I formerly taught cloud security classes with labs. I stored the class code I wrote in one repository. Then I pushed it to a separate source control account — it was actually even a separate vendor — for students to access. That’s how I knew that likely one of my students or someone with access to the network where I ran my class infected the student repository in the post I wrote about here:
The change that someone made was not in the repository where I or the person helping me performed development work, only in the class repository. I had pushed the code to the class repository myself. The people helping me did not have access to it once it left the development account.
I had accessed the class repository for class during class (something I noted I never did again after that class in the above post). I never accessed the development repository during class or used those credentials. That code was unscathed. No one in the class even knew it existed. Only the repository for that particular class had somehow been altered.
Also, I deployed separate repositories for each class. The only affected class was the one I opened up to the public in Seattle. None of the code for my private classes in separate repositories was affected.
In my opinion, people do not think about segregation of duties enough when it comes to source control. Should some credentials become compromised, how much of your code would be affected? Suppose it was ransomware…
Separate git tokens for separate repos
Here are some of the scenarios where you might have a user with multiple tokens to run deployment scripts.
A user may have separate tokens for separate GitHub accounts with different owners. A Github personal access token can only be associated with a single account.
You may also want to give different teams or different roles access to different repositories.
You might have a token used for day to day development purposes with lower permissions, and a token that you use for administrative or automation functions.
If you use the script I provided in the last post with the modifications above, it should work for all your tokens, and when you end the script the tokens are removed from memory.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow 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
