Skip to content

Guideline of best practices to follow to configure Github Enterprise Cloud in a secure way.

License

Notifications You must be signed in to change notification settings

dduzgun-security/github-enterprise-cloud-configuration

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

26 Commits
 
 
 
 

Repository files navigation

Contributors Forks Stargazers Issues MIT License


Logo

Github Enterprise Cloud Configuration

Guideline of best practices to follow to configure Github Enterprise Cloud in a secure way.

Report an issue

⚠️ This document is subject to change as the GitHub platform grows with time.

Table of contents

About the project

Looking for a guideline to configure your GitHub Enterprise Cloud in a secure way?

Here is a 🔥 list of things to do!

Enterprise account section

Managing the subscription

View the current subscription, license usage, invoices, payment history, and other billing information for your enterprise account.

Roles for an enterprise account

Enterprise accounts come with a set of administrator roles that you can assign to users of your enterprise. Each administrator role maps to business functions and provides permissions to do specific tasks within the enterprise account.

Manage user SAML access to enterprise account

When you enable SAML single sign-on for your enterprise account, each enterprise member can link their external identity on your identity provider (IdP) to their existing GitHub account. To access each organization's resources on GitHub, the member must have an active SAML session in their browser. To access each organization's protected resources using the API and Git, the member must use a personal access token or SSH key that the member has authorized for use with the organization. Enterprise owners can view and revoke a member's linked identity, active sessions, or authorized credentials at any time.

Adding organizations to the enterprise account

Enterprise owners can create new organizations within an enterprise account's settings.

To add an organization to your enterprise account, you must create the organization from within the enterprise account settings. You cannot transfer existing organizations into an enterprise account.

Enforcing repository management policy

Enterprise owners can enforce certain repository management policies for all organizations owned by an enterprise account, or allow policies to be set in each organization. The policies should respect the repository rules in the repository section bellow.

Enforcing security settings in your enterprise account

Enforce every enterprise account security recommendations listed here.

image

This covers many sections such as

1. Requiring two-factor authentication for organizations in your enterprise account
2. Managing allowed IP addresses for organizations in your enterprise account
3. Enabling SAML single sign-on for organizations in your enterprise account
4. Managing team synchronization for organizations in your enterprise account
5. Managing your enterprise account's SSH certificate authorities

More details can be viewed the organization security section

Organization section

Profile settings

Provide only necessary profile information

Organization display name
Description
URL
Location
Picture
Member privileges
Status Description
Base permissions None Members will only be able to clone and pull public repositories. To give a member additional access, you’ll need to add them to teams or make them collaborators on individual repositories.
Repository creation Internal Members will be able to create private repositories, visible to organization members with permission.
Repository forking Unchecked Refer to the repository forking section.
Actions Enable local Actions for this organization This allows all repositories to execute any Action, whether the code for the Action exists within the same repository, same organization, or a repository owned by a third party.
Repository visibility changes Unchecked Only organization owners can change repository visibilities. Or, repository creation and settings must be done as code via a PR
Repository deletion and transfer Unchecked Only organization owners can delete or transfer repositories. Or, repository creation and settings must be done as code via a PR
Issue deletion Unchecked Only organization owners can delete issues. Or, repository creation and settings must be done as code via a PR
Repository comments Unchecked No real need to see comment author’s profile name in issues and pull requests for private repositories.
Tream creation Unchecked Only organization owners can create new teams. Or, repository creation and settings must be done as code via a PR.
Outsider collaborators Disabled No outsider collaborators should be able to collaborate in the organization.
Billing manager

A billing manager for the organization must be defined.

Organization security
Status Description
Two factor authentication 🔒 Enabled Require two-factor authentication for everyone in the organization.
SAML single sign-on 🔒 Enable Enable SAML authentication for the organization through an identity provider like Azure AD. SSO authentication to GitHub must be from a known internal identity provider.
SSO on access tokens 🔒 Enable Enable SSO for the use of access tokens within the organization.
SSO on SSH keys 🔒 Enable Enable SSO for the use of SSH keys within the organization.
SCIM integration 🔒 Enable With SCIM, administrators can automate the exchange of user identity information between systems to add, manage and remove organization members.
SSH certificate authorities 🔒 Enable Manage the organization SSH CA to require the members to have SSH CA certificates to access organization resources.
Automated security update 🔒 Enable (unchecked) Automatic security checks for dependencies and trigger a pull request in the vulnerable repository with the automated security update feature.
Verify domain

The organization administrator must add the TXT record to our DNS configuration in order to be a Verified Organization Domain in GitHub. This control will also restrict email notifications to an approved domain to prevent information leak

Audit log

The SOC team must be able to use the GitHub audit log API to do further security analysis and investigation on events from the audit log.

Organization webhooks

Every webhooks that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Organization third party access

Every third-party access that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Organization OAuth apps

Every GitHub Oauth apps that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Organization GitHub apps

Every GitHub Apps that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Organization owner

GitHub organization owners account can basically do everything, and this is the reason why we must limit to a max of 3-5 users.

Blocked users

This feature must be called from an API if the SOC team detects strange events going on from a users account. We can block a user from within your organization settings or from a specific comment made by the user.

Terms of service

The Standard Terms of Service is an agreement between GitHub and you as an individual. To enter into an agreement with GitHub on behalf of an entity, such as a company, non-profit, or group, organization owners can upgrade to the Corporate Terms of Service.

User section

User creation

User creation must be done by using the corporate email.

User security

As listed in this README file, follow all the GitHub Account security best practices.

Repository section

Repository creation

The repository creation must be initiated from a pull request.

Once the PR is accepted, it will create a new repository respecting all the rules listed in this section.

Naming convention

Repositories must have an effective naming conventions to help scale the organization for long term.

Microservices

<method>-<project-name>-<communication>-service 
ex: get-authentication-rest-service
ex: post-authorization-grpc-service

Libraries

<project-name>-library
ex: validation-library
ex: error-library
ex: jwt-library
Tagging convention

GitHub repositories must be tagged with the ApplicationID, Technology used and other usefull informations.

Repository template

To have a complete repository standardisation, we must use the created GitHub Template Repository

With templates repositories, we can reuse organization based :

  • README.md files template
  • SECURITY.md files template
  • LICENSE.txt files template
  • CONTRIBUTING.md files template
  • CODEOWNER file template
  • GITIGNORE file template
  • OPENAPI file template

Also, we can use this feature to create basic reusable codegen templates for :

  • Organization base level GitHub Actions
    • Code quality (Codacy, SonarCloud, ...)
    • Dependency checks (Snyk, Dependabot, ...)
    • Secret scanning
    • Docker image security scaning
    • GitHub Package publishing (with versioning)
  • Microservices
  • Libraries
Manage access
Status Description
With teams ✔️ Members are part of teams and every access to repositories must be given with teams.
With individual members Individual members must not be able to be added to repositories. They must be a part of a team.
With outside collaborators 👨‍💻 For open-source projects only, the community must agree the terms and conditions of the company.
Branch protection
Status Description
Branch name master The master branch must always be protected.
Require pull request before merging ✔️ A pull request must absolutely be made before merging to master. No direct push to master must be allowed.
Require 2 approving reviews ✔️ Minimum 2 approved reviews should be passed and for major changes with security modification, a security advisor must be assigned in the pull request.
Require review from Code Owner ✔️ When possible, the code owner must review the pull requests.
Require status check to pass before merging ✔️ The new feature branch must pass all the required checks in order to be merged to master. Otherwise the merge would be impossible in order to protect the master branch.
Require the branch to be up to date before merging ✔️ The branches must be up to date before merging to avoid git conflicts.
Required signed commits ✔️ Only Signed Commits must be allowed. Here is a How-to.
Include restrictions to administrators ✔️ Administrators must not be able to bypass the branch security settings; they need to do pull requests also.
Repository webhook

Every Webhooks that the GitHub repository owners wants to add must be reviewed and approved by the security team.

Repository notification

Every Notifications that the GitHub repository owners wants to add must be reviewed and approved by the security team.

Repository integration and services

⚠️ This section is deprecated, do not use it.

Repository deploy key

Every Deploy Keys that the GitHub repository owners wants to add must be reviewed and approved by the security team. Deploy keys must respect the least privilege principle to access a repository.

Repository autolink references

Every Autolink references that the GitHub repository owners wants to add must be reviewed and approved by the security team.

Repository secrets

GitHub repositories must not have any clear text secrets in the code, the secrets must be in the GitHub Secrets.

We must call HashiCorp Vault to retrieve secrets. To do so, we must use the GitHub Auth Method. Since GitHub is synched to the companies Identity Provider, it can easily and securely become our source of access to HashiCorp Vault. We must therefore ensure that secure HashiCorp Vault Policies are bulletproof.

Security policies and advisories

Repositories must have a GitHub Security Policy document SECURITY.md to give instructions on how to responsibly report a security vulnerability.

GitHub Security Advisories must be used to privately discuss, fix, and publish information about security vulnerabilities.

Security alerts

We must ensure that GitHub Automated Security Alerts is enabled to have less security issues in our code.

Contributing file

We must have a CONTRIBUTING.md file that describes the steps to follow and respect in order to contribute to a project.

README file

Each repository must have a clear README.md file that describes the goal of the repository and helps developers to set up their working environment quickly.

CODEOWNER file

Each repository must have a CODEOWNER file to request reviews to the code owner on pull request.

GITIGNORE file

Each repository must have a GITIGNORE file to ignore sensible information or garbage data generated by IDEs.

LICENSE file

Each repository must have a LICENSE.txt file that is approved by the legal team of the organization. We must have specific licensing rules in repositories (private, public, ...)

GitHub Actions

GitHub Actions must be reusable and bulletproof. Therefore, they should be reviewed by DevOps, CloudOps and SecOps teams.

Actions must ease automation tasks in testing, deployment, security, notification and many other fields.

The template repository must have the base level GitHub Actions set by the organization at each time.

GitHub Packages

We must use as much as possible the GitHub Packages as our code and docker image registry to have an all-in-one tool that requires no external connections to other tools such as Nexus or JFrog.

In order to always have deployed artefact and images that are regulary scanned, we must add restriction in Github Actions when pulling a version of Package that is old. Github Packages 📦 older then 3 months must not be consumed for security reasons.

To re-run the GitHub Actions in order to have a new Github Package version simply push a change in the README.md file that doesn’t affect the code and then the base level action will follow all the security checks.

Repository forking

Members will be able to fork public (open source) repositories. When a member decides to fork a repository, he/she must ensure that he/she will merge his/her changes to the open source project. No sensible information must be in the forked code since repositories that are forked are by default public in GitHub.

Repository duplicating

Members who would like to add sensible data on existing open source projects must duplicate the repository and make it private within the organization instead of forking it.

Open sourcing

Yes! 😎

If the code doesn't leak sensible data and is reviewed by the security team, we strongly encourage you to make it open-source by including the licensing and going through the legal approbations of the organization.

Agility

We strongly encourage teams to use GitHub to work in an agile way. 👍

GitHub API section

GitHub Rest API

GitHub Rest API helps to configure many things in GitHub such as inviting/removing members, creating repositories and more.

GitHub GraphQL API

GitHub GraphQL API is also available and it offers the ability to define pricisely only the required data you want in a single call. It is also very usefull to audit GitHub logs.

⚠️ Keep note of the rate limiting in place when doing HTTP requests.

Compliancy section

No more need to worry about server deployments, updates, availability, hardening or other because with the cloud-hosted GitHub Enterprise Cloud because they handle this part.

Support section

Github Enterprise Support offers very usefull assistance on everything you search. 👍

Also, GitHub offers a Premium Support with a 24/7 hours of operation availability time.

Contributing

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.

  1. Fork the Project
  2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
  3. Commit your Changes (git commit -m 'Add some AmazingFeature')
  4. Push to the Branch (git push origin feature/AmazingFeature)
  5. Open a Pull Request

License

Distributed under the MIT License. See LICENSE.txt for more information.

Contact

Deniz Onur Duzgun
Khalid Nazmus Sakib

About

Guideline of best practices to follow to configure Github Enterprise Cloud in a secure way.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published