In this blog post, I'll go over the different ways to ensure separation of duties and continuous compliance with the GitLab DevOps platform. But first, let's level-set on two key concepts:
Compliance means being in accordance with guidelines and specifications that have been defined either by your corporation or a regulatory agency. Compliance helps maintain corporate ethics, appropriate user policies, security standards, and much more for the safety of consumers.
Non-compliance may result in a bundle of legal fees and fines, so it is very important to maintain compliance. While maintaining compliance, DevOps teams must also ensure sustained development velocity, providing necessary simplicity, visibility, and control.
Separation of duties requires multiple actors to complete a task to increase protection from error as well as prevent malicious activity. Separation of duties ensures roles best-suited for the job are the only ones that can perform it. As an example, some of the following actors are observed, each with a specific purpose:
- a developer will be responsible for developing new features
- a compliance officer will be responsible for creating and enforcing the usage of a pipeline
- an appSec engineer will be responsible for approving merge requests with vulnerabilities
Considering the above roles, we can ensure that a developer cannot change a running pipeline. This is a task that can only be performed by a compliance officer, ensuring only compliant code can be pushed without approval.
An appsec engineer is responsible for reviewing and approving code with vulnerabilities, ensuring proper mitigation can be performed, and that nothing comes as a surprise in the future. In this scenario, developers can't merge code until compliance and security requirements are met.
Compliance pipelines
It is important for compliance teams to be confident that their controls and requirements are set up correctly, but also that they stay set up correctly. To obtain this confidence, compliance pipelines can be configured.
Compliance pipelines allow group owners to define a compliance pipeline in a separate repository that gets executed in place of the local projects gitlab-ci.yml file. These pipelines can be set up in a few simple steps:
1. Create a project containing the CI files you would like to run. Make sure that only the security team and/or administator has access to ensure separation of duties. I created the Compliance and Deploy project, which contains the yamls I wish to enforce.
2. Create a compliance framework label to identify that your project has certain compliance requirements and needs additional oversight. This label can be created in Settings > General > Compliance Frameworks under your top-level group.
Note: Compliance labels can only be assigned to projects within the top-level group in which we create the label.
3. Within that framework, point to a compliance pipeline you wish to run, which is located in the project created in Step 1. Regardless of the CI file in a project, if the project is assigned a label, the defined pipeline will always run.
4. Assign the compliance label to a project within your top-level group. This can be done in Settings > General > Compliance Frameworks of the project on which you want to enforce compliance.
5. Run the pipeline
Now you can see that the pipeline is running the GitLab YAML from the Compliance and Deploy project. This can be seen in my Hypnotherapy Services project.
Security policies
GitLab provides Security Policies, which enable security teams to require security scans to run according to a configuration. This provides the security teams with confidence that the configured scans have not been changed or disabled.
There are two types of policies, Scan Execuition Policies and Scan Result Policies.
- Scan Execution Policies: Require that security scans run on a specified schedule or with the project pipeline
- Scan Result Policies: Take action based on scan results, such as requiring approval from the security team before a merge can occur
To take a quick view of the feature, see my explanation in the GitLab 14.8 Security Features video. These policies can be configured via the Policy Editor in a few simple steps:
