GitLab에서 작동하도록 LDAP를 구성한 경우, GitLab은 사용자와 그룹을 자동으로 동기화할 수 있습니다.

LDAP 동기화는 LDAP 신원이 할당된 기존 GitLab 사용자의 사용자 및 그룹 정보를 업데이트합니다. LDAP를 통해 새로운 GitLab 사용자를 생성하지는 않습니다.

동기화가 발생하는 시간을 변경할 수 있습니다.

속도 제한이 있는 LDAP 서버#

일부 LDAP 서버에는 속도 제한이 구성되어 있습니다.

GitLab은 다음 각각에 대해 LDAP 서버에 한 번씩 쿼리합니다:

• 예약된 사용자 동기화 프로세스 중 각 사용자.

• 예약된 그룹 동기화 프로세스 중 각 그룹.

일부 경우에는 LDAP 서버에 더 많은 쿼리가 트리거될 수 있습니다. 예를 들어 그룹 동기화 쿼리가 memberuid 속성을 반환하는 경우가 이에 해당합니다.

LDAP 서버에 속도 제한이 구성되어 있고 해당 제한이 다음 중에 도달하는 경우:

• 사용자 동기화 프로세스 중이면, LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자를 차단합니다.

• 그룹 동기화 프로세스 중이면, LDAP 서버가 오류 코드로 응답하고 GitLab이 해당 사용자의 그룹 멤버십을 제거합니다.

원하지 않는 사용자 차단 및 그룹 멤버십 제거를 방지하려면 LDAP 동기화를 구성할 때 LDAP 서버의 속도 제한을 고려해야 합니다.

사용자 동기화 {#user-sync}#

GitLab은 하루에 한 번 워커를 실행하여 GitLab 사용자를 LDAP와 비교하여 확인하고 업데이트합니다.

이 프로세스는 다음 액세스 검사를 실행합니다:

• 사용자가 여전히 LDAP에 존재하는지 확인합니다.

• LDAP 서버가 Active Directory인 경우, 사용자가 활성 상태인지(차단/비활성화 상태가 아닌지) 확인합니다. 이 검사는 LDAP 구성에서 active_directory: true가 설정된 경우에만 수행됩니다.

Active Directory에서 사용자 계정 제어 속성(userAccountControl:1.2.840.113556.1.4.803)의 비트 2가 설정되어 있으면 사용자가 비활성화/차단된 것으로 표시됩니다.

자세한 내용은 LDAP에서의 비트마스크 검색을 참조하세요.

이 프로세스는 또한 다음 사용자 정보를 업데이트합니다:

• 이름. 동기화 문제로 인해, 사용자가 프로필 이름을 변경하지 못하도록 방지가 활성화되어 있거나 sync_name이 false로 설정된 경우에는 name이 동기화되지 않습니다.

• 이메일 주소.

• sync_ssh_keys가 설정된 경우 SSH 공개 키.

• Kerberos가 활성화된 경우 Kerberos 신원.

LDAP 서버에 속도 제한이 있는 경우, 사용자 동기화 프로세스 중에 해당 제한에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

LDAP 사용자의 프로필 이름 동기화#

기본적으로 GitLab은 LDAP 사용자의 프로필 이름 필드를 동기화합니다.

이 동기화를 방지하려면 sync_name을 false로 설정할 수 있습니다.

gitlab_rails['ldap_servers'] = {
  'main' => {
    'sync_name' => false,
    }
}

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    ldap:
      servers:
        main:
          sync_name: false

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'sync_name' => false,
            }
        }

docker compose up -d

production: &base
  ldap:
    servers:
      main:
        sync_name: false

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

차단된 사용자#

다음 중 하나에 해당하면 사용자가 차단됩니다:

• 액세스 검사가 실패하여 해당 사용자가 GitLab에서 ldap_blocked 상태로 설정됩니다.

• 해당 사용자가 로그인할 때 LDAP 서버를 사용할 수 없습니다.

사용자가 차단되면 해당 사용자는 로그인하거나 코드를 push하거나 pull할 수 없습니다.

차단된 사용자는 다음 조건이 모두 충족되는 경우 LDAP로 로그인할 때 차단이 해제됩니다:

• 모든 액세스 검사 조건이 참입니다.

• 사용자가 로그인할 때 LDAP 서버를 사용할 수 있습니다.

LDAP 사용자 동기화가 실행될 때 LDAP 서버를 사용할 수 없으면 모든 사용자가 차단됩니다.

LDAP 사용자 동기화가 실행될 때 LDAP 서버를 사용할 수 없어 모든 사용자가 차단된 경우, 이후 LDAP 사용자 동기화가 실행되어도 해당 사용자들이 자동으로 차단 해제되지 않습니다.

그룹 동기화 {#group-sync}#

LDAP가 memberof 속성을 지원하는 경우, 사용자가 처음 로그인할 때 GitLab은 해당 사용자가 멤버여야 하는 그룹에 대한 동기화를 트리거합니다. 이를 통해 사용자는 그룹과 프로젝트에 대한 액세스 권한을 얻기 위해 매시간 동기화를 기다릴 필요가 없습니다.

그룹 동기화 프로세스는 매 시간 정각에 실행되며, CN 기반의 LDAP 동기화가 작동하려면 LDAP 구성에서 group_base가 설정되어야 합니다. 이를 통해 GitLab 그룹 멤버십이 LDAP 그룹 멤버를 기반으로 자동으로 업데이트됩니다.

group_base 구성은 GitLab에서 사용할 수 있어야 하는 LDAP 그룹을 포함하는 LDAP '컨테이너'(예: '조직' 또는 '조직 단위')여야 합니다. 예를 들어, group_base는 ou=groups,dc=example,dc=com이 될 수 있습니다. 구성 파일에서는 다음과 같이 표시됩니다.

LDAP 서버에 속도 제한이 있는 경우, 그룹 동기화 프로세스 중에 해당 제한에 도달할 수 있습니다. 자세한 내용은 속도 제한 문서를 확인하세요.

gitlab_rails['ldap_servers'] = {
  'main' => {
    'group_base' => 'ou=groups,dc=example,dc=com',
    }
}

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    ldap:
      servers:
        main:
          group_base: ou=groups,dc=example,dc=com

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'group_base' => 'ou=groups,dc=example,dc=com',
            }
        }

docker compose up -d

production: &base
  ldap:
    servers:
      main:
        group_base: ou=groups,dc=example,dc=com

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

그룹 동기화를 활용하려면, 그룹 Owner 또는 Maintainer 권한이 있는 사용자가 하나 이상의 LDAP 그룹 링크를 생성해야 합니다.

LDAP 서버와 GitLab 인스턴스 간에 연결 문제가 자주 발생하는 경우, 그룹 동기화 워커 간격을 기본값인 1시간보다 크게 설정하여 GitLab이 LDAP 그룹 동기화를 수행하는 빈도를 줄이는 것을 고려하세요.

그룹 링크 추가#

CN 및 필터를 사용하여 그룹 링크를 추가하는 방법에 대한 정보는 GitLab 그룹 문서를 참조하세요.

LDAP 그룹에 관리자 권한 할당#

그룹 동기화의 확장으로, 글로벌 GitLab 관리자를 자동으로 관리할 수 있습니다. admin_group에 그룹 CN을 지정하면 해당 LDAP 그룹의 모든 멤버에게 관리자 권한이 부여됩니다. 구성은 다음과 같습니다.

admin_group과 함께 group_base도 지정하지 않으면 관리자가 동기화되지 않습니다. 또한 전체 DN이 아닌 admin_group의 CN만 지정하세요. 또한, LDAP 사용자가 admin 권한을 가지고 있지만 admin_group 그룹의 멤버가 아닌 경우, GitLab은 동기화 시 해당 사용자의 admin 권한을 취소합니다.

gitlab_rails['ldap_servers'] = {
  'main' => {
    'group_base' => 'ou=groups,dc=example,dc=com',
    'admin_group' => 'my_admin_group',
    }
}

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    ldap:
      servers:
        main:
          group_base: ou=groups,dc=example,dc=com
          admin_group: my_admin_group

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'group_base' => 'ou=groups,dc=example,dc=com',
            'admin_group' => 'my_admin_group',
            }
        }

docker compose up -d

production: &base
  ldap:
    servers:
      main:
        group_base: ou=groups,dc=example,dc=com
        admin_group: my_admin_group

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

LDAP 그룹에 사용자 정의 관리자 권한 할당#

DETAILS: Tier: Ultimate

외부 LDAP 그룹에서 동기화된 모든 사용자에게 사용자 정의 관리자 권한을 할당할 수 있습니다. 이 옵션은 SAML 그룹에는 사용할 수 없습니다.

사용자가 다른 사용자 정의 권한이 할당된 여러 LDAP 그룹에 속하는 경우, GitLab은 먼저 링크된 LDAP 그룹과 연관된 권한을 할당합니다.

동기화 구성 후 사용자 정의 관리자 권한을 가진 LDAP 사용자가 LDAP 그룹에서 제거된 경우, 다음 동기화 때까지 사용자 정의 권한이 제거되지 않습니다.

전제 조건:

• 인스턴스와 통합된 LDAP 서버.

• 관리자 액세스.

글로벌 LDAP 그룹 멤버십 잠금#

GitLab 관리자는 그룹 멤버가 LDAP와 멤버십이 동기화된 하위 그룹에 새 멤버를 초대하는 것을 방지할 수 있습니다.

글로벌 그룹 멤버십 잠금은 LDAP 동기화가 구성된 최상위 그룹의 하위 그룹에만 적용됩니다. LDAP 동기화를 위해 구성된 최상위 그룹의 멤버십은 어떤 사용자도 수정할 수 없습니다.

글로벌 그룹 멤버십 잠금이 활성화된 경우:

• 그룹 또는 하위 그룹을 Code Owner로 설정할 수 없습니다. 자세한 내용은 글로벌 그룹 멤버십 잠금과의 비호환성을 참조하세요.

• 관리자만 액세스 수준을 포함한 모든 그룹의 멤버십을 관리할 수 있습니다.

• 사용자는 다른 그룹과 프로젝트를 공유하거나 그룹에서 생성된 프로젝트에 멤버를 초대할 수 없습니다.

글로벌 그룹 멤버십 잠금을 활성화하려면:

• LDAP를 구성합니다.

• 오른쪽 상단 모서리에서 Admin을 선택합니다.

• 왼쪽 사이드바에서 Settings > General을 선택합니다.

• Visibility and access controls를 확장합니다.

• Lock memberships to LDAP synchronization 체크박스가 선택되어 있는지 확인합니다.

LDAP 그룹 동기화 설정 관리 변경#

기본적으로 Owner 권한이 있는 그룹 멤버는 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

GitLab 관리자는 그룹 Owner에게서 이 권한을 제거할 수 있습니다:

• LDAP를 구성합니다.

• 오른쪽 상단 모서리에서 Admin을 선택합니다.

• 왼쪽 사이드바에서 Settings > General을 선택합니다.

• Visibility and access controls를 확장합니다.

• Allow group owners to manage LDAP-related settings 체크박스가 선택 해제되어 있는지 확인합니다.

Allow group owners to manage LDAP-related settings가 비활성화된 경우:

• 그룹 Owner는 최상위 그룹 및 하위 그룹 모두에 대한 LDAP 동기화 설정을 변경할 수 없습니다.

• 인스턴스 관리자는 인스턴스의 모든 그룹에 대한 LDAP 그룹 동기화 설정을 관리할 수 있습니다.

외부 그룹#

external_groups 설정을 사용하면 이러한 그룹에 속한 모든 사용자를 외부 사용자로 표시할 수 있습니다. 그룹 멤버십은 LdapGroupSync 백그라운드 작업을 통해 주기적으로 확인됩니다.

gitlab_rails['ldap_servers'] = {
  'main' => {
    'external_groups' => ['interns', 'contractors'],
    }
}

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    ldap:
      servers:
        main:
          external_groups: ['interns', 'contractors']

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
            'external_groups' => ['interns', 'contractors'],
          }
        }

docker compose up -d

production: &base
  ldap:
    servers:
      main:
        external_groups: ['interns', 'contractors']

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

그룹을 위한 GitLab Duo 애드온#

duo_add_on_groups 설정은 LDAP를 통해 인증하는 사용자에 대해 GitLab Duo 애드온 시트를 자동으로 관리합니다. 이 기능은 조직이 LDAP 그룹 멤버십을 기반으로 GitLab Duo 시트 할당 프로세스를 간소화하는 데 도움이 됩니다.

GitLab Duo 시트 동기화는 두 가지 방식으로 발생합니다:

• 사용자 로그인 시: 사용자가 LDAP를 통해 로그인하면 GitLab이 즉시 해당 사용자의 그룹 멤버십을 확인합니다.

• 예약된 동기화: GitLab은 매일 오전 02:00(서버 시간)에 모든 LDAP 사용자를 자동으로 동기화하여 사용자 로그인 없이도 시트 할당이 최신 상태로 유지되도록 합니다.

그룹의 애드온 시트 관리를 활성화하려면 GitLab 인스턴스에서 duo_add_on_groups 설정을 구성해야 합니다:

gitlab_rails['ldap_servers'] = {
  'main' => {
    'duo_add_on_groups' => ['duo_group_1', 'duo_group_2'],
    }
}

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    ldap:
      servers:
        main:
          duo_add_on_groups: ['duo_group_1', 'duo_group_2']

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_servers'] = {
          'main' => {
              'duo_add_on_groups' => ['duo_group_1', 'duo_group_2'],
          }
        }

docker compose up -d

production: &base
  ldap:
    servers:
      main:
        duo_add_on_groups: ['duo_group_1', 'duo_group_2']

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

그룹 동기화 기술적 세부 사항#

이 섹션에서는 어떤 LDAP 쿼리가 실행되고 그룹 동기화에서 어떤 동작을 기대할 수 있는지 설명합니다.

사용자의 LDAP 그룹 멤버십이 변경되면 해당 사용자의 그룹 액세스 수준이 강등될 수 있습니다. 예를 들어, 사용자가 그룹에서 Owner 권한을 가지고 있고 다음 그룹 동기화에서 Developer 권한만 가져야 한다고 나타나면 액세스가 그에 따라 조정됩니다. 유일한 예외는 사용자가 그룹의 마지막 Owner인 경우입니다. 그룹은 관리 업무를 수행하기 위해 최소한 한 명의 Owner가 필요합니다.

접근 제한이 있는 Minimal Access 권한 할당#

• GitLab 18.10에서 기본적으로 활성화됨.

접근 제한이 활성화되어 있고 구독 시트가 없는 경우, LDAP 그룹 동기화 중에 사용자에게 Minimal Access 권한이 할당됩니다.

자세한 내용은 SAML, SCIM 및 LDAP를 사용한 프로비저닝 동작을 참조하세요.

지원되는 LDAP 그룹 유형/속성#

GitLab은 다음 member 속성을 사용하는 LDAP 그룹을 지원합니다:

• member

• submember

• uniquemember

• memberof

• memberuid

즉, 그룹 동기화는 다음 object 클래스를 가진 LDAP 그룹을 (적어도) 지원합니다:

• groupOfNames

• posixGroup

• groupOfUniqueNames

다른 object 클래스도 위에 언급된 속성 중 하나로 멤버가 정의된 경우 작동해야 합니다.

Active Directory는 중첩된 그룹을 지원합니다. 구성 파일에서 active_directory: true가 설정된 경우 그룹 동기화는 재귀적으로 멤버십을 해결합니다.

중첩된 그룹 멤버십#

중첩된 그룹 멤버십은 중첩된 그룹이 구성된 group_base에서 발견되는 경우에만 해결됩니다. 예를 들어, GitLab이 DN이 cn=nested_group,ou=special_groups,dc=example,dc=com인 중첩된 그룹을 발견하지만 구성된 group_base가 ou=groups,dc=example,dc=com인 경우, cn=nested_group은 무시됩니다.

쿼리 {#queries}#

• 각 LDAP 그룹은 group_base를 기본으로 하고 (cn=<cn_from_group_link>) 필터를 사용하여 최대 한 번 쿼리됩니다.

• LDAP 그룹에 memberuid 속성이 있는 경우, GitLab은 각 멤버에 대해 추가 LDAP 쿼리를 실행하여 각 사용자의 전체 DN을 가져옵니다. 이 쿼리들은 base를 기본으로 하고, 범위는 baseObject이며, user_filter 설정 여부에 따라 다른 필터를 사용합니다. 필터는 (uid=<uid_from_group>) 또는 user_filter와의 조합일 수 있습니다.

벤치마크#

그룹 동기화는 가능한 한 성능이 좋도록 작성되었습니다. 데이터가 캐시되고, 데이터베이스 쿼리가 최적화되었으며, LDAP 쿼리가 최소화되었습니다. 마지막 벤치마크 실행에서 다음 메트릭이 나타났습니다:

20,000명의 LDAP 사용자, 11,000개의 LDAP 그룹, 각각 10개의 LDAP 그룹 링크가 있는 1,000개의 GitLab 그룹의 경우:

• 초기 동기화(GitLab에 기존 멤버 미할당) 소요 시간: 1.8시간

• 이후 동기화(멤버십 확인, 쓰기 없음) 소요 시간: 15분

이러한 메트릭은 기준을 제공하기 위한 것이며 성능은 다양한 요인에 따라 달라질 수 있습니다. 이 벤치마크는 극단적인 경우이며 대부분의 인스턴스는 이렇게 많은 사용자나 그룹을 가지고 있지 않습니다. 디스크 속도, 데이터베이스 성능, 네트워크 및 LDAP 서버 응답 시간이 이러한 메트릭에 영향을 줍니다.

LDAP 동기화 일정 조정#

LDAP가 사용자, 그룹, GitLab Duo 애드온 시트를 동기화하는 시간과 간격을 변경할 수 있습니다.

사용자의 경우#

기본적으로 GitLab은 서버 시간 오전 01:30에 하루에 한 번 워커를 실행하여 GitLab 사용자를 LDAP와 비교하여 확인하고 업데이트합니다.

동기화 프로세스를 너무 자주 실행하지 마세요. 이로 인해 여러 동기화가 동시에 실행될 수 있습니다. 대부분의 설치에서는 동기화 일정을 수정할 필요가 없습니다. 자세한 내용은 LDAP 보안 문서를 참조하세요.

다음 구성 값을 cron 형식으로 설정하여 LDAP 사용자 동기화 시간을 수동으로 구성할 수 있습니다. 필요한 경우 crontab 생성기를 사용할 수 있습니다. 아래 예시는 LDAP 사용자 동기화를 매 12시간마다 정각에 실행하도록 설정하는 방법을 보여줍니다.

gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    cron_jobs:
      ldap_sync_worker:
        cron: "0 */12 * * *"

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"

docker compose up -d

production: &base
  ee_cron_jobs:
    ldap_sync_worker:
      cron: "0 */12 * * *"

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

그룹의 경우#

기본적으로 GitLab은 매 시간 정각에 그룹 동기화 프로세스를 실행합니다. 표시된 값은 cron 형식입니다. 필요한 경우 crontab 생성기를 사용할 수 있습니다.

동기화 프로세스를 너무 자주 시작하지 마세요. 이로 인해 여러 동기화가 동시에 실행될 수 있습니다. 대부분의 설치에서는 동기화 일정을 수정할 필요가 없습니다.

다음 구성 값을 설정하여 LDAP 그룹 동기화 시간을 수동으로 구성할 수 있습니다. 아래 예시는 그룹 동기화를 매 두 시간마다 정각에 실행하도록 설정하는 방법을 보여줍니다.

gitlab_rails['ldap_group_sync_worker_cron'] = "0 */2 * * *"

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    cron_jobs:
      ldap_group_sync_worker:
        cron: "*/30 * * * *"

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_group_sync_worker_cron'] = "0 */2 * * *"

docker compose up -d

production: &base
  ee_cron_jobs:
    ldap_group_sync_worker:
      cron: "*/30 * * * *"

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

GitLab Duo 애드온 시트의 경우#

기본적으로 GitLab은 서버 시간 오전 02:00에 하루에 한 번 GitLab Duo 애드온 시트 동기화 프로세스를 실행하여 LDAP 그룹 멤버십을 확인하고 GitLab Duo 애드온 시트를 할당하거나 제거합니다.

동기화 프로세스를 너무 자주 시작하지 마세요. 이로 인해 여러 동기화가 동시에 실행될 수 있습니다. 대부분의 설치에서는 동기화 일정을 수정할 필요가 없습니다.

구성 값을 설정하여 LDAP GitLab Duo 애드온 시트 동기화 시간을 수동으로 구성할 수 있습니다. 다음 예시는 동기화를 매 네 시간마다 실행하도록 설정하는 방법을 보여줍니다.

gitlab_rails['ldap_add_on_seat_sync_worker_cron'] = "0 */4 * * *"

sudo gitlab-ctl reconfigure

helm get values gitlab > gitlab_values.yaml

global:
  appConfig:
    cron_jobs:
      ldap_add_on_seat_sync_worker:
        cron: "0 */4 * * *"

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['ldap_add_on_seat_sync_worker_cron'] = "0 */4 * * *"

docker compose up -d

production: &base
  ee_cron_jobs:
    ldap_add_on_seat_sync_worker:
      cron: "0 */4 * * *"

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart