GitLab 인스턴스의 관리자는 브랜치, 프로젝트, 스니펫, 그룹 등에 특정 제어를 적용할 수 있습니다. 예를 들어 다음 항목을 정의할 수 있습니다.

• 프로젝트를 생성하거나 삭제할 수 있는 권한.
• 삭제된 프로젝트와 그룹의 보존 기간.
• 그룹, 프로젝트, 스니펫의 가시성.
• 허용되는 SSH 키의 유형과 길이.
• 허용 프로토콜(SSH 또는 HTTPS), 클론 URL 같은 Git 설정.
• 푸시 미러링과 풀 미러링의 허용 또는 차단.

사전 요구 사항:

• 관리자여야 합니다.

가시성 및 액세스 제어 옵션에 접근하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.

프로젝트를 만들 수 있는 권한 정의#

인스턴스에 프로젝트 생성 보호를 추가할 수 있습니다. 이 보호는 인스턴스에서 그룹에 프로젝트를 추가할 수 있는 권한을 정의합니다.

Default minimum role required to create projects 설정을 구성하면 새 그룹에 적용되는 기본값을 지정합니다. 기존 그룹은 현재 권한을 유지합니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Default minimum role required to create projects에서 원하는 권한을 선택합니다.
   • No one.
   • Administrators.
   • Owners.
   • Maintainers.
   • Developers.
5. Save changes를 선택합니다.

관리자만 프로젝트 삭제 가능하도록 제한#

사전 요구 사항:

• 관리자이거나 프로젝트에서 Owner 권한이 있어야 합니다.

프로젝트 삭제를 관리자만 가능하도록 제한하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Allowed to delete projects로 이동해 Administrators를 선택합니다.
5. Save changes를 선택합니다.

이 제한을 해제하는 방법은 다음과 같습니다.

1. Owners and administrators를 선택합니다.
2. Save changes를 선택합니다.

삭제 보호#

히스토리

• GitLab 18.0에서 GitLab Premium에서 GitLab Free로 이동되었습니다.

삭제 보호는 인스턴스에서 그룹과 프로젝트가 실수로 삭제되는 것을 방지합니다.

보존 기간#

그룹과 프로젝트는 정의한 보존 기간 동안 복원할 수 있는 상태로 유지됩니다. 보존 기간의 기본값은 30일이며, 1 일에서 90 일 사이의 값으로 변경할 수 있습니다.

사전 요구 사항:

• 관리자 액세스 권한이 있어야 합니다.

그룹과 프로젝트에 대한 삭제 보호를 구성하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Retention period로 이동해 보존 기간을 1 일에서 90 일 사이의 값으로 설정합니다.
5. Save changes를 선택합니다.

기본값 재정의 및 영구 삭제#

지연을 재정의하고 삭제 예정으로 표시된 프로젝트를 영구히 삭제하는 방법은 다음과 같습니다.

1. 프로젝트를 복원합니다.
2. 프로젝트 관리에 설명된 대로 프로젝트를 삭제합니다.

프로젝트 가시성 기본값 구성#

새 프로젝트의 가시성 수준 기본값을 설정하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. 원하는 기본 프로젝트 가시성을 선택합니다.
   • Private - 각 사용자에게 프로젝트 액세스 권한을 명시적으로 부여합니다. 이 프로젝트가 그룹에 속해 있으면 그룹 멤버에게 액세스 권한이 부여됩니다.
   • Internal - 외부 사용자를 제외한 인증된 모든 사용자가 프로젝트에 접근할 수 있습니다.
   • Public - 모든 사용자가 인증 없이 프로젝트에 접근할 수 있습니다.
5. Save changes를 선택합니다.

스니펫 가시성 기본값 구성#

새 스니펫의 가시성 수준 기본값을 설정하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Default snippet visibility에서 원하는 가시성 수준을 선택합니다.
   • Private.
   • Internal. 이 설정은 GitLab.com의 새 프로젝트, 그룹, 스니펫에서 비활성화되어 있습니다. Internal 가시성 설정을 사용하던 기존 스니펫은 이 설정을 유지합니다. 이 변경에 대한 자세한 내용은 이슈 12388을 참고합니다.
   • Public.
5. Save changes를 선택합니다.

그룹 가시성 기본값 구성#

새 그룹의 가시성 수준 기본값을 설정하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Default group visibility에서 원하는 가시성 수준을 선택합니다.
   • Private - 멤버만 그룹과 그 프로젝트를 볼 수 있습니다.
   • Internal - 외부 사용자를 제외한 인증된 모든 사용자가 그룹과 내부 프로젝트를 볼 수 있습니다.
   • Public - 그룹과 공개 프로젝트를 보는 데 인증이 필요하지 않습니다.
5. Save changes를 선택합니다.

그룹 가시성에 대한 자세한 내용은 그룹 가시성을 참고합니다.

가시성 수준 제한#

가시성 수준을 제한할 때는 변경 대상 항목에서 가시성을 상속하는 하위 그룹 및 프로젝트의 권한과 이 제한이 어떻게 상호 작용하는지 고려합니다.

이 설정은 개인 네임스페이스 아래에 생성된 프로젝트에는 적용되지 않습니다. 이 기능을 엔터프라이즈 사용자로 확장하는 기능 요청 이 있습니다.

그룹, 프로젝트, 스니펫, 선택한 페이지의 가시성 수준을 제한하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Restricted visibility levels에서 제한할 가시성 수준을 선택합니다.
   • Public 수준을 제한하면 다음과 같습니다.
     • 관리자만 공개 그룹, 프로젝트, 스니펫을 만들 수 있습니다.
     • 사용자 프로필은 웹 인터페이스에서 인증된 사용자에게만 표시됩니다.
     • 사용자 속성은 GraphQL API로 조회할 수 없습니다.
   • Internal 수준을 제한하면 다음과 같습니다.
     • 관리자만 내부 그룹, 프로젝트, 스니펫을 만들 수 있습니다.
   • Private 수준을 제한하면 다음과 같습니다.
     • 관리자만 비공개 그룹, 프로젝트, 스니펫을 만들 수 있습니다.
5. Save changes를 선택합니다.

활성화된 Git 액세스 프로토콜 구성#

GitLab 액세스 제한을 사용하면 사용자가 GitLab과 통신할 때 사용할 프로토콜을 선택할 수 있습니다. 액세스 프로토콜을 비활성화해도 서버 자체에 대한 포트 접근은 차단되지 않습니다. 해당 프로토콜에 쓰이는 포트인 SSH 나 HTTP(S) 포트에는 여전히 접근할 수 있습니다. GitLab의 제한은 애플리케이션 수준에서 적용됩니다.

GitLab은 선택한 프로토콜에 대해서만 Git 작업을 허용합니다.

• SSH와 HTTP(S)를 모두 활성화하면 사용자가 둘 중 하나를 선택할 수 있습니다.
• 한 가지 프로토콜만 활성화하면 프로젝트 페이지에는 허용된 프로토콜의 URL만 표시되고 변경 옵션은 나타나지 않습니다.

인스턴스의 모든 프로젝트에 적용할 Git 액세스 프로토콜을 지정하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Enabled Git access protocols에서 원하는 프로토콜을 선택합니다.
   • SSH와 HTTP(S) 모두.
   • SSH만.
   • HTTP(S)만.
5. Save changes를 선택합니다.

HTTP(S)용 Git 클론 URL 사용자 정의#

HTTP(S) 용 프로젝트 Git 클론 URL을 사용자 정의할 수 있으며, 이는 프로젝트 페이지에서 사용자에게 표시되는 클론 패널에 반영됩니다. 예를 들면 다음과 같습니다.

• GitLab 인스턴스가 https://example.com에 있으면 프로젝트 클론 URL은 https://example.com/foo/bar.git 형태가 됩니다.
• 클론 URL을 https://git.example.com/gitlab/foo/bar.git 형태로 바꾸려면 이 설정을 https://git.example.com/gitlab/로 지정합니다.

gitlab.rb에서 HTTP(S) 용 사용자 정의 Git 클론 URL을 지정하려면 gitlab_rails['gitlab_ssh_host']에 새 값을 설정합니다. GitLab UI에서 새 값을 지정하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. **Custom Git clone URL for HTTP(S)**에 루트 URL을 입력합니다.
5. Save changes를 선택합니다.

RSA, DSA, ECDSA, ED25519, ECDSA_SK, ED25519_SK SSH 키에 대한 기본값 구성#

이 옵션은 SSH 키에 허용되는 유형과 길이를 지정합니다.

각 키 유형에 대한 제한을 지정하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. RSA SSH keys로 이동합니다.
5. 각 키 유형에 대해 사용을 허용하거나 전면 차단할 수 있고, 다음 길이만 허용할 수도 있습니다.
   • 최소 1024비트.
   • 최소 2048비트.
   • 최소 3072비트.
   • 최소 4096비트.
   • 최소 1024비트.
6. Save changes를 선택합니다.

프로젝트 미러링 활성화#

GitLab은 기본적으로 프로젝트 미러링을 활성화합니다. 이를 비활성화하면 모든 리포지터리에서 풀 미러링과 푸시 미러링 이 더 이상 동작하지 않습니다. 이후에는 관리자 사용자가 프로젝트 단위로만 다시 활성화할 수 있습니다.

인스턴스의 프로젝트 Maintainer가 프로젝트별로 미러링을 구성할 수 있도록 허용하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Repository를 선택합니다.
3. Repository mirroring을 확장합니다.
4. Allow project maintainers to configure repository mirroring을 선택합니다.
5. Save changes를 선택합니다.

전역 허용 IP 주소 범위 구성#

관리자는 IP 주소 범위를 그룹별 IP 제한과 함께 사용할 수 있습니다. 전역 허용 IP 주소를 지정하면 그룹이 자체 IP 주소 제한을 설정하더라도 GitLab 설치의 일부 기능이 정상적으로 동작합니다.

예를 들어 GitLab Pages 데몬이 10.0.0.0/24 범위에서 실행된다면 그 범위를 전역으로 허용합니다. 그러면 그룹의 IP 주소 제한에 10.0.0.0/24 범위가 포함되어 있지 않더라도 GitLab Pages는 파이프라인에서 아티팩트를 가져올 수 있습니다.

그룹의 허용 목록에 IP 주소 범위를 추가하는 방법은 다음과 같습니다.

사전 요구 사항:

• 관리자여야 합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Globally-allowed IP ranges에 IP 주소 범위 목록을 입력합니다. 이 목록의 특징은 다음과 같습니다.
   • IP 주소 범위의 개수에 제한이 없습니다.
   • SSH와 HTTP로 인가된 IP 주소 범위 모두에 적용됩니다. 이 목록을 인가 유형별로 나눌 수는 없습니다.
5. Save changes를 선택합니다.

그룹 및 프로젝트 초대 방지#

히스토리

• GitLab 18.0에서 도입되었습니다. 기본적으로 비활성화되어 있습니다.

관리자는 관리자가 아닌 사용자가 인스턴스의 모든 그룹이나 프로젝트에 사용자를 초대하지 못하도록 막을 수 있습니다. 이 설정을 구성하면 관리자만 인스턴스의 그룹이나 프로젝트에 사용자를 초대할 수 있습니다.

사전 요구 사항:

• 관리자여야 합니다.

초대를 방지하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. Prevent group member invitations 체크박스를 선택합니다.
5. Save changes를 선택합니다.

GitLab 크레딧 사용자 데이터 표시#

히스토리

• 사용자 데이터 표시를 허용하는 인스턴스 설정이 GitLab 18.7에서
• GitLab 18.10에서 기능 플래그 usage_billing_dev가 제거되었습니다.

사전 요구 사항:

• 관리자여야 합니다.

GitLab 크레딧 대시보드에서 사용자 데이터 표시를 켜는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. GitLab Credits dashboard에서 Display user data 체크박스를 선택합니다.
5. Save changes를 선택합니다.

MCP 서버에 대한 액세스 허용#

히스토리

• GitLab 19.0에서 mcp_server_availability_setting이라는
• GitLab 19.2에서 일반 공급되었습니다.
• GitLab 19.5에서 기존 인스턴스에 대해 관리자가 끄지 않은 경우 켜졌습니다.

MCP 서버에 대한 액세스는 기본적으로 켜져 있습니다. GitLab 19.5로 업그레이드하면 관리자가 끄지 않은 한 인스턴스에서 켜집니다.

사전 요구 사항:

• 관리자 액세스 권한.

인스턴스에서 MCP 서버에 대한 액세스를 변경하는 방법은 다음과 같습니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility and access controls를 확장합니다.
4. MCP client access 섹션에서 Allow connection to GitLab 체크박스를 선택하거나 선택 해제합니다.
5. Save changes를 선택합니다.

이 설정을 끄면 MCP API는 모든 요청을 거부합니다.