Access Control and Secrets: Protecting the Keys to the Kingdom

Permission levels

Both platforms let you assign different access levels per repository instead of an all-or-nothing choice. GitHub’s roles run roughly from read (can view and clone) through triage, write (can push and manage issues), maintain, up to admin (full control, including who else has access). GitLab’s equivalent scale runs Guest, Reporter, Developer, Maintainer, Owner. The exact names differ, the idea doesn’t: this is the principle of least privilege, the same one that applies to any other system, applied directly to source code. Give someone exactly the access their actual work needs, not more, and review that access periodically rather than assuming it’s still correct.

Why account security is repository security

A platform account with write access to a repository is, functionally, a key to that repository. That means account-level security decisions are repository-level security decisions:

• Two-factor authentication, covered in Lesson 1, on every account with any write access, no exceptions for “trusted” people.
• Personal access tokens (PATs) instead of your actual password for command-line or API access, so a leaked token can be revoked individually without changing your main credentials, and so you can scope a token to only the permissions it actually needs, with an expiry date instead of forever.
• The real lesson underneath all of this: a compromised maintainer account is effectively a compromised project, because every push made under that identity is trusted by everyone who pulls from it. This is exactly the mechanism behind a real category of modern security incident, an attacker who steals one maintainer’s credentials and uses them to push a tampered update that everyone downstream trusts by default.

Secrets belong in the platform’s secret store, never in code

This continues directly from Git Fundamentals Lesson 5. On GitHub, repository or organization Settings → Secrets and variables → Actions lets you store values like API keys, injected into CI runs at execution time, never written into the repository itself. GitLab’s equivalent is Settings → CI/CD → Variables. Either way, the rule is the same one from before: if a secret ever leaks into a repository’s history, public or private, deleting the file afterward does not undo the leak. The actual fix is rotating or revoking that credential immediately, the moment you know it was exposed.

Take a look, read-only, at your own practice repository’s secrets settings page now, just to know where it lives for when you actually need it.

What to notice

• Access levels exist so you can give people exactly the access their work needs, not the most convenient blanket option.
• One compromised maintainer account is, in practical terms, one compromised project, because everything pushed under that account is trusted downstream by default.
• A platform’s secrets store exists specifically so a credential never has to appear in code at all, the strongest version of the .gitignore habit from the previous track.