Organizations, Teams, Roles, Repository Access, Enterprise Policies, and Delegated Administration: Configuration, Design Choices, and Tradeoffs

1. Configuration is an authorization architecture

The goal is not to minimize the number of settings. It is to make the answer to “why can this identity do this?” short, durable, and reviewable. Prefer a small number of job-function teams, a conservative base permission, narrow delegated roles, and explicit exceptions with expiry.

2. Direct collaborator grants versus team-based access

Team-based access is normally the maintainable default. Direct grants are not inherently insecure; their problem is lifecycle drift. Every direct grant should answer who approved it, why it exists, and when it expires.

3. Base permission and default-deny strategy

For private-repository estates, None base permission plus explicit teams is the cleanest default-deny pattern. Read base permission can be reasonable for highly collaborative organizations where every member should read every private repository. Write as a base permission usually creates a large blast radius because every member can modify every repository unless another control intervenes.

Base permission applies to organization members, not outside collaborators, and higher explicit grants override a lower base. Internal repositories are an enterprise visibility exception: enterprise members have broad read visibility by design. Treat repository visibility selection as part of authorization architecture, not merely confidentiality labeling.

4. Organization owner versus delegated/predefined/custom role

Owner is appropriate for organization lifecycle, high-impact policy, and continuity—not ordinary CI, security triage, app management, billing, or team administration. Current GitHub provides predefined organization roles for specialist duties. Use those where they fit. Enterprise Cloud adds custom organization and custom repository roles for narrower permission sets; enterprise-level custom roles are also evolving and some are public preview.

5. Outside collaborator versus member versus managed user

Choose member when the person participates in organization teams and recurring organization workflows. Choose an outside collaborator for narrow ordinary GitHub.com repository access without organization membership. Outside collaborators cannot join teams and are not subject to base permission. Under Enterprise Managed Users, use the enterprise's managed identity model: repository collaborator/guest collaborator behavior replaces ordinary external-account assumptions, and provisioning/authentication come from the IdP.

Do not use “machine member” as a substitute for proper GitHub App/service identity. Chapter 27 showed why application identity should be separated from human organization membership whenever the integration model supports it.

6. Organization settings versus enterprise policy

An organization owner may be unable to change a setting because the enterprise has enforced a policy. That is not a repository-role problem. Diagnose hierarchy: enterprise → organization → repository/team. Record whether a control is locally configurable, inherited, or locked. With SAML/SCIM/team synchronization, also record whether GitHub or the IdP is authoritative for membership.

GitHub Enterprise Server is a separate deployment with version-specific role/features. Do not copy GitHub.com Enterprise Cloud custom-role assumptions into an older GHES deployment without checking its versioned documentation.

7. Break-glass and time-bound elevation

A break-glass path should be more controlled than routine access, not less. Define eligibility, approver, exact role, exact repositories, start time, expiry, incident/ticket reference, and post-use review. Prefer a dedicated elevation team or role over temporarily granting organization ownership. Remove elevation automatically where your identity/governance tooling supports it and independently verify the removal.

8. Worked decision table: three teams, three repositories

9. A compact governance policy

Access principles
1. Base permission: None for private repositories unless documented otherwise.
2. Persistent repository access is team-based; direct grants require owner + expiry.
3. Organization owners: minimum continuity set only; no routine task should require owner.
4. Nested parent teams receive only permissions safe for every descendant.
5. Temporary elevation has ticket, approver, start, expiry, and verification of removal.
6. Offboarding enumerates identity, org membership, every team, direct grant, role, and credential owner.
7. Quarterly review records grant source, business owner, last review, and next expiry/review.
8. Enterprise/IdP-enforced controls are labeled as inherited and changed at the authoritative layer.

Knowledge check

Summary

Good governance favors team-based persistent access, conservative base permission, narrowly delegated administration, and explicit exception lifecycle. Organization owner is a continuity/high-impact role, not the default administrator role. Enterprise Cloud custom roles and managed identities can improve delegation, but the mandatory operating model remains valid without paid features.

Official references

• Roles in an organization
• Managing repository roles
• About organization teams
• Setting base permissions
• Managing custom organization roles
• Repository visibility and internal repositories
• Managed user account abilities and restrictions