Skip to content

Instantly share code, notes, and snippets.

@andyfeller
Created February 23, 2023 12:48
Show Gist options
  • Save andyfeller/c1490b3e0ae18ea21d3eed3d49903846 to your computer and use it in GitHub Desktop.
Save andyfeller/c1490b3e0ae18ea21d3eed3d49903846 to your computer and use it in GitHub Desktop.
Organization and Team Insights

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:

Screen Shot 2022-04-20 at 8 30 12 AM

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

Screen Shot 2022-04-20 at 8 29 11 AM

Screen Shot 2022-04-20 at 8 29 27 AM

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)

Screen Shot 2022-04-20 at 8 29 33 AM

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:

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.
  1. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment