Security in Managed Service for GitLab

Detecting vulnerabilities in CI/CDDetecting vulnerabilities in CI/CD

Managed Service for GitLab offers protection of your pipeline with built-in GitLab tools.

The tools available depend on the 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 for a complete list of pipeline security tools with respective licenses:

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 develops, the 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

See 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).

GitLab instance security setup guidelinesGitLab instance security setup guidelines

Use these sets of 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 commits using a GPG key.
• Arrange for changes in code to be approved (approve) by at least two people. 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 to secure your container building processes.
• 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 the use of service accounts with the cluster-admin role and the opening of the Kubernetes API to the internet.
• To prevent connectivity of GitLab Runner and Kubernetes, deploy using the 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, API tokens, and so on) in the code. To search for secrets in the code, use the Secret Scanning tool.

Access managementAccess management

• Provide access to your projects to a limited number of personnel. Grant employees only the minimum required rights.
• Configure access to projects using GitLab groups.
• Limit project connections only to specific IP addresses and enable two-factor authentication. To do this, go to Settings → General → Permissions, LFS, 2FA in the properties of the appropriate group.
• To grant your company users access to projects, configure SAML SSO.
• If possible, disable the use of fork.

Secure configuration for GitLab RunnerSecure configuration for GitLab Runner

• Use the most isolated and safest Docker and Kubernetes managers. We do not recommend using the obsolete Shell executor.
• To restrict network access to GitLab Runner, use security groups.
• Assign a service account to a virtual machine to interact with the cloud API from inside jobs. This approach is more secure than specifying credentials via env.

Use casesUse cases

• Deploying GitLab Runner on a Yandex Compute Cloud virtual machine