Security in Managed Service for GitLab

Detecting vulnerabilities in CI/CDDetecting vulnerabilities in CI/CD

Managed Service for GitLab uses GitLab’s built-in tools to protect your pipelines.

The available tools depend on your GitLab license type. The free license offers several security tools, such as Static Application Security Testing (SAST) and Secret Detection. You can also develop custom jobs using open-source tools.

See the table below for a complete list of pipeline security tools by license type:

Pipeline security tools	Free	Premium	Ultimate
API Fuzzing
Cluster Image Scanning
Container Scanning
Dependency Scanning
Dynamic Application Security Testing (DAST)
License Compliance
Secret Detection
Security Dashboard
Static Application Security Testing (SAST)

As Managed Service for GitLab evolves, the tool list may change.

Use of pipeline security examplesUse of pipeline security examples

You can integrate a pipeline into your projects in the following ways:

• Create a pipeline in an individual project and add it to other projects using the include function. This option is available for all license types.
• Use the Compliance framework and pipeline mechanism. You can apply it to any of the group's projects. It is available for the Ultimate license.
• Copy the pipeline sections to the .gitlab-ci.yml files in your projects.

Additional resourcesAdditional resources

Check out the pipeline security examples prepared as part of Yandex Cloud Security Solution Library:

• Detecting vulnerabilities in CI/CD (Ultimate license).
• Detecting vulnerabilities in CI/CD (Free license).

Best practices for GitLab instance security configurationBest practices for GitLab instance security configuration

Use these recommendations to ensure security of your GitLab instance:

• For audit and analysis of security events, configure export of audit logs to a third-party event analysis system, e.g., Splunk.
• Sign your commits using a GPG key.
• Ensure that at least two team members approve code changes. This will help reduce the number of errors.
• To prevent denial of service, use the User and IP rate limits limitations.

Working with Docker from inside GitLabWorking with Docker from inside GitLab

• Review the best practices of secure use of Docker images.
• Work with Docker in non-privileged mode. Use the cap_add and cap_drop settings to fine-tune the setup of container privileges.
• Use kaniko for secure container builds.
• Do not use Shell executor, Docker-in-Docker, and Docker socket binding: this provides access to Docker socket and privileged mode. For more information, see Securing GitLab CI pipelines with Sysbox.

Use casesUse cases

• Storing Docker images in Yandex Container Registry

Integration with Yandex Managed Service for KubernetesIntegration with Yandex Managed Service for Kubernetes

• For secure integration, use GitLab Agent for Kubernetes.
• Do not use certificate-based integration to prevent using service accounts with the cluster-admin role and exposing the Kubernetes API to the internet.
• To prevent tight coupling between GitLab Runner and Kubernetes, use deployment via a CI/CD tunnel.

Use casesUse cases

• Continuous deployment of containerized Managed Service for Kubernetes applications

Using variablesUsing variables

• Use the Protect variable setting to restrict access to variables.
• Use the Mask variable setting to mask variables in logs.
• Do not store secrets, such as keys, passwords, and API tokens, in code. Use Secret Scanning to detect secrets in your code.

Access controlAccess control

• Grant access to your projects only to a limited number of team members. Follow the principle of least privilege when granting access.
• Use GitLab groups to configure project access.
• Restrict project access to specific IP addresses and enable two-factor authentication. To do this, go to Settings → General → Permissions, LFS, 2FA in the target group's settings.
• To grant your organization's users access to projects, configure SAML SSO.
• If possible, disable the use of fork.

Secure GitLab Runner configurationSecure GitLab Runner configuration

• Use the most isolated and secure Docker and Kubernetes executors. We do not recommend using the deprecated Shell executor.
• To restrict network access to GitLab Runner, use security groups.
• Assign service accounts to a virtual machine to securely work with cloud APIs within jobs. This approach is more secure than providing credentials via env.

Use casesUse cases

• Deploying GitLab Runner on a Yandex Compute Cloud virtual machine