계정 및 제한 설정

Tier: Free, Premium, Ultimate Offering: Self-managed

기본 프로젝트 제한

새로운 사용자가 개인 네임스페이스에서 생성할 수 있는 프로젝트의 최대 수를 구성할 수 있습니다. 이 제한은 설정 변경 후에 만들어진 새 사용자 계정에만 영향을 미칩니다. 기존 사용자에 대해서는 이 설정이 역작용하지 않지만 별도로 기존 사용자의 프로젝트 제한을 편집할 수 있습니다.

새로운 사용자의 개인 네임스페이스에서 생성할 수 있는 프로젝트 최대 수를 구성하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 기본 프로젝트 제한 값을 증가 또는 감소시킵니다.

기본 프로젝트 제한을 0으로 설정하면 사용자는 자신의 개인 네임스페이스에서 프로젝트를 생성할 수 없습니다. 그러나 프로젝트는 그룹에서 생성할 수 있습니다.

사용자의 프로젝트 제한

특정 사용자를 편집하고, 해당 사용자가 개인 네임스페이스에서 생성할 수 있는 프로젝트의 최대 수를 변경할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 개요 > 사용자를 선택합니다.
  3. 사용자 목록에서 사용자를 선택합니다.
  4. 편집을 선택합니다.
  5. 프로젝트 제한 값을 증가 또는 감소시킵니다.

첨부 파일 최대 크기

GitLab 댓글 및 답글의 첨부 파일 크기 제한은 100MB입니다. 최대 첨부 파일 크기를 변경하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 최대 첨부 파일 크기 (MiB)의 값 변경으로 증가 또는 감소합니다.

웹 서버에 구성된 값보다 큰 크기를 선택하는 경우 오류를 받을 수 있습니다. 자세한 내용은 문제 해결 섹션을 읽어보세요.

GitLab.com 리포지토리 크기 제한에 대해 더 알아보려면 계정 및 제한 설정을 읽으세요.

푸시 최대 크기

인스턴스의 최대 푸시 크기를 변경할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 최대 푸시 크기 (MiB)의 값 변경으로 증가 또는 감소합니다.

GitLab.com 푸시 크기 제한에 대해 더 알아보려면 계정 및 제한 설정을 읽으세요.

참고: 웹 UI를 통해 리포지토리에 파일을 추가할 때, 최대 첨부 파일 크기가 제한 요소입니다. 왜냐하면 웹 서버는 GitLab이 커밋을 생성하기 전에 파일을 받아야하기 때문입니다. 대용량 파일을 리포지토리에 추가하려면 Git LFS를 사용하세요. 이 설정은 Git LFS 객체를 푸시할 때는 적용되지 않습니다.

개인 액세스 토큰 접두어

개인 액세스 토큰에 접두어를 지정할 수 있습니다. 토큰을 더 빨리 찾거나 자동화 도구와 함께 사용하기 위해 접두어를 사용할 수 있습니다.

기본 접두어는 glpat-이지만 관리자는 이를 변경할 수 있습니다.

프로젝트 액세스 토큰과 그룹 액세스 토큰도 이 접두어를 상속받습니다.

접두어 설정

기본 글로벌 접두어를 변경하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. 개인 액세스 토큰 접두어 필드에 값을 입력합니다.
  5. 변경 사항 저장을 선택합니다.

또한 settings API를 사용하여 접두어를 구성할 수도 있습니다.

리포지토리 크기 제한

Tier: Premium, Ultimate Offering: Self-managed

귀하의 GitLab 인스턴스에 있는 리포지토리는 특히 LFS를 사용하는 경우 빠르게 커질 수 있습니다. 그 크기는 지속적으로 사용 가능한 저장소를 확보하는 신속한 속도로 증가할 수 있습니다. 이를 방지하기 위해 리포지토리 크기에 대한 엄격한 제한을 설정할 수 있습니다. 이 제한은 글로벌로, 그룹별로 또는 프로젝트별로 설정할 수 있으며 프로젝트별 제한이 우선합니다.

리포지토리 크기에 대한 제한을 설정하는 여러 사용 사례가 있습니다. 예를 들어 다음 워크플로우를 고려해보세요:

  1. 팀에서 앱을 개발하는데, 애플리케이션 리포지토리에 큰 파일을 저장해야 합니다.
  2. 프로젝트에 Git LFS를 사용했지만 저장소가 크게 확장되었습니다.
  3. 사용 가능한 저장소를 초과하기 전에 리포지토리당 10GB의 제한을 설정합니다.

참고: GitLab.com 리포지토리 크기 제한에 대해 더 알아보려면 계정 및 제한 설정을 읽으세요.

작동 방법

GitLab 관리자만 이러한 제한을 설정할 수 있습니다. 제한을 0으로 설정하면 제한이 없다는 뜻입니다.

이 설정 항목을 다음에서 찾을 수 있습니다:

  • 각 프로젝트의 설정:
    1. 프로젝트 홈페이지에서 설정 > 일반로 이동합니다.
    2. 이름, 주제, 아바타 섹션에서 리포지토리 크기 제한 (MiB) 필드에 값을 입력합니다.
    3. 변경 사항 저장을 선택합니다.
  • 각 그룹의 설정:
    1. 그룹 홈페이지에서 설정 > 일반으로 이동합니다.
    2. 이름, 가시성 섹션에서 리포지토리 크기 제한 (MiB) 필드에 값을 입력합니다.
    3. 변경 사항 저장을 선택합니다.
  • GitLab 전역 설정:
    1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
    2. 설정 > 일반을 선택합니다.
    3. 계정 및 제한 섹션을 확장합니다.
    4. 리포지토리 당 크기 제한 (MiB) 필드에 값을 입력합니다.
    5. 변경 사항 저장을 선택합니다.

새 프로젝트의 첫 푸시, LFS 객체를 포함하여 크기가 검사됩니다. 이들 크기의 합이 허용된 리포지토리 크기를 초과하는 경우 푸시가 거부됩니다.

참고: 리포지토리 크기 제한에는 리포지토리 파일과 LFS가 포함되나 아티팩트, 업로드, 위키, 패키지 또는 스니펫은 포함되지 않습니다. 리포지토리 크기 제한은 비공개 및 공개 프로젝트 모두에 적용됩니다.

파일을 수동으로 정리하는 자세한 내용은 Git을 사용하여 리포지토리 크기 축소하기를 참조하세요.

세션 기간

기본 세션 기간 사용자 정의

활동이 없을 때 사용자가 로그인 상태를 유지할 수 있는 시간을 변경할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.

  3. 계정 및 제한을 확장합니다. 설정된 기간은 세션 기간(분)에 표시됩니다.

    경고: 세션 기간(분)을 0으로 설정하면 GitLab이 손상됩니다. 자세한 정보는 이슈 19469를 참조하십시오.

기억하기가 활성화되어 있는 경우 사용자 세션은 무기한으로 활성 상태를 유지할 수 있습니다.

자세한 내용은 로그인에 사용되는 쿠키를 참조하십시오.

기억하기를 켜거나 끄기

사용자는 로그인할 때 기억하기 확인란을 선택할 수 있으며, 특정 브라우저로 접근할 때 해당 사용자의 세션이 무기한으로 유지됩니다. 보안 또는 규정 준수 목적으로 세션 만료를 필요로 하는 경우 이 설정을 해제할 수 있습니다. 이 설정을 해제하면 사용자 세션이 회의 기간 동안만 유효하도록 설정한 후 기본 세션 기간을 사용자 정의하는 방법에 따라 사용자 세션이 만료됩니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 기억하기 확인란을 선택하거나 선택 해제하여 이 설정을 켜거나 끌 수 있습니다.
  5. 변경 사항 저장을 선택합니다.

2FA 활성화된 경우 Git 작업을 위한 세션 기간 사용자 정의

Tier: 프리미엄, 얼티밋 Offering: Self-managed

플래그: 자체 관리형 GitLab에서 기본적으로 이 기능은 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 two_factor_for_cli라는 기능 플래그를 활성화할 수 있습니다. GitLab.com 및 전용 GitLab에서 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용하기에 적합하지 않습니다. 이 기능 플래그는 또한 SSH 작업에 대한 2FA에도 영향을 줍니다.

GitLab 관리자는 2FA가 활성화된 경우 Git 작업에 대한 세션 기간(분)을 사용자 정의할 수 있습니다. 기본값은 15이며 1부터 10080 사이의 값으로 설정할 수 있습니다.

이러한 세션이 유효한 기간을 설정하려면 다음을 수행합니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. 2FA가 활성화된 경우 Git 작업을 위한 세션 기간(분) 필드를 입력합니다.
  5. 변경 사항 저장을 선택합니다.

새로운 엑세스 토큰에 만료 날짜 요구

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 관리형, 전용 GitLab

전제 조건:

  • 관리자여야 합니다.

새로운 모든 엑세스 토큰이 만료 날짜를 가져야 합니다. 이 설정은 기본적으로 활성화되어 있으며 다음의 것에 적용됩니다:

  • 프로젝트 엑세스 토큰.
  • 그룹 엑세스 토큰.
  • 서비스 계정 사용자의 개인 엑세스 토큰.

서비스 계정의 개인 엑세스 토큰의 경우, 애플리케이션 설정 API에서 service_access_tokens_expiration_enforced 설정을 사용합니다.

새로운 엑세스 토큰에 만료 날짜를 요구하려면 다음을 수행합니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 개인 / 프로젝트 / 그룹 엑세스 토큰 만료 확인란을 선택합니다.
  5. 변경 사항 저장을 선택합니다.

새로운 엑세스 토큰에 만료 날짜를 요구한 경우:

  • 사용자는 새로운 엑세스 토큰의 수명 기간을 초과하지 않는 만료 날짜를 설정해야 합니다.
  • 엑세스 토큰의 최대 유효 기간을 제어하려면 엑세스 토큰의 유효 기간 제한 설정을 사용합니다.

최상위 그룹 소유자가 서비스 계정을 만들 수 있도록 허용

Tier: 프리미엄, 얼티밋 Offering: Self-managed
  • GitLab 17.5에서 도입되었습니다. 기능 플래그 allow_top_level_group_owners_to_create_service_accounts가 GitLab 자체 관리형에 사용 가능한 상태로 도입되었습니다. 기본적으로 비활성화되어 있습니다.

플래그: GitLab 자체 관리형에서 기본적으로 이 기능은 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 allow_top_level_group_owners_to_create_service_accounts라는 기능 플래그를 활성화할 수 있습니다. GitLab.com에서는 이 기능을 사용할 수 있습니다.

기본적으로 GitLab 자체 관리형의 최상위 그룹 소유자는 서비스 계정을 만들 수 없습니다. 그러나 GitLab 관리자는 최상위 그룹 소유자가 서비스 계정을 만들 수 있도록 할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 서비스 계정 생성 하위에서 최상위 그룹 소유자가 서비스 계정 생성 허용 확인란을 선택합니다.
  5. 변경 사항 저장을 선택합니다.

SSH 키의 수명 제한

Tier: 얼티밋 Offering: Self-managed

사용자는 선택적으로 SSH 키의 수명을 지정할 수 있습니다. 이 수명은 필수 사항이 아니며 임의의 일수로 설정할 수 있습니다.

SSH 키는 GitLab에 액세스하는 사용자 자격 증명입니다. 그러나 보안 요구 사항이 있는 조직에서는 이러한 비밀 유지를 강화하기 위해 이러한 키의 정기적인 회전을 요구할 수 있습니다.

수명 설정

GitLab 관리자만 수명을 설정할 수 있습니다. 비워 두면 제한이 없음을 의미합니다.

SSH 키가 유효한 기간을 설정하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. SSH 키의 최대 허용 수명(일) 필드에 값을 입력합니다.
  5. 변경 사항 저장을 선택합니다.

SSH 키의 수명이 설정되면 GitLab은:

  • 사용자가 새로운 SSH 키에 허용된 수명을 초과하지 않는 만료 날짜를 설정하도록 요구합니다.
  • 기간 제한을 기존 SSH 키에 적용합니다. 만료되지 않거나 수명이 허용된 최대 기간보다 큰 키는 즉시 무효화됩니다.

참고: 사용자의 SSH 키가 무효화되면 같은 키를 삭제하고 다시 추가할 수 있습니다.

엑세스 토큰의 수명 제한

Tier: Ultimate Offering: Self-Managed

사용자는 선택적으로 엑세스 토큰의 최대 수명을 일(day) 기준으로 지정할 수 있습니다. 이는 개인, 그룹 및 프로젝트 엑세스 토큰을 포함합니다. 이 수명은 필수 사항은 아니며 0보다 크고 365보다 작거나 같은 임의의 값을 설정할 수 있습니다. 이 설정을 비워 두면 엑세스 토큰의 기본 허용 수명은 365일입니다.

엑세스 토큰은 GitLab에 대한 프로그래밍 방식의 엑세스에 필요한 유일한 토큰입니다. 그러나 보안 요구 사항을 갖춘 조직은 이러한 토큰을 정기적으로 교체함으로써 더 많은 보호를 강제할 수 있습니다.

수명 설정

엑세스 토큰의 수명을 설정하는 것은 GitLab 관리자만 가능합니다. 비워 두면 제한이 없음을 의미합니다.

엑세스 토큰의 유효 기간을 설정하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. 엑세스 토큰의 최대 허용 수명(일) 필드를 채웁니다.
  5. 변경 사항 저장을 선택합니다.

엑세스 토큰의 수명을 설정한 후에 GitLab에서는:

  • 새 개인 액세스 토큰에 대해 수명을 적용하고 사용자가 만료일을 설정하도록 요구합니다. 그리고 허용된 수명보다 늦은 날짜를 설정합니다.
  • 3시간 후에 만료일이나 허용된 수명보다 긴 수명을 가진 이전 토큰을 취소합니다. 취소가 이루어지기 전에 3시간이 주어지며, 이 시간 동안 관리자가 허용된 수명을 변경하거나 제거할 수 있습니다.

사용자 OAuth 애플리케이션 설정

Tier: Free, Premium, Ultimate Offering: Self-Managed

사전 요구 사항:

관리자여야 합니다.

사용자 OAuth 애플리케이션 설정은 사용자가 GitLab을 OAuth 제공자로 사용하는 애플리케이션을 등록할 수 있는지 여부를 제어합니다. 이 설정은 사용자 소유의 OAuth 애플리케이션에 영향을 미치지만 그룹 수준의 OAuth 애플리케이션에는 영향을 미치지 않습니다.

사용자 OAuth 애플리케이션 설정을 켜거나 끄려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. 사용자 OAuth 애플리케이션 확인란을 선택 또는 해제합니다.
  5. 변경 사항 저장을 선택합니다.

사용자 프로필 이름 변경 금지

Tier: Premium, Ultimate Offering: Self-Managed

감사 이벤트에서 사용자 세부 정보의 무결성을 유지하기 위해 GitLab 관리자는 사용자가 프로필 이름을 변경하는 기능을 비활성화할 수 있습니다.

비활성화하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한 섹션을 확장합니다.
  4. 사용자가 프로필 이름을 변경하는 것을 방지 확인란을 선택합니다.

참고: 이 기능이 비활성화된 경우 GitLab 관리자는 여전히 새로운 사용자의 프로필을 기본적으로 비공개로 설정하거나 API를 사용하여 사용자 이름을 업데이트할 수 있습니다.

사용자가 조직 생성을 금지

Status: Experiment
  • GitLab 16.7에 도입되었으며 기본적으로 ui_for_organizations라는 플래그가 있습니다. 기본적으로 비활성화됨.
Self-Managed GitLab의 경우 기본적으로 이 기능을 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 ui_for_organizations라는 플래그를 활성화해야 합니다. GitLab.com 및 전용 GitLab에서는 이 기능을 사용할 수 없습니다. 이 기능은 아직 제품으로 출시 준비가 되지 않았습니다.

기본적으로 사용자는 조직을 생성할 수 있습니다. GitLab 관리자는 사용자가 조직을 생성하는 것을 금지할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 사용자가 조직을 생성하는 것을 허용 확인란을 선택 해제합니다.

새 사용자가 최상위 그룹을 만드는 것을 방지

기본적으로 새 사용자는 최상위 그룹을 만들 수 있습니다. GitLab 관리자는 새 사용자가 최상위 그룹을 만드는 것을 방지할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 새 사용자가 최상위 그룹을 만들 수 있도록 함 확인란을 선택 해제합니다.

비회원이 프로젝트 및 그룹 생성을 방지

기본적으로 게스트 역할을 가진 사용자는 프로젝트 및 그룹을 생성할 수 있습니다. GitLab 관리자는 이러한 동작을 방지할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 게스트 역할까지 프로젝트 및 개인 프로젝트를 만들 수 있도록 함 확인란을 선택 해제합니다.
  5. 변경 사항 저장을 선택합니다.

사용자가 프로필을 비공개로 만들 수 있도록 함

Tier: Premium, Ultimate Offering: Self-Managed Status: Experiment
  • GitLab 17.1에 도입되었으며 기본적으로 disallow_private_profiles라는 플래그가 있습니다. 기본적으로 비활성화됨.
이 기능의 사용 가능성은 플래그로 제어됩니다. 자세한 내용은 이력을 참조하십시오. 이 기능은 테스트용으로 제공되지만 제품으로 사용하기에는 아직 준비되지 않았습니다.

기본적으로 사용자는 프로필을 비공개로 설정할 수 있습니다. GitLab 관리자는 이 설정을 비활성화하여 사용자가 프로필을 비공개로 설정하는 것을 방지할 수 있습니다.

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 사용자가 프로필을 비공개로 설정하는 것을 허용 확인란을 선택 해제합니다.
  5. 변경 사항 저장을 선택합니다.

참고: 이 설정이 비활성화되면, 새 사용자의 프로필을 기본적으로 비공개로 설정도 비활성화됩니다.

경고: 이 설정이 비활성화되면 기존의 비공개 프로필이 공개로 변경되지는 않습니다. GitLab 관리자는 모든 기존의 비공개 프로필을 수동으로 공개로 변경해야 합니다. 자세한 내용은 이슈 461701을 참조하십시오.

새 사용자의 프로필을 기본적으로 프라이빗으로 설정하기

기본적으로 새로 생성된 사용자는 공개 프로필을 가지게 됩니다. GitLab 관리자는 새 사용자의 프로필을 기본적으로 프라이빗하게 설정할 수 있습니다:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 새로운 사용자의 프로필을 기본적으로 프라이빗으로 만듭니다 확인란을 선택합니다.
  5. 변경 사항 저장을 선택합니다.

참고: 사용자가 자신의 프로필을 비공개로 만들 수 있도록 허용이 비활성화되어 있는 경우, 이 설정도 비활성화됩니다.

사용자 계정 삭제 방지

Tier: Premium, Ultimate Offering: Self-Managed
  • GitLab 16.1에서 deleting_account_disabled_for_users라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.

기본적으로 사용자는 자신의 계정을 삭제할 수 있습니다. GitLab 관리자는 사용자가 자신의 계정을 삭제하는 것을 방지할 수 있습니다:

  1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 제한을 확장합니다.
  4. 사용자가 자신의 계정을 삭제하는 것을 허용 확인란을 해제합니다.

문제 해결

413 Request Entity Too Large

GitLab에서 댓글이나 답글에 파일을 첨부할 때 413 Request Entity Too Large 오류가 표시된다면, 최대 첨부 파일 크기가 웹 서버에서 허용된 값보다 큰 것일 수 있습니다.

Linux 패키지 설치에서 최대 첨부 파일 크기를 200MB로 늘리려면, 최대 첨부 파일 크기를 늘리기 전에 아래 줄을 /etc/gitlab/gitlab.rb에 추가해야 할 수 있습니다: 

nginx['client_max_body_size'] = "200m"

이 저장소가 크기 제한을 초과했습니다

만약 Rails exceptions log에서 이와 같은 간헐적인 푸시 오류를 받는다면: 

Your push has been rejected, because this repository has exceeded its size limit.

Housekeeping 작업이 저장소 크기의 증가를 유발할 수 있습니다. 이 문제를 해결하기 위해 아래 옵션 중 하나를 단기적으로 해결할 수 있습니다: