When you ask a company outsourcing development, "Who currently has access to your repositories?", they usually cannot answer right away. They could find out by investigating. However, not being able to answer on the spot also means they cannot detect changes.
Pulling an actual roster often reveals accounts of contractors whose on-site assignments ended, former employees remaining with personal accounts, or permissions granted without any record of who requested them. This is rarely malicious; almost all cases are simply forgotten revocations.
Forgotten revocations happen because access is granted via UI clicks. A request arrives in chat, a manager opens the browser, authenticates, clicks through the interface, and finishes. The record remains only in the chat thread. Nobody digs up that thread six months later.
What is wrong with clicking through the UI?
Recently, a case study was published detailing the migration of GitHub permission management to Terraform. The stated motivation was operational fatigue: every time a new member joined or team structures changed, requests flowed through Slack workflows, requiring someone to open a browser and click through the UI each time.
Fatigue is just the surface; what impacts operations downstream are these three issues:
Current state cannot be viewed in one place. Organization member lists, team memberships, and repository-level permissions reside on separate screens. The complete picture exists only inside someone's head.
Reasons for changes are lost. Only the person who granted access can answer why a user has write permissions. When that person transfers, no one can revoke it. What people are unsure whether to revoke remains untouched.
Audits rely on visual inspection. Even if recurring audits are scheduled, because the comparison baseline is the previous visual check, you inspect all records rather than diffs. It does not last.
Moving to code turns requests into pull requests
Using Terraform's GitHub provider, units like Organization memberships, teams, team memberships, and team repository assignments can be maintained as configuration files.
This is where operations transform: Access requests shift from chat messages to pull requests.
- Commit history records who granted what permission to whom and when
- Approval becomes explicit in the form of code review
- Current state is readable as files (auditing becomes diff verification)
- When contracts end, submitting a pull request deleting the corresponding lines completes the process
This final point is most impactful for companies working with external contractors. Offboarding shifts from "remembering to revoke access" to "applying a diff." Even among companies with established account deactivation procedures in Google Workspace, it is not uncommon for code hosting to remain manual.
Trying to manage everything in code leads to failure
Attempting to codify everything in an Organization from day one usually stalls midway. The actual case study explicitly states, "We do not manage everything."
What is most valuable to codify are items that change frequently and require audit records.
| Target | Manage in code initially? | Rationale |
|---|---|---|
| Organization members | Manage in code | Changes most frequently with joiners, leavers, contract starts and ends |
| Teams and team memberships | Manage in code | Substantive permissions concentrate here |
| Repository assignments to teams | Manage in code | The core of "who can touch what" |
| Branch protection rules | Depends on circumstances | Low update frequency; little need to prioritize |
| Repository creation itself | Do not rush | Permissions cause more incidents than repository creation |
Following this order yields results within the first week. Conversely, starting from individual repository configurations drains momentum through importing minute existing discrepancies.
Where people actually get stuck
If you are considering adoption, there are four points worth knowing in advance.
Importing existing resources. Because resources already exist, you must map the current state into code. This constitutes the bulk of initial setup costs. As headcount increases, time grows, making the decision to narrow scope to members and teams highly effective.
Handling pending invited users. Users who have been invited but have not yet accepted are unconfirmed as members. They may appear as diffs on every apply, creating recurring noise unless operational rules are defined.
Association with personal accounts. GitHub accounts tie to individuals. If there is no mapping table between employee rosters and usernames, looking at the code provides no clarity on who someone is. Creating this mapping table first is surprisingly impactful.
Where to store execution credentials. Credentials used to run applies and storage locations for state files concentrate powerful permissions to manipulate the Organization. If kept on personal machines, the blast radius if a developer device is compromised spikes dramatically. Running inside CI and managing credentials as secrets is a prerequisite.
While this shares tools with managing entire infrastructure declaratively, permission management has a smaller scope and a shorter path to value. Even companies not yet advanced in Infrastructure as Code can start here first.
What clients ordering work can verify
Even without an internal engineering team, there are questions you can ask external contractors.
"Can you produce a roster of who can access our repositories right now?" If they can, follow up with: "Where is that roster managed?" If the answer is "in GitHub's UI," there is no guarantee access will be revoked when contracts end. Asking them to produce the exact same roster 30 days after contract termination makes things clear.
What to do next
Count how many times permissions were granted in your Organization over the past year. If it exceeds 10 times, it has reached a scale where records cannot be tracked through manual UI clicks.
First, place only members and team memberships into code, and accept subsequent requests via pull requests. With this alone, audits turn into diff verifications.
GleamHub provides consultations on development, AI, and automation covering permission design for development teams, access management including contractors, and establishing offboarding procedures upon contract termination. Because the appropriate scope varies depending on your team structure and number of contractors, please reach out via our contact form.
