In this chapter, I'll explain some of the basics of the GitHub platform. You'll learn about the different hosting options, pricing, and how you can integrate it into your existing toolchain.
The key topics are as follows:
GitHub has many different licenses and hosting options. It is important to understand them to make the right choice for your enterprise.
GitHub (https://github.com) is hosted in data centers in the United States. You can sign up on GitHub for free and you'll get unlimited private and public repositories for free. Many of the features in GitHub are free for open source projects but not for private repositories.
For enterprises, you have different options to host GitHub (see Figure 20.1):
GitHub Enterprise Cloud (GHEC) is a SaaS offering from GitHub and is completely hosted by GitHub in their cloud infrastructure in the United States. You can apply additional security and support single sign-on for your users. GHEC allows you to host private and public repositories so that you can host open source projects in the context of your enterprise.
GHEC is guaranteeing you an SLA of 99.9% monthly uptime, meaning a maximum downtime of 45 minutes per month.
GitHub Enterprise Server (GHES) is a system that you can host wherever you want. You can host it in your own data center or in a cloud environment such as Azure or AWS. You can use GitHub Connect to connect to GitHub.com – this allows you to share licenses and make use of open source resources on your server.
GHES is based on the same source as GHEC, so eventually, all features will come to the server a few months later. But there are some things provided in the cloud that you must take care of on GHES for yourself, for example, the runners in GitHub Actions. In the cloud you can leverage GitHub hosted runners; on GHES, you must build your own solution using self-hosted runners.
There are also managed services that offer to host GHES for you – for example, in an Azure data center in your region. This way, you have full data residency and don't have to manage the servers by yourself. Some also include offering to host managed GitHub Actions runners.
GitHub is building a service called GitHub Enterprise AE (GHAE). It is currently in private beta for customers with more than 500 seats and there is not yet a date when the service will be available publicly.
GHAE is a completely isolated, managed offering from GitHub in a Microsoft Azure region of your choice. This gives you full data residency and compliance.
For customers that need data residency and compliance, this will be a good option in the future, but for now, it is not clear when it will be available, what the pricing will be, and what the minimum number of seats will be.
The power of GitHub lies in its community and the value the community provides. To be able to leverage this on the server, you can connect your server to GitHub using GitHub Connect. You can activate each feature individually, as you can see in Figure 20.2:
The following is a list of the features:
The cost of GitHub is billed monthly per user, and it is built upon three different tiers, Free, Team, and Enterprise (see Figure 20.3):
Public repositories – and therefore open source – are free and contain a lot of features for free, such as Actions, Packages, and many security features. Private repositories are free with limited functionality and 2,000 Action minutes and 500 MB of storage. The pricing for Actions was covered in depth in Chapter 7, Running Your Workflows.
If you really want to collaborate with GitHub in private repositories, you need at least the Team license. It includes protected branches, code owners, and other advanced pull request features. And you get access to Codespaces, but you must pay for them separately (see Chapter 13, Shift Left Security and DevSecOps, for the pricing of Codespaces). The team tier contains 3,000 Action minutes and 2 GB of storage for packages.
Free and Team are only available on GitHub.com. If you need GHEC, GHES, or GHAE, you must buy the GitHub Enterprise license. This license contains all the Enterprise features, such as single sign-on, user management, auditing, and policies, and it comes with 50,000 Action minutes and 50 GB of storage for packages. It also gives you the option to purchase additional add-ons such as Advanced Security or Premium Support.
Licenses are bought in blocks of 10 and can be paid monthly or yearly. If you want to use GitHub Advances Security or Premium Support, you must talk to the GitHub Sales team or a GitHub partner. They can give you a quote for that.
There are certain things that are paid on a per-use basis in addition to the license tiers, such as the following:
You can configure spending limits on the organization or enterprise level.
Until now, I just assumed that you already have a GitHub account. With over 70 million users, chances are high that you do. If you have one, just skip this section and continue with enterprise security.
Signing up for GitHub is straightforward. It is designed like a wizard that looks like a console. The steps to create a new account are as follows:
Click Continue if you found a unique username.
After you have successfully created your account, there are some steps you should do right away:
$ git config --global user.email <email address>
Your GitHub account is now ready, and you can start creating repositories or contributing to open source projects.
As an enterprise, you can use SAML single sign-on (SSO) with your identity provider (IdP) to protect your GitHub Enterprise resources. SSO can be configured in GHEC at the enterprise and organization levels. In GHES, it can only be configured for the entire server.
SAML SSO can be configured with every IdP that supports SAML – but not all support the System for Cross-domain Identity Management (SCIM). These are compatible: Azure AD (AAD), Okta, and OneLogin.
Configuring SAML SSO in GitHub is straightforward. You can find the corresponding settings in the enterprise or organization settings under Authentication security (/settings/security) | SAML single sign-on. Here, you can find the consumer URL you will need to configure your IdP (see Figure 20.8):
The values for the fields must be configured in your IdP. Check their documentation for more information. In AAD, for example, you can find detailed instructions here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/github-tutorial. You have to create a new Enterprise application in AAD. You can search the templates for GitHub and pick the corresponding one (for enterprise, organization, or server). See Figure 20.9 for the currently available templates:
Assign users or groups to the application that you want to have access to GitHub. The important configuration happens in Set up single sign on (see Figure 20.10):
Use the organization or enterprise URL as the identifier. You can use the first part of the URL you have seen in Figure 20.8, only without /saml/consume. Use this URL as Entity ID. Add /saml/consume for Reply URL and /sso for Sign on URL. The result should look like Figure 20.11:
The attributes and claims can be used to adjust the mappings for the fields in AAD. The default settings should work if your AAD was not customized (see Figure 20.12):
Download the Base64 certificate used to sign the SAML token (see Figure 20.13):
Copy the Login URL and Azure AD Identifier URLs (see Figure 20.14):
You can now head back to GitHub and fill in the data. Then, paste the Login URL information into the Sign on URL field and the Azure AD Identifier URL into the Issuer field. Open the certificate in a text editor and paste the content in the Public certificate field. The result looks like Figure 20.15:
Click Test SAML configuration and log in with your AAD credentials. If everything was successful, you can check Require SAML authentication to enforce the access with SAML. GitHub will then check which users have not been granted access through the IdP and remove them after your confirmation.
Note that only authorized PAT tokens and SSH keys can access content that is protected by SSO. Each user must go to their PAT tokens/SSH keys and authorize them as in the example in Figure 20.16:
Of course, the configuration for every IdP is different, and the values vary slightly depending on whether you configure an enterprise, an organization, or a server. But with the documentation of your IdP, the setup should be straightforward.
If you enable SAML SSO, users will not be automatically deprovisioned when you deactivate a user in your IdP. You can implement SCIM in GHEC to automatically add, manage, and remove access based on the information of your IdP.
SCIM is an API endpoint (see https://docs.github.com/en/enterprise-cloud@latest/rest/reference/scim) that is used by your IdP to manage the users in GitHub. Compatible IdPs are, for example, Azure AD, Okta, and OneLogin. To configure SCIM, you must follow the documentation of your IdP if they are compatible. Here is the tutorial for AAD: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/github-provisioning-tutorial.
Disable Third-Party Access Restrictions
Note that you have to disable third-party access restrictions in the settings of your organization before authorizing your IdP. You can do this under Settings | Third-party access | Disable access restrictions.
If you use SAML SSO on GHEC, you can set up team synchronization to automatically sync team membership with your IdP. Currently, team synchronization only supports AAD and Okta.
You can enable team synchronization in the settings of your organization under Authentication security (/settings/security). There, you can then see how many teams are synchronized and jump to the filtered audit log to see all relevant events (see Figure 20.17):
Once enabled, you can create new teams and select one or more groups from your IdP that get synchronized with your team, as you can see in Figure 20.18:
You can add these teams inside other teams (Parent team), but you cannot sync nested groups to GitHub.
In GHEC, even if you set up SAML SSO for your enterprise or organization, every user still needs a user account on GitHub.com. The GitHub user account is basically the identity of the user, and the SAML authorization is the access granted to certain Enterprise resources. The user could contribute to open source and other organizations using their identity, and must authenticate using SSO to access Enterprise resources. But many organizations don't want that. They want complete control over the identity of their users. The solution for that is Enterprise Managed Users (EMU). With EMU, the identity of users gets completely managed in the IdP. A new user gets created if a user logs in for the first time using the identity from the IdP. This user cannot contribute to open source or be added as an outside collaborator to other repositories. Also, the contributions only count to the profile of that user.
EMU gives your enterprise a lot of control over the identities, but it comes with a lot of restrictions, as shown in the following examples:
These restrictions make a lot of things difficult. One of the main benefits of GitHub is its integration of open source repositories. But if EMU allows you to use the cloud instead of a server instance, it might be worth giving it a shot.
Currently, EMU-supported IdPs are AAD and Okta.
If you want to try EMU, you must contact GitHub's sales team and they will create a new enterprise for you.
To learn more about EMU, see https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/managing-iam-with-enterprise-managed-users/about-enterprise-managed-users.
On the server, things work differently. You can configure SSO for SAML, LDAP, or CAS. The configuration is straightforward and not so different from GHEC. Users do not need a GitHub.com account; they can sign in directly to the server using the IdP, similar to EMU. But if GitHub Connect is configured, users can connect their GitHub account in User Settings | GitHub Connect and share the number of contributions with their public GitHub profile. This way, they can connect multiple corporate identities to their GitHub profile if they choose to do so.
GHEC, as well as GHES, supports audit logging. The log contains log entries for all security-relevant events. Each audit log entry shows applicable information about an event, such as the following:
Figure 20.19 shows a sample audit log in GHEC at the enterprise level. You can search and filter the audit log. You can pick predefined filters and click on the title elements of the log entries to create a filter statement:
On GHEC, you can enable log streaming and configure automatic streaming of all events to one of the following targets:
You can forward the events with Azure Event Hubs to other tools such as Log Analytics or Sentinel.
You can also access the audit log using the audit log API. You can query the audit log using GraphQL or the REST API. The following example shows how you could retrieve all events for a specific date using the REST API:
$ curl -H "Authorization: token TOKEN"
--request GET
"https://api.github.com/enterprises/name/audit-log?phrase=created:2022-01-01&page=1&per_page=100"
For more information about querying audit logs using the API, see https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/using-the-audit-log-api-for-your-enterprise.
One of the big advantages of GitHub is that most developers already know how it works. This means less time for training and onboarding. But, of course, there are still developers that are new to GitHub. GitHub offers the GitHub Learning Lab (https://lab.github.com/) for free. It contains many learning paths that use GitHub issues and a bot to provide you with a hands-on experience to learn GitHub.
There are also many free learning paths available on Microsoft Learn if you prefer this way of learning. Just go to Microsoft Learn and filter by product, GitHub: https://docs.microsoft.com/en-us/learn/browse/?products=github.
In this chapter, you learned about the different pricing and hosting options for GitHub. You learned about enterprise security and how you can integrate GitHub into your enterprise.
In the next chapter, I'll show you how you can migrate from your existing source control system or DevOps solution to GitHub.
Use the following links to get more information on the topics: