Organization and Team Insights

README.md

Recommendation

1. Keep as few organizations as absolutely needed
2. Leverage teams and repository visibility to balance collaboration versus the need for barriers
3. Be very intentional where you want barriers, talk with your teams so they understand what they won't have access to

Deeper Dive

From GitHub guide to organizations:

Pro tips for configuring Organizations on GitHub Enterprise

HAVE AS FEW ORGANIZATIONS AS POSSIBLE TO AVOID CHALLENGING SITUATIONS IN THE FUTURE.

This makes discoverability easier and decreases administrative headaches. Instead of managing permissions across many Organizations, having one or few Organizations can help you build a cohesive and nimble permissions strategy.

TEAMS ARE THE BEST WAY TO GROUP USERS AND PROVIDE ACCESS TO REPOSITORIES.

Teams allow you to create groups with separate levels of access and visibility within an Organization. Relying on Teams as opposed to Organizations can help increase collaboration without compromising access controls.

Starting from there, I'll dove tail into a little more detail we would get into if we were doing an Admin Training offering, which is that you have multiple varieties of teams in a single org to accommodate permissions, discussions, and collaboration:

Teams are most effective when they look like trees with specialized permissions and discussions occurring at the leaves.

There are several types of teams and all of them have a use:

• organizational structure
• roles (broad groups for discussion and perhaps permissions if internal visibility not used)
• product alignment (aggregation of development, operations, project managers, program managers, product managers, marketing, etc that cuts across organizational and role based teams)
• areas of interest (Java, Ansible, Kubernetes, React, etc)

For the areas where you do want cross-organizational collaboration, this is where leveraging internal visibility for repositories can allow teams to share knowledge and avoid duplicate efforts while private repositories allow you to scope access based on teams that need to know.

Understanding costs and concerns around organizations #

GitHub strives to provide various levels of out-of-the-box management capabilities for enterprises. For every capability that is not managed at the enterprise level, enterprise and organization owners take on additional efforts to enforce and review them.

Organizations are intended to create intentional barriers around concerns as only organization members can see or maintain repositories outside of internal repositories. This creates silos and prevents awareness and learning opportunities, which might be necessary for security incidents or highly confidential legal and financial efforts.

Native management capability matrix #

Capability \ Mgmt	Enterprise	Organization	Repository	Additional
Verified domain	✅	✅
SAML SSO	✅	✅		Considerations
Repository base permissions policy	✅	✅
Repository creation policy	✅	✅
Repository forking policy	✅	✅
Repository outside collaborators policy	✅	✅
Repository default branch name policy	✅	✅
Repository visibility policy	✅	✅
Repository deletion and transfer policy	✅	✅
Repository issue deletion policy	✅	✅
Allowed IPs	✅	✅
Two-factor authentication	✅	✅
Billing manager role	✅	✅		Considerations
Audit log streaming	✅
Team creation policy		✅
Manage GitHub Apps		✅
Custom repository roles		✅
Manage GitHub Actions	✅	✅	✅
Repository security & analysis policy		✅	✅
Secret scanning custom patterns	✅	✅	✅

Third-party management solutions #

Enterprises often want to manage more regarding GitHub than we natively support, which is where 2nd and 3rd party solutions for additional capabilities are important to understand:

• Manage repository settings across an organization https://github.com/github/safe-settings

• Capture policies around GitHub Advanced Security and supply chain concerns with a variety of actions https://github.com/GeekMasher/advanced-security-compliance

• Manage various GitHub resources via Terraform https://registry.terraform.io/providers/integrations/github/

Considerations

SAML #

From "Switching your SAML configuration from an organization to an enterprise account":

There are special considerations when enabling SAML SSO for your enterprise account if any of the organizations owned by the enterprise account are already configured to use SAML SSO.

1. When you configure SAML SSO at the organization level, each organization must be configured with a unique SSO tenant in your IdP, which means that your members will be associated with a unique SAML identity record for each organization they have successfully authenticated with. If you configure SAML SSO for your enterprise account instead, each enterprise member will have one SAML identity that is used for all organizations owned by the enterprise account.

2. SCIM provisioning is not currently supported when SAML SSO is configured for an enterprise account. If you are currently using SCIM for an organization owned by your enterprise account, you will lose this functionality when switching to an enterprise-level configuration.

This means additional overhead for managing access with every organization created.

Billing Manager #

From "Inviting a billing manager"

Note: If your organization is owned by an enterprise account, you cannot invite billing managers at the organization level. For more information, see "About enterprise accounts."

This means that all licensing and subscription service usage can only be managed at the enterprise-level.