가입 제한

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

다음의 가입 제한을 적용할 수 있습니다:

  • 새 가입 비활성화.
  • 새 가입에 대한 관리자 승인 요구.
  • 사용자 이메일 확인 요구.
  • 특정 이메일 도메인을 사용하여 가입 허용 또는 거부.

새 가입 비활성화

기본적으로, 귀하의 GitLab 도메인을 방문하는 모든 사용자는 계정을 생성할 수 있습니다. 공개적으로 노출되는 GitLab 인스턴스를 운영하는 고객에게는 공개 사용자가 계정을 생성할 것으로 예상하지 않는 경우 새 가입을 비활성화하는 것을 강력히 권장합니다.

가입을 비활성화하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가입 제한을 확장합니다.
  4. 가입 허용 체크박스를 지운 후 변경 사항 저장을 선택합니다.

다음 명령을 실행하여 Rails console에서 새 가입을 비활성화할 수도 있습니다:

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

새 가입에 대한 관리자 승인 요구

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

새 가입에 대한 관리자 승인 요구:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가입 제한을 확장합니다.
  4. 새 가입에 대한 관리자 승인 요구 체크박스를 선택한 후 변경 사항 저장을 선택합니다.

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

참고:
이 설정은 LDAP 또는 OmniAuth 사용자에게 적용되지 않습니다. OmniAuth 또는 LDAP를 사용하여 가입하는 새로운 사용자에 대한 승인을 강제하려면, OmniAuth 구성 또는 LDAP 구성에서 block_auto_created_users를 true로 설정하세요.
사용자 제한 또한 새로운 사용자에 대한 승인을 강제하는데 사용할 수 있습니다.

사용자 이메일 확인

  • 소프트 이메일 확인 변경됨 : GitLab 15.9에서 기능 플래그에서 애플리케이션 설정으로 전환되었습니다.

가입 중에 확인 이메일을 보내고 사용자가 로그인할 수 있도록 하기 전에 이메일 주소를 확인하도록 요구할 수 있습니다.

새 가입에 사용된 이메일 주소 확인을 강제하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가입 제한을 확장합니다.
  4. 이메일 확인 설정에서 Hard를 선택합니다.

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

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

사용자 한도

사용자 한도는 관리자의 승인이 없이 가입하거나 구독에 추가할 수 있는 최대 청구 사용자 수입니다. 사용자 한도가 도달하면, 가입하거나 추가된 사용자는 관리자의 승인을 받아야 합니다. 사용자는 관리자의 승인을 받은 후에만 계정을 사용할 수 있습니다.

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

그룹을 위한 사용자 한도를 설정하는 방법 보기.

참고: LDAP 또는 OmniAuth를 사용하는 인스턴스에서는 신규 가입에 대한 관리자 승인이 활성화되거나 비활성화될 때 Rails 구성 변경으로 인해 다운타임이 발생할 수 있습니다.

새 사용자의 승인을 강제 적용하기 위해 사용자 한도를 설정할 수 있습니다. 사용자 한도가 즉시 적용되도록 하려면, 현재 청구 사용자 수보다 낮은 값(예: 1)으로 설정하십시오.

사용자 한도 설정

관리자의 승인 없이 가입할 수 있는 사용자 수를 제한하기 위해 사용자 한도를 설정합니다.

청구 사용자 수는 하루에 한 번 업데이트됩니다.

사용자 한도는 이미 초과된 후에만 소급 적용될 수 있습니다.

한도가 즉시 적용되도록 하려면, 현재 청구 사용자 수보다 낮은 값(예: 1)으로 설정하십시오.

필수 조건:

  • 당신은 관리자여야 합니다.

사용자 한도를 설정하려면:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가입 제한을 확장합니다.
  4. 사용자 한도에 숫자를 입력합니다.
  5. 변경 사항 저장을 선택합니다.

사용자 한도 제거

관리자의 승인 없이 가입할 수 있는 신규 사용자 수에 제한이 없도록 사용자 한도를 제거합니다.

사용자 한도를 제거한 후에는 승인 대기 중인 사용자가 자동으로 승인됩니다.

필수 조건:

  • 당신은 관리자여야 합니다.

사용자 한도를 제거하려면:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가입 제한을 확장합니다.
  4. 사용자 한도에서 숫자를 제거합니다.
  5. 변경 사항 저장을 선택합니다.

제한된 접근 활성화

Tier: Premium, Ultimate Offering: GitLab.com
Status: Beta

-GitLab 17.5에서 도입되었습니다.

이 기능은 베타입니다.

제한된 접근을 사용하여 초과 요금을 방지하세요. 초과 요금은 구독의 좌석 수를 초과할 경우 발생하며, 다음 분기 정산에서 지불해야 합니다.

제한된 접근을 활성화하면, 구독의 좌석이 남아 있지 않을 때 그룹은 신규 청구 사용자를 추가할 수 없습니다.

필수 조건:

  • 당신은 그룹의 소유자 역할을 가지고 있어야 합니다.
  • 그룹이나 그 하위 그룹 또는 프로젝트는 외부와 공유되지 않아야 합니다.

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

  1. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
  2. 권한 및 그룹 기능을 확장합니다.
  3. 좌석 제어 아래에서 제한된 접근을 선택합니다.

알려진 문제

제한된 접근을 활성화할 때 다음과 같은 알려진 문제가 발생할 수 있으며, 이로 인해 초과가 발생할 수 있습니다:

  • 좌석 수는 여전히 초과될 수 있습니다:
    • SAML 또는 SCIM을 사용하여 신규 구성원을 추가하고, 구독의 좌석 수를 초과한 경우.
    • 여러 사용자가 소유자 역할로 동시에 구성원을 추가하는 경우.
    • 신규 청구 구성원이 초대를 수락하는 데 지연이 발생하는 경우.
    • 사용자 한도에서 제한된 접근으로 변경하고, 제한된 접근으로 변경하기 전에 승인 대기 중인 구성원이 있는 경우. 이 경우, 해당 구성원은 대기 상태에 남아 있습니다. 대기 중인 구성원이 제한된 접근을 사용하는 동안 승인되면, 구독의 좌석 수를 초과할 수 있습니다.
  • GitLab 판매 팀을 통해 현재 구독보다 적은 사용자 수로 구독을 갱신하는 경우 초과 요금이 발생합니다. 이 요금을 피하려면 갱신 시작 전에 추가 사용자를 제거하십시오. 예를 들어:
    • 사용자가 20명 있습니다.
    • 15명의 사용자 수로 구독을 갱신합니다.
    • 5명의 추가 사용자로 인해 초과 요금이 청구됩니다.

최소 비밀번호 길이 제한

사용자는 GitLab UI를 사용하여 비밀번호의 최소 문자 수를 변경할 수 있습니다.

비밀번호 복잡성 요구사항

Tier: Premium, Ultimate Offering: Self-managed

기본적으로 사용자 비밀번호에 대한 유일한 요구사항은 최소 비밀번호 길이입니다.
추가적인 복잡성 요구사항을 추가할 수 있습니다. 비밀번호 복잡성 요구사항에 대한 변경 사항은 새로운 비밀번호에 적용됩니다:

  • 새로 가입하는 사용자에게
  • 비밀번호를 재설정하는 기존 사용자에게

기존 비밀번호에는 영향을 미치지 않습니다. 비밀번호 복잡성 요구사항을 변경하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Sign-up restrictions를 확장합니다.
  4. 최소 비밀번호 길이(문자 수) 아래에서 추가 비밀번호 복잡성 요구 사항을 선택합니다. 숫자, 대문자, 소문자 및 기호를 요구할 수 있습니다.
  5. 변경 사항 저장을 선택합니다.

특정 이메일 도메인을 사용하여 가입 허용 또는 차단하기

사용자가 가입할 때 사용할 수 있는 이메일 도메인에 대한 포괄적이거나 배제된 목록을 지정할 수 있습니다.

이러한 제한은 외부 사용자가 가입할 때만 적용됩니다. 관리자는 허용되지 않는 도메인을 사용하여 관리 패널을 통해 사용자를 추가할 수 있습니다. 사용자는 또한 가입 후 허용되지 않는 도메인으로 이메일 주소를 변경할 수 있습니다.

허용된 이메일 도메인

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

차단된 이메일 도메인

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

이메일 도메인 허용 목록 또는 차단 목록 만들기

이메일 도메인 허용 목록 또는 차단 목록을 만들려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Sign-up restrictions를 확장합니다.

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

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

    파일을 업로드하거나 수동으로 차단 목록을 입력할 수 있는 도메인 차단 목록 설정 이미지

LDAP 사용자 필터 설정

LDAP 서버의 LDAP 사용자 하위 집합에 대한 GitLab 액세스를 제한할 수 있습니다.

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

역할 승격 승인 활성화

Tier: Ultimate Offering: Self-managed, GitLab Dedicated
Status: Beta
  • GitLab 16.9에서 플래그 member_promotion_management와 함께 도입됨.
  • 기능 플래그 member_promotion_management는 변경됨 및 GitLab 17.5에서 기본적으로 활성화됨.

이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다.

Ultimate 계층에서는 청구되지 않는 역할을 프로젝트 또는 그룹에서 청구되는 역할로 승격할 수 있으며, 이로 인해 청구되는 좌석 수가 증가하며, 관리자는 이 승격에 대한 아무런 제어권을 가지지 않습니다.
구독의 기존 사용자가 청구되는 역할로 승격되는 것을 방지하기 위해 역할 승격 승인을 활성화할 수 있습니다.

이 설정이 활성화되면, 청구되는 역할에서 그룹 또는 프로젝트로 추가되는 기존 구독 사용자는 관리자 승인 대기 상태가 됩니다.

청구되는 좌석을 이미 차지하고 있는 사용자의 사용자 역할에 대한 승격이나 업데이트는 관리자 승인을 요구하지 않습니다.

관리자가 그룹 또는 프로젝트에 사용자를 추가하는 경우, 해당 사용자가 다른 그룹이나 프로젝트에 대한 모든 멤버십 요청은 자동으로 승인됩니다.

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

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Sign-up restrictions를 확장합니다.
  4. Seat controls 섹션에서 Approve role promotions을 선택합니다.

알려진 문제

역할 승격 승인을 켜면, 사용자가 그룹에 대한 액세스를 요청하고 그룹 소유자가 청구 역할로 승인을 받을 경우, 청구 가능한 수가 여전히 증가할 수 있습니다.