Cyber Compliance
Introduction
This document outlines the Platform One repository requirements for IL2/IL4/IL5 gitlab repository structure to create pipelines for deployment to staging and production environments.
Project Visibility Requirements
All projects should be set to Internal or Private. Either Internal or Private are acceptable at Platform One, with preference to Internal if you don't mind sharing.
You can ready more about GitLab Visibility Settings.
These settings prevent projects from discovery via your favorite search engine. Public projects can also be cloned without Authenticating over HTTPS, which is not good.
If you want to share internally, internal projects can be seen and cloned by any Authenticated Users, and Private Repos can only be viewed/cloned by project members if you don't want to share. Personal Private Repos under user namespace are not allowed.
INFO
By default, all Gitlab groups created for each team, are set to a Private visibility level. The Private visibility level cascades to the projects created under the Gitlab group.
Master Branch Requirements
Master branch protection and role enforcement are cybersecurity best practices to enforce code validation and pushes to the master branch.
By default, defining branches as protected provides the following features:
- Prevents its creation, if not already created, from everybody except users with Maintainer permission.
- Prevents pushes from everybody except users with Allowed permission.
- Prevents anyone from force pushing to the branch.
- Prevents anyone from deleting the branch.
To ensure the master branch is protected, the following roles are enforced:
- Only Maintainers can merge to master.
- No One can push directly to master.
- For more details, review protected branch GitLab documentation.
- Set manually created branches to protected by navigating to Settings > Repository > Protected Branches.
A branch shows as per below when it is protected.
Repository Requirements
Party Bus assumes there will be a minimum of a frontend project and a backend project for each application. Recommendation is you have a readme file for each application explaining the purpose of each project and your overall application.
Monorepos
Party Bus does not support mono-repos. Each repository may only have one pipeline configuration, one Dockerfile, and one deployment. All code in a repository must be part of the same deployment package. Applications consisting of multiple services must be separated into individual repositories with one service per repository.
Multiple Language Pipelines
Party Bus does not support multi-language repositories. All code in a repository must be the same programming language. and use the same framework. The pipeline templates are set up specifically to build, scan, and deploy one language and framework.
Repository Clean-up
Repositories must only contain code to be deployed. Along with the mono-repo and multiple-language requirements, extraneous code or scripts not used for local development or deployment must be removed. Terraform scripts, kubernetes manifests, and other unrelated code must be removed.
Example Project Structure
The project structure of group/sub group/project is required. A Platform One DevOps will create your initial Gitlab Group and assign a team owner at the level. That team owner controls future access at the gitlab group, sub group or project level.
Example of a team with multiple applications:
Multiple examples of gitlab group/subgroup/project structures:
Pipelines
Pipelines are created and managed by Mission DevOps (MDO) team. Open a Pipeline Request ticket if you would like a Pipeline set up.
No
gitlab-ci.yamlallowed.a. Why? Pipelines are setup only by the Mission DevOps team to enforce the C-ATO Requirements.
b. Why? Implementation of a custom pipeline and bypassing Mission DevOps is a security risk.
c. All settings normally in the gitlab-ci.yaml file are now maintained in pipeline-products (IL4 , IL5 ) and the CI/CD settings.
All pipelines deployed to a Platform One staging or production environment cannot have the giltab feature allow_failures enabled.
a. Why? Per the Platform One Cyber team, we cannot allow Cyber scanning to fail as it poses a risk to our infrastructure and other customers deploying to the environment.
MDO uses templates to define which jobs need to be executed for a pipeline. Each template is language-specific/technology-specific. Pipeline jobs are defined in Pipeline Basics. We support two broad types of pipelines.
Package Pipelines
A package pipeline results in an artifact that is intended to be used by other repos/pipelines as a dependency.
We currently support package pipelines for:
- conan
- go (1.17)
- gradle
- maven
- npm
- pypi
- yarn
Deployment Pipelines
A deployment pipeline results in one Docker image that is deployed to a Platform One cluster. These require a Dockerfile to specify how to create the Docker image.
We currently support deployment pipelines for:
- cpp
- dotnet
- go (1.17)
- gradle
- maven
- npm
- php
- python
- ruby
- yarn
Dockerfiles
IMPORTANT
Dockerfiles MUST be at the root of each project. Each project is deployed and the Dockerfile sets the initial requirements.
Requirements
Product images built in a Party Bus pipeline are required to be built with an approved Iron Bank Hardened Image.
a. Approved images can be found in Registry1 Harbor. or the Container Registry (search for base-image).
b. Never use the :LATEST. Always use a specific : < TAG >.
Dockerfiles are not allowed to contain commands that will modify the base image (e.g., 'yum update,' and 'yum install' are not allowed). Dependencies and config files can be copied into the Docker image, but if a base image does not have the necessary OS-level dependencies then a ticket should be opened to request a custom image.
Base Images:
New Iron Bank Image:
Start with the Iron Bank team to obtain approval for your custom image. An example of a new image would be an image that does not exist in the Iron Bank hardened images repository. Follow instructions on Confluence to request a new Iron Bank Hardened Image.
New Mission DevOps Image:
Images created by the Mission DevOps team are a rare exception. We recommend contacting Iron Bank before requesting a custom image from the Mission DevOps team. Examples of the types of custom images would be add-ons to or a new version of the an existing image. Submit a support ticket to request a modification to an existing image. More detailed information can be found in our Docker articles.