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.

Pipeline security usage examplesPipeline security usage examples

The following options of pipeline usage are available for your projects:

• Create a pipeline in an individual project and add it to other projects using the include function. Available for all license types.
• Use the Compliance framework and pipeline mechanism. You can run it in any group project. Available for the Ultimate license.
• Copy pipeline sections to the .gitlab-ci.yml file of your projects.

Extra materialsExtra materials

See examples of pipeline security prepared as part of Yandex Cloud Security Solution Library:

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

Recommendations on security settings for a GitLab instanceRecommendations on security settings for a GitLab instance

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.
• Organize the approval of changes to code 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.

Working with Docker from inside GitLabWorking with Docker from inside GitLab

• Review best practices on the secure operation of Docker images.
• Operate Docker in non-privileged mode. Use the cap_add and cap_drop settings to fine-tune the setup of container privileges.
• For building secure containers, use kaniko.
• Do not use Shell executor, Docker-in-Docker, and Docker socket binding because this gives access to Docker socket and privileged mode. For more information, see Securing GitLab CI pipelines with Sysbox.

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

• For secure integration, use GitLab Agent for Kubernetes.
• To make it impossible to use service accounts with the cluster-admin role and open the Kubernetes API to the internet, do not use certificate-based integration.
• To prevent connectivity of GitLab Runner and Kubernetes, deploy using the CI/CD tunnel.

Using variablesUsing variables

• To restrict access to variables, use the Protect variable setting.
• To mask variables in logs, use the Mask variable setting.
• 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 differentiationAccess differentiation

• 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 fork usage.

Secure configuration for GitLab RunnerSecure configuration for GitLab Runner

• Use the most isolated and safest Docker and Kubernetes executors. We do not recommend using the deprecated 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.