GitHub Enterprise security best practices

We want to free up your administrator’s time by providing a tool that requires little maintenance and great out-of-the-box security. By following a few simple steps, GitHub Enterprise can be ready for your developers to test the same day it you install it.

Sometimes in the excitement to get up and running, it is easy to pass over simple solutions for security. This post will guide you through some of the settings GitHub Enterprise provides to ensure your company’s installation is secure without inhibiting collaboration. We will also discuss monitoring and auditing tools that give greater insight into the health and security of your installation.

Initial instance setup

Instance password

The password for the Enterprise Management Console, as shown in step #8 of this guide, is the main gateway to administer GitHub Enterprise. This shared password gives a user unfettered access to the GitHub Enterprise environment, so we recommend that you only share it with a select few individuals and save it in an encrypted vault such as 1Password or a similar password management tool. Using this password, you can establish SSH keys through the /setup page in GitHub Enterprise. After setting up a key, an administrator can SSH into the GitHub Enterprise instance and gain access to all the ghe- command line utilities available.

Private Mode

In the /setup page of GitHub Enterprise you will find a setting that enables Private Mode. With this setting enabled, GitHub Enterprise hides all content from users who are not authenticated, including public repositories.

Enabling Private Mode is required for GitHub Enterprise instances that are accessible to users outside of the firewall without a VPN. This helps to ensure a user does not inadvertently make a repository public externally that should remain private within a company.

If your GitHub Enterprise install is only available from a VPN outside of your firewall Private Mode does not need to be turned on. This lets unauthenticated people within the firewall view public repositories and public GitHub Pages.

Subdomain isolation

We strongly recommend that everyone turn on subdomain isolation for their GitHub Enterprise instance. Subdomain isolation securely separates user-supplied content from other portions of your GitHub Enterprise appliance, which mitigates cross-site scripting and other related vulnerabilities. You can make these changes by creating a wildcard DNS entry or by whitelisting each subdomain individually. A full list of these subdomains is available in the link above.

Improved monitoring

If you navigate to the /setup/monitor page in GitHub Enterprise you will notice GitHub Enterprise now ships (as of Enterprise version 2.3) with more graphs to monitor activity on the instance. This permits an administrator to spot suspicious activity and maintain stability in the environment.

Another feature that helps you keep GitHub Enterprise secure is the audit log, which is available at the /stafftools/audit_log endpoint. It records actions that are occurring and makes them visible to a site administrator. These audit logs reveal what action occurred (for instance, a user login), who performed the action, and the IP address of the request. This gives you great visibility into what is happening on an instance level.

Authentication

Certain authentication methods provide additional levels of security and control. Two we’ll highlight here are restricted user groups and universal two-factor authentication.

Restricted user groups

Both LDAP Sync and SAML with Okta allow GitHub Enterprise administrators to segment users and fine-tune control of GitHub Enterprise. In addition to securing your instance, these tools let you control the number of licensed seats in use at any given time.

LDAP Sync permits an administrator to set up a Restricted Group (in Active Directory, for example) that limits access to GitHub Enterprise to only users found in that group.

SAML with Okta lets an administrator control access to GitHub Enterprise by setting it up as an “application” and assigning users to that application to give them access.

With fine tuned controls over who can access the instance, and great reporting from those tools about group membership, an administrator can feel confident in both controlling and monitoring access.

Universal second factor authentication

In partnership with Yubico, GitHub also supports Universal Second Factor Authentication (U2F). If you are not using GitHub’s built in authentication in your instance, however, your identity management provider must provide U2F.

We strongly encourage companies and individuals to reach out to their identity providers and request support for U2F if it is not yet supported.

Organizational security options

GitHub’s revamped organizations and teams are another way to secure your GitHub Enterprise installation. Administrators of GitHub Enterprise will now have the ability to set access levels for a team on a per repository basis. This granularity will reduce the number of teams that administrators must set up and maintain.

Any questions, don’t hesitate to reach out

If you are administering GitHub Enterprise for your team, putting these best practices into play is a great step toward ensuring that your instance stays healthy, secure, and as easy to maintain as it was to install. For a deeper dive into securing your GitHub Enterprise installation, check out this recording from GitHub Universe.

If you have any questions about securing your GitHub Enterprise installation you can reach out to enterprise@github.com to get clarifications or help.

The GitHub Services team is happy to help get you up and running with GitHub Enterprise. We can help you get GitHub Enterprise deployed quickly while following the best practices for security, availability and redundancy. If you would like to learn more about how we can help, don’t hesitate to reach out to services@github.com.

Written by

Matt Duff

@mattcantstop