debian-mirror-gitlab/doc/user/project/clusters/securing.md

stage	group	info
Defend	Container Security	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers

Securing your deployed applications

GitLab makes it easy to secure applications deployed in connected Kubernetes clusters. You can benefit from the protection of a Web Application Firewall, Network Policies, or even Container Host Security.

This page contains full end-to-end steps and instructions to connect your cluster to GitLab and install these features, whether or not your applications are deployed through GitLab CI/CD. If you use Auto DevOps to build and deploy your application with GitLab, see the documentation for the respective GitLab Managed Applications above.

Overview

At a high level, the required steps include the following:

• Connect the cluster to GitLab.
• Set up one or more runners.
• Set up a cluster management project.
• Install a Web Application Firewall, Network Policies, and/or Container Host Security.
• Install Prometheus to get statistics and metrics in the threat monitoring dashboard.

Requirements

Minimum requirements (depending on the GitLab Manage Application you want to install):

• Your cluster is connected to GitLab (ModSecurity, Cilium, and Falco).
• At least one GitLab Runner is installed (Cilium and Falco only).

Understanding how GitLab Managed Apps are installed

You install GitLab Managed Apps from the GitLab web interface with a one-click setup process. GitLab uses Sidekiq (a background processing service) to facilitate this.

  sequenceDiagram
    autonumber
    GitLab->>+Sidekiq: Install a GitLab Managed App
    Sidekiq->>+Kubernetes: Helm install
    Kubernetes-->>-Sidekiq: Installation complete
    Sidekiq-->>-GitLab: Refresh UI

NOTE: Note: This diagram uses the term Kubernetes for simplicity. In practice, Sidekiq connects to a Helm Tiller daemon running in a pod in the cluster.

Although this installation method is easier because it's a point-and-click action in the user interface, it's inflexible and hard to debug. When something goes wrong, you can't see the deployment logs. The Web Application Firewall feature uses this installation method.

However, the next generation of GitLab Managed Apps V2 (CI/CD-based GitLab Managed Apps) don't use Sidekiq to deploy. All the applications are deployed using a GitLab CI/CD pipeline and therefore GitLab Runners.

sequenceDiagram
  autonumber
  GitLab->>+GitLab: Trigger pipeline
  GitLab->>+Runner: Run deployment job
  Runner->>+Kubernetes: Helm install
  Kubernetes-->>-Runner: Installation is complete
  Runner-->>-GitLab: Report job status and update pipeline

Debugging is easier because you have access to the raw logs of these jobs (the Helm Tiller output is available as an artifact in case of failure) and the flexibility is much better. Since these deployments are only triggered when a pipeline is running (most likely when there's a new commit in the cluster management repository), every action has a paper trail and follows the classic merge request workflow (approvals, merge, deploy). The Network Policy (Cilium) Managed App and Container Host Security (Falco) are deployed with this model.

Connect the cluster to GitLab

To deploy GitLab Managed Apps to your cluster, you must first add your cluster to GitLab. Then install the Web Application Firewall from the project or group Kubernetes page.

Note that your project doesn't have to be hosted or deployed through GitLab. You can manage a cluster independent of the applications that use the cluster.

Set up a GitLab Runner

To install CI/CD-based GitLab Managed Apps, a pipeline using a GitLab Runner must be running in GitLab. You can install a GitLab Runner in the Kubernetes cluster added in the previous step, or use one of the shared runners provided by GitLab if you're using GitLab.com.

With your cluster connected to GitLab and a GitLab Runner in place, you can proceed to the next steps and start installing the Cilium and Falco GitLab Managed Apps to secure your applications hosted on this cluster.

Create a Cluster Management Project

A Cluster Management Project is a GitLab project that contains a .gitlab-ci.yml file to deploy GitLab Managed Apps to your cluster. This project runs the required charts with the Kubernetes cluster-admin privileges.

The creation of this project starts like any other GitLab project. Use an empty project and add a gitlab-ci.yml file at the root, containing this template:

include:
  - template: Managed-Cluster-Applications.gitlab-ci.yml

To make this project a Cluster Management Project, follow these instructions. This project can be designated as such even if your application isn't hosted on GitLab. In this case, create a new empty project where you can select your newly created Cluster Management Project.

Install GitLab Container Network Policy

GitLab Container Network Policy is based on Cilium. To install the Cilium GitLab Managed App, add a .gitlab/managed-apps/config.yaml file to your Cluster Management project:

# possible values are gke, eks or you can leave it blank
clusterType: gke

cilium:
  installed: true

Your application doesn't have to be managed or deployed by GitLab to leverage this feature. Read more about configuring Container Network Policy.

Install GitLab Container Host Security

Similarly, you can install Container Host Security, based on Falco, in your .gitlab/managed-apps/config.yaml:

falco:
  installed: true

[Read more] about configuring Container Host Security.