InfoGrab Docs

새 사용자 계정 제한

요약

새 사용자 계정에 대해 다음과 같은 제한을 시행할 수 있습니다: 기본적으로 GitLab 도메인을 방문하는 모든 사용자가 계정을 생성할 수 있습니다. 다음 명령을 실행하여 Rails 콘솔로 새 사용자 계정 생성을 방지할 수도 있습니다:

새 사용자 계정에 대해 다음과 같은 제한을 시행할 수 있습니다:

  • 계정 생성 방지.
  • 새 계정에 관리자 승인 요구.
  • 사용자 이메일 확인 요구.
  • 특정 이메일 도메인을 사용한 새 계정 허용 또는 거부.

전제 조건#

관리자 접근 권한이 있어야 합니다.

새 사용자 계정 생성 비활성화#

기본적으로 GitLab 도메인을 방문하는 모든 사용자가 계정을 생성할 수 있습니다. 공개 GitLab 인스턴스를 운영하는 고객의 경우, 공개 사용자가 계정을 생성할 것으로 예상하지 않는다면 새 계정 생성을 비활성화하는 것을 강력히 권장합니다. GitLab Dedicated의 경우, 인스턴스가 프로비저닝될 때 기본적으로 새 계정 생성이 방지됩니다.

새 계정 생성을 방지하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Allow new user accounts 체크박스를 해제한 다음 Save changes를 선택합니다.

다음 명령을 실행하여 Rails 콘솔로 새 사용자 계정 생성을 방지할 수도 있습니다:

::Gitlab::CurrentSettings.update!(signup_enabled: false)

새 사용자 계정에 관리자 승인 요구#

이 설정은 새 GitLab 인스턴스에서 기본적으로 활성화되어 있습니다. 이 설정이 활성화되면 GitLab 도메인을 방문하여 등록 양식을 사용하여 새 계정을 생성하는 모든 사용자는 계정을 사용하기 전에 관리자로부터 명시적인 승인을 받아야 합니다. 이 설정은 사용자 계정이 허용된 경우에만 적용됩니다.

새 사용자 계정에 관리자 승인을 요구하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Require admin approval for new user accounts 체크박스를 선택한 다음 Save changes를 선택합니다.

관리자가 이 설정을 비활성화하면 승인 대기 중인 사용자는 백그라운드 job에서 자동으로 승인됩니다.

Note

이 설정은 LDAP 또는 OmniAuth 사용자에게는 적용되지 않습니다. OmniAuth 또는 LDAP를 사용하여 계정을 생성하는 새 사용자에 대한 승인을 시행하려면 OmniAuth 구성 또는 LDAP 구성에서 block_auto_created_userstrue로 설정하세요. 사용자 상한을 사용하여 새 사용자에 대한 승인을 시행할 수도 있습니다.

사용자 이메일 확인#

히스토리
  • GitLab 15.9에서 소프트 이메일 확인이 기능 플래그에서 애플리케이션 설정으로 변경됨.

계정 생성 시 확인 이메일을 보내고 사용자가 로그인하기 전에 이메일 주소를 확인해야 하도록 설정할 수 있습니다.

새 계정에 사용된 이메일 주소 확인을 시행하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Email confirmation settings 아래에서 Hard를 선택합니다.

다음 설정을 사용할 수 있습니다:

  • Hard - 계정 생성 시 확인 이메일을 보냅니다. 새 사용자는 로그인하기 전에 이메일 주소를 확인해야 합니다.
  • Soft - 계정 생성 시 확인 이메일을 보냅니다. 새 사용자는 즉시 로그인할 수 있지만 3일 이내에 이메일을 확인해야 합니다. 3일 후 사용자는 이메일을 확인할 때까지 로그인할 수 없습니다.
  • Off - 새 사용자는 이메일 주소를 확인하지 않고 로그인할 수 있습니다.

제한된 접근#

히스토리

초과 요금을 방지하기 위해 제한된 접근을 사용하세요. 초과 요금은 구독의 라이선스 사용자 수를 초과할 때 발생하며, 다음 분기별 정산 시 지불해야 합니다.

제한된 접근을 활성화하면 구독에 남은 라이선스 시트가 없을 때 인스턴스에서 새 결제 사용자를 추가할 수 없습니다.

Note

인스턴스 또는 보류 중인 멤버가 있는 그룹에 사용자 상한이 활성화된 경우 제한된 접근을 활성화하면 보류 중인 모든 멤버가 그룹에서 자동으로 제거됩니다.

제한된 접근 활성화#

전제 조건:

  • 관리자여야 합니다.
  • 그룹 또는 하위 그룹이나 프로젝트 중 하나가 외부에서 공유되지 않아야 합니다.

제한된 접근을 활성화하려면:

  1. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  2. New user account restrictions를 확장합니다.
  3. Seat control 아래에서 Restricted access를 선택합니다.

제한된 접근을 활성화하면 그룹 계층 구조 외부의 그룹 초대 방지 설정이 자동으로 활성화됩니다. 이 설정은 초과 요금을 발생시킬 수 있는 새 결제 사용자가 예기치 않게 추가되는 것을 방지합니다.

필요에 따라 그룹 및 하위 그룹의 프로젝트 공유를 독립적으로 구성할 수 있습니다.

SAML, SCIM 및 LDAP를 통한 프로비저닝 동작#

히스토리

제한된 접근이 활성화되고 사용 가능한 구독 시트가 없는 경우, SAML, SCIM 또는 LDAP를 통해 프로비저닝된 사용자는 구성된 접근 수준 대신 최소 접근 권한이 할당됩니다. 이 동작은 GitLab.com 및 GitLab Self-Managed Ultimate에서 결제 시트를 소비하지 않고 동기화를 계속할 수 있도록 합니다.

최소 접근 권한을 가진 사용자는 인증하고 그룹에 접근할 수 있지만 제한된 권한을 가집니다. 시트가 가용해지면 사용자를 의도한 접근 수준으로 승격할 수 있습니다. 결제 역할을 가진 기존 사용자는 이 동작의 영향을 받지 않습니다.

시트 사용량 보기를 통해 최소 접근 권한을 가진 사용자를 관리할 수 있습니다.

알려진 문제#

제한된 접근을 활성화하면 다음과 같은 알려진 문제가 발생하여 초과가 발생할 수 있습니다:

  • 다음과 같은 경우 결제 사용자 수가 여전히 초과될 수 있습니다:
    • SAML, SCIM 또는 LDAP를 사용하여 새 멤버를 추가하고 구독의 시트 수를 초과한 경우. 최소 접근 폴백 기능이 활성화되면 사용자는 차단 대신 최소 접근 권한이 할당됩니다.
    • 관리자 접근 권한을 가진 여러 사용자가 동시에 멤버를 추가하는 경우.
    • 새 결제 사용자가 초대 수락을 지연하는 경우. 사용자를 초대하면 초대를 수락할 때까지 결제 시트를 소비하지 않습니다. 초대된 사용자가 수락을 지연하면 그 시간 동안 다른 사용자를 초대하고 추가할 수 있습니다. 지연된 사용자가 최종적으로 수락하면 결제 시트를 소비하며, 이미 시트 한도에 도달한 경우 초과가 발생할 수 있습니다.
  • 현재 구독보다 적은 사용자 수로 GitLab 영업팀을 통해 구독을 갱신하면 초과 요금이 발생합니다. 이 요금을 피하려면 갱신이 시작되기 전에 추가 사용자를 제거하세요. 예를 들어, 20명의 사용자가 있고 15명의 사용자로 구독을 갱신하면 5명의 추가 사용자에 대한 초과 요금이 부과됩니다.

또한 제한된 접근은 표준 비초과 흐름을 차단할 수 있습니다:

  • 결제 역할로 업데이트되거나 추가되는 서비스 봇이 잘못 차단됩니다.
  • 이메일을 통한 기존 결제 사용자 초대 또는 업데이트가 예기치 않게 차단됩니다.

사용자 상한#

사용자 상한은 관리자 승인 없이 구독에 계정을 생성하거나 추가될 수 있는 최대 결제 사용자 수입니다. 사용자 상한에 도달하면 계정을 생성하거나 추가되는 사용자는 관리자로부터 승인을 받아야 합니다. 사용자는 관리자의 승인 후에만 계정을 사용할 수 있습니다.

관리자가 사용자 상한을 늘리거나 제거하면 승인 대기 중인 사용자는 자동으로 승인됩니다.

결제 사용자 수는 하루에 한 번 업데이트됩니다. 상한이 이미 초과된 후에만 소급하여 적용될 수 있습니다. 상한이 현재 결제 사용자 수보다 낮은 값으로 설정되면(예: 1) 상한이 즉시 활성화됩니다.

개별 그룹에 대한 사용자 상한도 설정할 수 있습니다.

Note

LDAP 또는 OmniAuth를 사용하는 인스턴스의 경우, 새 사용자 계정에 대한 관리자 승인이 활성화되거나 비활성화될 때 Rails 구성 변경으로 인해 다운타임이 발생할 수 있습니다. 사용자 상한을 설정하여 새 사용자에 대한 승인을 시행할 수 있습니다.

사용자 상한 설정#

전제 조건:

  • 관리자여야 합니다.

사용자 상한을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. User cap 필드에 숫자를 입력하거나 무제한으로 두려면 비워 둡니다.
  5. Save changes를 선택합니다.

사용자 상한 제거#

관리자 승인 없이 계정을 생성할 수 있는 새 사용자 수에 제한이 없도록 사용자 상한을 제거합니다.

사용자 상한을 제거한 후 승인 대기 중인 사용자는 자동으로 승인됩니다.

전제 조건:

  • 관리자여야 합니다.

사용자 상한을 제거하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. User cap에서 숫자를 제거합니다.
  5. Save changes를 선택합니다.

사용자 상한에서 제한된 접근으로 변경#

사용자 상한에서 제한된 접근으로 변경하면 모든 보류 중인 멤버(승인을 기다리는 멤버와 초대된 멤버 모두)가 자동으로 제거됩니다. 사용자가 멤버로 승인되도록 하려면 제한된 접근을 활성화하기 전에 보류 중인 멤버를 승인하거나 제거해야 합니다.

비밀번호 복잡도 요구 사항 수정#

기본적으로 사용자 비밀번호에는 제한된 수의 요구 사항이 있습니다. 요구 사항을 수정하여 최소 길이를 늘리거나 특정 문자 유형을 요구할 수 있습니다.

비밀번호 요구 사항을 변경해도 기존 사용자 비밀번호에는 영향을 미치지 않습니다. 수정된 복잡도 요구 사항은 다음 상황에서만 시행됩니다:

  • 새 사용자가 계정을 생성할 때.
  • 기존 사용자가 비밀번호를 재설정할 때.

비밀번호 복잡도 요구 사항을 수정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. 복잡도 요구 사항을 수정합니다:

    설정 설명
    Minimum password length 필요한 최소 문자 수를 설정합니다. 8자 미만 또는 128자 초과일 수 없습니다.
    Require numbers 비밀번호에 최소 하나의 숫자(0-9)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require uppercase letters 비밀번호에 최소 하나의 대문자(A-Z)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require lowercase letters 비밀번호에 최소 하나의 소문자(a-z)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require symbols 비밀번호에 최소 하나의 기호를 포함해야 합니다. Premium 및 Ultimate만 해당.
  5. Save changes를 선택합니다.

특정 이메일 도메인을 사용한 계정 생성 허용 또는 거부#

새 사용자 계정에 사용할 수 있는 이메일 도메인의 허용 또는 거부 목록을 지정할 수 있습니다.

이러한 제한은 외부 사용자의 새 계정 생성 시에만 적용됩니다. 관리자는 허용되지 않는 도메인을 가진 사용자를 관리자 패널을 통해 추가할 수 있습니다. 계정 생성 후 사용자는 허용되지 않는 도메인으로 이메일 주소를 변경할 수도 있습니다.

이메일 도메인 허용 목록#

사용자가 주어진 도메인 목록과 일치하는 이메일 주소를 가진 사용자 계정만 생성하도록 제한할 수 있습니다.

이메일 도메인 거부 목록#

특정 도메인의 이메일 주소를 사용할 때 사용자 가입을 차단할 수 있습니다. 이를 통해 일회용 이메일 주소로 스팸 계정을 만드는 악의적인 사용자의 위험을 줄일 수 있습니다.

이메일 도메인 허용 목록 또는 거부 목록 생성#

이메일 도메인 허용 목록 또는 거부 목록을 생성하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. 허용 목록의 경우 수동으로 목록을 입력해야 합니다. 거부 목록의 경우 수동으로 목록을 입력하거나 목록 항목이 포함된 .txt 파일을 업로드할 수 있습니다.

    허용 목록과 거부 목록 모두 와일드카드를 허용합니다. 예를 들어, *.company.com을 사용하여 모든 company.com 하위 도메인을 허용하거나 *.io를 사용하여 .io로 끝나는 모든 도메인을 차단할 수 있습니다. 도메인은 공백, 세미콜론, 쉼표 또는 새 줄로 구분해야 합니다.

    도메인 거부 목록 설정(파일 업로드 또는 수동 입력 옵션 포함)

LDAP 사용자 필터 설정#

LDAP 서버의 LDAP 사용자 일부로 GitLab 접근을 제한할 수 있습니다.

자세한 내용은 LDAP 사용자 필터 설정에 관한 문서를 참조하세요.

역할 승격에 관리자 승인 활성화#

히스토리
  • GitLab 16.9에서 member_promotion_management라는 플래그와 함께 도입됨.
  • 기능 플래그 member_promotion_management가 GitLab 17.5에서 wip에서 beta변경되고 기본적으로 활성화됨.
  • 기능 플래그 member_promotion_management가 GitLab 18.0에서 제거됨.

기존 사용자가 프로젝트나 그룹의 결제 역할로 승격되는 것을 방지하려면 역할 승격에 대한 관리자 승인을 활성화합니다. 그런 다음 관리자 승인이 대기 중인 승격 요청을 승인하거나 거부할 수 있습니다.

  • 관리자가 그룹이나 프로젝트에 사용자를 추가하는 경우:
    • 새 사용자 역할이 결제인 경우, 해당 사용자에 대한 다른 모든 멤버십 요청이 자동으로 승인됩니다.
    • 새 사용자 역할이 결제가 아닌 경우, 해당 사용자에 대한 다른 요청은 관리자 승인까지 보류 상태로 유지됩니다.
  • 관리자가 아닌 사용자가 그룹이나 프로젝트에 사용자를 추가하는 경우:
    • 사용자가 그룹이나 프로젝트에서 결제 역할이 없고 결제 역할로 추가되거나 승격되면, 해당 요청은 관리자 승인까지 보류 상태로 유지됩니다.
    • 사용자가 이미 결제 역할을 가지고 있으면 관리자 승인이 필요하지 않습니다.

전제 조건:

  • 관리자여야 합니다.

역할 승격에 대한 승인을 활성화하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. Seat control 섹션에서 Approve role promotions를 선택합니다.

    이 승인 요구 사항은 LDAP 동기화 또는 SAML 그룹 링크를 통해 부여된 멤버십에는 적용되지 않습니다. LDAP 또는 SAML을 통해 역할 승격을 받은 사용자는 이전에 결제 역할을 가졌는지와 관계없이 관리자 승인이 필요하지 않습니다.

새 사용자 계정 제한

Tier: Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

새 사용자 계정에 대해 다음과 같은 제한을 시행할 수 있습니다: 기본적으로 GitLab 도메인을 방문하는 모든 사용자가 계정을 생성할 수 있습니다. 다음 명령을 실행하여 Rails 콘솔로 새 사용자 계정 생성을 방지할 수도 있습니다:

새 사용자 계정에 대해 다음과 같은 제한을 시행할 수 있습니다:

  • 계정 생성 방지.
  • 새 계정에 관리자 승인 요구.
  • 사용자 이메일 확인 요구.
  • 특정 이메일 도메인을 사용한 새 계정 허용 또는 거부.

전제 조건#

관리자 접근 권한이 있어야 합니다.

새 사용자 계정 생성 비활성화#

기본적으로 GitLab 도메인을 방문하는 모든 사용자가 계정을 생성할 수 있습니다. 공개 GitLab 인스턴스를 운영하는 고객의 경우, 공개 사용자가 계정을 생성할 것으로 예상하지 않는다면 새 계정 생성을 비활성화하는 것을 강력히 권장합니다. GitLab Dedicated의 경우, 인스턴스가 프로비저닝될 때 기본적으로 새 계정 생성이 방지됩니다.

새 계정 생성을 방지하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Allow new user accounts 체크박스를 해제한 다음 Save changes를 선택합니다.

다음 명령을 실행하여 Rails 콘솔로 새 사용자 계정 생성을 방지할 수도 있습니다:

::Gitlab::CurrentSettings.update!(signup_enabled: false)

새 사용자 계정에 관리자 승인 요구#

이 설정은 새 GitLab 인스턴스에서 기본적으로 활성화되어 있습니다. 이 설정이 활성화되면 GitLab 도메인을 방문하여 등록 양식을 사용하여 새 계정을 생성하는 모든 사용자는 계정을 사용하기 전에 관리자로부터 명시적인 승인을 받아야 합니다. 이 설정은 사용자 계정이 허용된 경우에만 적용됩니다.

새 사용자 계정에 관리자 승인을 요구하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Require admin approval for new user accounts 체크박스를 선택한 다음 Save changes를 선택합니다.

관리자가 이 설정을 비활성화하면 승인 대기 중인 사용자는 백그라운드 job에서 자동으로 승인됩니다.

Note

이 설정은 LDAP 또는 OmniAuth 사용자에게는 적용되지 않습니다. OmniAuth 또는 LDAP를 사용하여 계정을 생성하는 새 사용자에 대한 승인을 시행하려면 OmniAuth 구성 또는 LDAP 구성에서 block_auto_created_userstrue로 설정하세요. 사용자 상한을 사용하여 새 사용자에 대한 승인을 시행할 수도 있습니다.

사용자 이메일 확인#

히스토리
  • GitLab 15.9에서 소프트 이메일 확인이 기능 플래그에서 애플리케이션 설정으로 변경됨.

계정 생성 시 확인 이메일을 보내고 사용자가 로그인하기 전에 이메일 주소를 확인해야 하도록 설정할 수 있습니다.

새 계정에 사용된 이메일 주소 확인을 시행하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. Email confirmation settings 아래에서 Hard를 선택합니다.

다음 설정을 사용할 수 있습니다:

  • Hard - 계정 생성 시 확인 이메일을 보냅니다. 새 사용자는 로그인하기 전에 이메일 주소를 확인해야 합니다.
  • Soft - 계정 생성 시 확인 이메일을 보냅니다. 새 사용자는 즉시 로그인할 수 있지만 3일 이내에 이메일을 확인해야 합니다. 3일 후 사용자는 이메일을 확인할 때까지 로그인할 수 없습니다.
  • Off - 새 사용자는 이메일 주소를 확인하지 않고 로그인할 수 있습니다.

제한된 접근#

히스토리

초과 요금을 방지하기 위해 제한된 접근을 사용하세요. 초과 요금은 구독의 라이선스 사용자 수를 초과할 때 발생하며, 다음 분기별 정산 시 지불해야 합니다.

제한된 접근을 활성화하면 구독에 남은 라이선스 시트가 없을 때 인스턴스에서 새 결제 사용자를 추가할 수 없습니다.

Note

인스턴스 또는 보류 중인 멤버가 있는 그룹에 사용자 상한이 활성화된 경우 제한된 접근을 활성화하면 보류 중인 모든 멤버가 그룹에서 자동으로 제거됩니다.

제한된 접근 활성화#

전제 조건:

  • 관리자여야 합니다.
  • 그룹 또는 하위 그룹이나 프로젝트 중 하나가 외부에서 공유되지 않아야 합니다.

제한된 접근을 활성화하려면:

  1. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  2. New user account restrictions를 확장합니다.
  3. Seat control 아래에서 Restricted access를 선택합니다.

제한된 접근을 활성화하면 그룹 계층 구조 외부의 그룹 초대 방지 설정이 자동으로 활성화됩니다. 이 설정은 초과 요금을 발생시킬 수 있는 새 결제 사용자가 예기치 않게 추가되는 것을 방지합니다.

필요에 따라 그룹 및 하위 그룹의 프로젝트 공유를 독립적으로 구성할 수 있습니다.

SAML, SCIM 및 LDAP를 통한 프로비저닝 동작#

히스토리

제한된 접근이 활성화되고 사용 가능한 구독 시트가 없는 경우, SAML, SCIM 또는 LDAP를 통해 프로비저닝된 사용자는 구성된 접근 수준 대신 최소 접근 권한이 할당됩니다. 이 동작은 GitLab.com 및 GitLab Self-Managed Ultimate에서 결제 시트를 소비하지 않고 동기화를 계속할 수 있도록 합니다.

최소 접근 권한을 가진 사용자는 인증하고 그룹에 접근할 수 있지만 제한된 권한을 가집니다. 시트가 가용해지면 사용자를 의도한 접근 수준으로 승격할 수 있습니다. 결제 역할을 가진 기존 사용자는 이 동작의 영향을 받지 않습니다.

시트 사용량 보기를 통해 최소 접근 권한을 가진 사용자를 관리할 수 있습니다.

알려진 문제#

제한된 접근을 활성화하면 다음과 같은 알려진 문제가 발생하여 초과가 발생할 수 있습니다:

  • 다음과 같은 경우 결제 사용자 수가 여전히 초과될 수 있습니다:
    • SAML, SCIM 또는 LDAP를 사용하여 새 멤버를 추가하고 구독의 시트 수를 초과한 경우. 최소 접근 폴백 기능이 활성화되면 사용자는 차단 대신 최소 접근 권한이 할당됩니다.
    • 관리자 접근 권한을 가진 여러 사용자가 동시에 멤버를 추가하는 경우.
    • 새 결제 사용자가 초대 수락을 지연하는 경우. 사용자를 초대하면 초대를 수락할 때까지 결제 시트를 소비하지 않습니다. 초대된 사용자가 수락을 지연하면 그 시간 동안 다른 사용자를 초대하고 추가할 수 있습니다. 지연된 사용자가 최종적으로 수락하면 결제 시트를 소비하며, 이미 시트 한도에 도달한 경우 초과가 발생할 수 있습니다.
  • 현재 구독보다 적은 사용자 수로 GitLab 영업팀을 통해 구독을 갱신하면 초과 요금이 발생합니다. 이 요금을 피하려면 갱신이 시작되기 전에 추가 사용자를 제거하세요. 예를 들어, 20명의 사용자가 있고 15명의 사용자로 구독을 갱신하면 5명의 추가 사용자에 대한 초과 요금이 부과됩니다.

또한 제한된 접근은 표준 비초과 흐름을 차단할 수 있습니다:

  • 결제 역할로 업데이트되거나 추가되는 서비스 봇이 잘못 차단됩니다.
  • 이메일을 통한 기존 결제 사용자 초대 또는 업데이트가 예기치 않게 차단됩니다.

사용자 상한#

사용자 상한은 관리자 승인 없이 구독에 계정을 생성하거나 추가될 수 있는 최대 결제 사용자 수입니다. 사용자 상한에 도달하면 계정을 생성하거나 추가되는 사용자는 관리자로부터 승인을 받아야 합니다. 사용자는 관리자의 승인 후에만 계정을 사용할 수 있습니다.

관리자가 사용자 상한을 늘리거나 제거하면 승인 대기 중인 사용자는 자동으로 승인됩니다.

결제 사용자 수는 하루에 한 번 업데이트됩니다. 상한이 이미 초과된 후에만 소급하여 적용될 수 있습니다. 상한이 현재 결제 사용자 수보다 낮은 값으로 설정되면(예: 1) 상한이 즉시 활성화됩니다.

개별 그룹에 대한 사용자 상한도 설정할 수 있습니다.

Note

LDAP 또는 OmniAuth를 사용하는 인스턴스의 경우, 새 사용자 계정에 대한 관리자 승인이 활성화되거나 비활성화될 때 Rails 구성 변경으로 인해 다운타임이 발생할 수 있습니다. 사용자 상한을 설정하여 새 사용자에 대한 승인을 시행할 수 있습니다.

사용자 상한 설정#

전제 조건:

  • 관리자여야 합니다.

사용자 상한을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. User cap 필드에 숫자를 입력하거나 무제한으로 두려면 비워 둡니다.
  5. Save changes를 선택합니다.

사용자 상한 제거#

관리자 승인 없이 계정을 생성할 수 있는 새 사용자 수에 제한이 없도록 사용자 상한을 제거합니다.

사용자 상한을 제거한 후 승인 대기 중인 사용자는 자동으로 승인됩니다.

전제 조건:

  • 관리자여야 합니다.

사용자 상한을 제거하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. New user account restrictions를 확장합니다.
  4. User cap에서 숫자를 제거합니다.
  5. Save changes를 선택합니다.

사용자 상한에서 제한된 접근으로 변경#

사용자 상한에서 제한된 접근으로 변경하면 모든 보류 중인 멤버(승인을 기다리는 멤버와 초대된 멤버 모두)가 자동으로 제거됩니다. 사용자가 멤버로 승인되도록 하려면 제한된 접근을 활성화하기 전에 보류 중인 멤버를 승인하거나 제거해야 합니다.

비밀번호 복잡도 요구 사항 수정#

기본적으로 사용자 비밀번호에는 제한된 수의 요구 사항이 있습니다. 요구 사항을 수정하여 최소 길이를 늘리거나 특정 문자 유형을 요구할 수 있습니다.

비밀번호 요구 사항을 변경해도 기존 사용자 비밀번호에는 영향을 미치지 않습니다. 수정된 복잡도 요구 사항은 다음 상황에서만 시행됩니다:

  • 새 사용자가 계정을 생성할 때.
  • 기존 사용자가 비밀번호를 재설정할 때.

비밀번호 복잡도 요구 사항을 수정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. 복잡도 요구 사항을 수정합니다:

    설정 설명
    Minimum password length 필요한 최소 문자 수를 설정합니다. 8자 미만 또는 128자 초과일 수 없습니다.
    Require numbers 비밀번호에 최소 하나의 숫자(0-9)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require uppercase letters 비밀번호에 최소 하나의 대문자(A-Z)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require lowercase letters 비밀번호에 최소 하나의 소문자(a-z)를 포함해야 합니다. Premium 및 Ultimate만 해당.
    Require symbols 비밀번호에 최소 하나의 기호를 포함해야 합니다. Premium 및 Ultimate만 해당.
  5. Save changes를 선택합니다.

특정 이메일 도메인을 사용한 계정 생성 허용 또는 거부#

새 사용자 계정에 사용할 수 있는 이메일 도메인의 허용 또는 거부 목록을 지정할 수 있습니다.

이러한 제한은 외부 사용자의 새 계정 생성 시에만 적용됩니다. 관리자는 허용되지 않는 도메인을 가진 사용자를 관리자 패널을 통해 추가할 수 있습니다. 계정 생성 후 사용자는 허용되지 않는 도메인으로 이메일 주소를 변경할 수도 있습니다.

이메일 도메인 허용 목록#

사용자가 주어진 도메인 목록과 일치하는 이메일 주소를 가진 사용자 계정만 생성하도록 제한할 수 있습니다.

이메일 도메인 거부 목록#

특정 도메인의 이메일 주소를 사용할 때 사용자 가입을 차단할 수 있습니다. 이를 통해 일회용 이메일 주소로 스팸 계정을 만드는 악의적인 사용자의 위험을 줄일 수 있습니다.

이메일 도메인 허용 목록 또는 거부 목록 생성#

이메일 도메인 허용 목록 또는 거부 목록을 생성하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. 허용 목록의 경우 수동으로 목록을 입력해야 합니다. 거부 목록의 경우 수동으로 목록을 입력하거나 목록 항목이 포함된 .txt 파일을 업로드할 수 있습니다.

    허용 목록과 거부 목록 모두 와일드카드를 허용합니다. 예를 들어, *.company.com을 사용하여 모든 company.com 하위 도메인을 허용하거나 *.io를 사용하여 .io로 끝나는 모든 도메인을 차단할 수 있습니다. 도메인은 공백, 세미콜론, 쉼표 또는 새 줄로 구분해야 합니다.

    도메인 거부 목록 설정(파일 업로드 또는 수동 입력 옵션 포함)

LDAP 사용자 필터 설정#

LDAP 서버의 LDAP 사용자 일부로 GitLab 접근을 제한할 수 있습니다.

자세한 내용은 LDAP 사용자 필터 설정에 관한 문서를 참조하세요.

역할 승격에 관리자 승인 활성화#

히스토리
  • GitLab 16.9에서 member_promotion_management라는 플래그와 함께 도입됨.
  • 기능 플래그 member_promotion_management가 GitLab 17.5에서 wip에서 beta변경되고 기본적으로 활성화됨.
  • 기능 플래그 member_promotion_management가 GitLab 18.0에서 제거됨.

기존 사용자가 프로젝트나 그룹의 결제 역할로 승격되는 것을 방지하려면 역할 승격에 대한 관리자 승인을 활성화합니다. 그런 다음 관리자 승인이 대기 중인 승격 요청을 승인하거나 거부할 수 있습니다.

  • 관리자가 그룹이나 프로젝트에 사용자를 추가하는 경우:
    • 새 사용자 역할이 결제인 경우, 해당 사용자에 대한 다른 모든 멤버십 요청이 자동으로 승인됩니다.
    • 새 사용자 역할이 결제가 아닌 경우, 해당 사용자에 대한 다른 요청은 관리자 승인까지 보류 상태로 유지됩니다.
  • 관리자가 아닌 사용자가 그룹이나 프로젝트에 사용자를 추가하는 경우:
    • 사용자가 그룹이나 프로젝트에서 결제 역할이 없고 결제 역할로 추가되거나 승격되면, 해당 요청은 관리자 승인까지 보류 상태로 유지됩니다.
    • 사용자가 이미 결제 역할을 가지고 있으면 관리자 승인이 필요하지 않습니다.

전제 조건:

  • 관리자여야 합니다.

역할 승격에 대한 승인을 활성화하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.

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

  3. New user account restrictions를 확장합니다.

  4. Seat control 섹션에서 Approve role promotions를 선택합니다.

    이 승인 요구 사항은 LDAP 동기화 또는 SAML 그룹 링크를 통해 부여된 멤버십에는 적용되지 않습니다. LDAP 또는 SAML을 통해 역할 승격을 받은 사용자는 이전에 결제 역할을 가졌는지와 관계없이 관리자 승인이 필요하지 않습니다.