Contact UsTry it for free
© 2026 Direct Cursus Technology L.L.C.

Configuring security groups

Written by
Updated at May 7, 2026

Security groups and Managed Service for GitLab instance access restrictions

Security group rules determine the following:

Warning

The security group's setup determines the Managed Service for GitLab instance performance and availability.

To set up a security group for a Managed Service for GitLab instance:

  1. Add rules for incoming and outgoing traffic to an existing security group or create a new group with such rules.
  2. Apply the security group to the GitLab instance when creating or updating it.

If you do not assign a separate security group to your instance, the default security group of its network will apply. The rules of this security group added for other services affect access to the GitLab instance.

If you have issues with setting up a security group, contact support.

Rules for incoming traffic

Rule purpose

Rule settings

For accessing Git repositories over SSH

  • Port range: 22 and 2222. Create a separate rule for each port.

  • Protocol: TCP.

  • Source: CIDR.

  • CIDR blocks: Specify IP address ranges of subnets in Yandex Cloud or public IP addresses of internet hosts to enable access from subnets and computers. Here are some examples:

    • 172.16.0.0/12
    • 85.32.32.22/32

    To allow all traffic from any IP address, specify 0.0.0.0/0.

For accessing Git repositories over HTTPS.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: Specify IP address ranges of subnets in Yandex Cloud or public IP addresses of internet hosts to enable access from subnets and computers.

For enabling Let’s Encrypt certificate.

This certificate is used by default when accessing Git repositories over HTTPS. If you do not specify this rule, add your own certificate to work over HTTPS.
  • Port range: 80 and 443. Create a separate rule for each port.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: 0.0.0.0/0.

For creating instance backups.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: 213.180.193.243/32.

For health checks by a network load balancer
  • Port range: 80.
  • Protocol: TCP.
  • Source: Load balancer healthchecks.

For connecting to GitLab Container Registry.

  • Port range: 5050.

  • Protocol: TCP.

  • Source: CIDR.

  • CIDR blocks: Specify IP address ranges of subnets in Yandex Cloud or public IP addresses of internet hosts to enable access from subnets and computers.

    To allow all traffic from any IP address, specify 0.0.0.0/0.

Rules for outgoing traffic

Managed Service for GitLab relies on third-party integrations. If you limit the outgoing traffic in the instance's security group, the instance may work incorrectly. To avoid this, add the following rules to the security group:

Rule purpose

Rule settings

For enabling Let’s Encrypt certificate.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: 0.0.0.0/0.

For creating instance backups.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: 213.180.193.243/32.

For requests to the metadata service when updating an instance.
  • Port range: 80.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: 169.254.169.254/32.

For requests to the DNS service.

  • Port range: 53.

  • Protocol: UDP.

  • Source: CIDR.

  • CIDR blocks — <second_IP_address_in_subnet>/32. For example, for the 10.128.0.0/24 subnet, this will be the 10.128.0.2/32 CIDR.

    If your subnet has a dedicated DNS server, allow outgoing traffic to it, e.g., DNS_server_IP_address/32.

For requests to NTP servers to support two-factor authentication.
  • Port range: 123.
  • Protocol: UDP.
  • Source: CIDR.
  • CIDR blocks: 0.0.0.0/0.

For accessing workers managed by a runner created via the management console.
  • Port range: 22.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: CIDR of the subnet containing the Managed Service for GitLab instance (and hosting the workers), e.g., 10.128.0.0/24.

Security groups for a managed runner

To set up networking between GitLab and managed runners, you need to configure required, recommended, and optional security group settings.

Rules for incoming traffic

Rule purpose

Rule settings

To manage the runner from the GitLab instance over SSH.
This is a required rule.
  • Port range: 22.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: CIDRs of all subnets where runners may run.
    Instead of a CIDR, you can specify a security group created for runners.

Rules for outgoing traffic

Rule purpose

Rule settings

To access the GitLab instance's public address over HTTPS, e.g., for cloning repositories or downloading artifacts.
This is a required rule.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: public GitLab address.

To access the artifact registry, e.g., Cloud Registry or dockerhub.io.
This is a recommended rule.
  • Port range: 443, 5000, or other.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: CIDRs of the registries to which access is granted. To allow traffic to any IP addresses, specify 0.0.0.0/0.

To access object storages, e.g., LFS or Container Registry.
This is a recommended rule.
  • Port range: 443.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: CIDRs of the object storages to which access is granted. To allow traffic to any IP addresses, specify 0.0.0.0/0.

To access external resources.
This is an optional rule.
  • Port range: 443, 80, or other.
  • Protocol: TCP.
  • Source: CIDR.
  • CIDR blocks: CIDRs of external resources.
    If the list of resources is not defined, you can allow outgoing traffic to any addresses (the 0.0.0.0/0 CIDR) on all ports. In this case, you can skip configuring the recommended rules and access from a managed runner to the GitLab instance's public address.
Previous
Creating and activating an instance
Next
Stopping and starting an instance