[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for GitLab](../index.md) > [Step-by-step guides](index.md) > Configuring security groups

# Configuring security groups

## Security groups and Managed Service for GitLab instance access restrictions {#sg-instance}

[Security group](../../vpc/concepts/security-groups.md) rules determine the following:

* IP addresses that can access the instance, including web access.
* Protocol for working with Git repositories in the GitLab instance: SSH or HTTPS.
* Certificate for HTTPS: [Let's Encrypt](https://docs.gitlab.com/omnibus/settings/ssl/#enable-the-lets-encrypt-integration) (default) or your own certificate (by submitting a request to [support](https://center.yandex.cloud/support)).
* Whether or not access to [GitLab Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/) is provided.

{% note warning %}

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

{% endnote %}

To set up a security group for a Managed Service for GitLab instance:
1. [Add](../../vpc/operations/security-group-add-rule.md) rules for [incoming](#ingress-rules-instance) and [outgoing](#egress-rules-instance) traffic to an existing security group or [create](../../vpc/operations/security-group-create.md) a new group with such rules.
1. Apply the security group to the GitLab instance when [creating](instance/instance-create.md) or [updating](instance/instance-update.md) 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](https://center.yandex.cloud/support).

### Rules for incoming traffic {#ingress-rules-instance}

#|
|| **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](https://docs.gitlab.com/omnibus/settings/ssl/#enable-the-lets-encrypt-integration) when accessing Git repositories over HTTPS. If you do not specify this rule, add your own certificate to work over HTTPS. To configure it, contact [support](https://center.yandex.cloud/support). |
* Port range: `80`.
* 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](../../network-load-balancer/concepts/health-check.md) 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 {#egress-rules-instance}

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](../../compute/concepts/vm-metadata.md) 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](../tutorials/install-gitlab-runner.md#create-runner). |
* 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 {#sg-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 {#ingress-rules-runner}

#|
|| **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 {#egress-rules-runner}

#|
|| **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.
||
|#