What's changed: New GH-100 Chapter 1 (user identities & auth = managed users (EMU) vs personal accounts, SAML SSO/2FA, SCIM and team sync, identity providers, auth model; access & permissions = org/repo roles [Read/Triage/Write/Maintain/Admin/custom], enterprise teams and nested inheritance, team-based least privilege, access auditing and audit log, policies and ruleset enforcement)
1.2Managing Access and Permissions
Understand organization and repository roles, defining/managing enterprise teams, auditing access and permissions, and managing settings/policies/rulesets/roles—governing access along least-privilege principles.
After authentication confirms "who," next is governing "what they can access and do"—authorization. GitHub manages access via hierarchical roles (enterprise → organization → repository/team), granting only the needed scope along least privilege.
1.2.1Organization and repository roles
Organization roles include the owner (governs the whole org), regular members, and carved-out roles like security manager. Repository roles are access levels per repo—Read / Triage / Write / Maintain / Admin—plus custom repository roles for fine-grained permissions. Assigning roles to teams and managing permissions by team (not by individual) is more robust to moves/offboarding and easier to audit. The principle is granting "the minimum role the duty needs."
1.2.2Enterprise teams
A team groups members to assign repository access and review duties. Enterprise teams are a higher-level team concept that manage membership/access across multiple organizations, used for cross-cutting group management in large enterprises. Teams can be nested (parent/child), with child teams inheriting the parent’s permissions. Combined with IdP team synchronization (prior section), group management can be centralized in the IdP.
1.2.3Access auditing and policies/rulesets
Audit who holds which access regularly—find excessive or stale permissions and keep least privilege. The audit log tracks "who changed what, when." Org/enterprise policies govern what members can do (repo creation, visibility, forking, Actions usage), and rulesets enforce branch protection, required reviews, required status checks, etc. Combine roles, policies, and rulesets for consistent access and guardrails.
Common: (1) Repo roles = Read/Triage/Write/Maintain/Admin + custom roles; manage permissions by team (least privilege). (2) Org roles = owner/member/security manager. (3) Enterprise teams span multiple orgs; teams nest and inherit. (4) Regularly audit access + audit log; policies govern member capabilities; rulesets enforce branch protection/required reviews, etc.
Watch out: (1) Per-individual grants don’t scale—manage by team. (2) Owner is powerful—grant sparingly. (3) Policies (what members can do) and rulesets (guardrails on code changes) are different layers. (4) Don’t confuse enterprise teams (cross-org) with in-org teams. (5) Audit regularly, not once.
1.2.4Section summary
- Repo roles = Read/Triage/Write/Maintain/Admin + custom; manage by team (least privilege)
- Org roles = owner/member/security manager; enterprise teams span orgs; teams nest and inherit
- Audit access regularly + audit log; policies govern member capabilities
- Rulesets enforce branch protection/required reviews/checks (a separate layer from policies)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. In a large org, what best manages access robustly against moves/offboarding and eases auditing?
Q2. Which correctly lists GitHub repository role levels?
Q3. Which higher-level team concept manages membership/access across multiple organizations?
Q4. You want to enforce branch protection, required reviews, and required status checks org-wide. What do you use?
Q5. To keep least privilege, what should you do regularly for access management?
Q6. Which is correct about the organization "Owner" role?