그룹 권한 및 액세스를 제어하도록 그룹을 구성합니다. 자세한 내용은 프로젝트 및 그룹 공유를 참조하세요.

Git 액세스 프로토콜 제한#

그룹의 저장소에 접근하는 데 허용된 프로토콜을 SSH, HTTPS 또는 둘 다로 설정할 수 있습니다. 이 설정은 관리자가 인스턴스 설정을 구성한 경우 비활성화됩니다.

그룹의 허용된 Git 액세스 프로토콜을 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 펼칩니다.
4. 활성화된 Git 액세스 프로토콜에서 허용할 프로토콜을 선택합니다.
5. 변경 사항 저장을 선택합니다.

IP 주소로 그룹 액세스 제한#

조직의 사람들만 특정 리소스에 액세스할 수 있도록 하려면 IP 주소로 그룹 액세스를 제한할 수 있습니다. 이 최상위 그룹 설정은 다음에 적용됩니다:

• 서브그룹, 프로젝트, 이슈를 포함한 GitLab UI. GitLab Pages에는 적용되지 않습니다.
• API.
• GitLab Self-Managed에서는 그룹에 대해 전역 허용 IP 주소 범위를 구성할 수도 있습니다.

관리자는 IP 주소로 제한된 액세스를 전역 허용 IP 주소와 결합할 수 있습니다.

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

IP 주소로 그룹 액세스를 제한하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.

3. 권한 및 그룹 기능 섹션을 펼칩니다.

4. IP 주소로 액세스 제한 텍스트 상자에 CIDR 표기법으로 IPv4 또는 IPv6 주소 범위 목록을 입력합니다:

   192.168.1.0/24
   10.0.0.0/8
   2001:db8::/32
   203.0.113.5/32
   

   각 IP 주소 항목을 수동으로 추가해야 합니다. 쉼표나 공백으로 구분된 여러 항목 추가는 지원되지 않습니다. 일괄 항목 지원은 이슈 468998에서 제안되었습니다.

   이 목록은:

   • IP 주소 범위 수에 제한이 없습니다.
   • SSH 및 HTTP 승인된 IP 주소 범위 모두에 적용됩니다. 이 목록을 인증 유형별로 분리할 수 없습니다.

5. 변경 사항 저장을 선택합니다.

보안 영향#

IP 액세스 제한은 그룹 및 프로젝트에 대한 액세스를 제한하지만 완전한 방화벽은 아닙니다. 이 기능은 일반적으로 그룹 및 프로젝트 리소스에 대한 액세스를 제한하지만, 일부 정보는 여전히 제한된 사용자에게 접근 가능할 수 있습니다. 허용되지 않은 IP 주소에서 GitLab에 접근할 때 다음의 (비포괄적인) 보안 영향 목록을 염두에 두세요:

• 관리자와 그룹 Owner는 항상 그룹 설정에 액세스할 수 있습니다.
• 관리자는 항상 그룹의 프로젝트에 액세스할 수 있습니다. 여기에는 코드 클론도 포함됩니다.
• 그룹 Owner는 항상 서브그룹에 액세스할 수 있지만, 그룹이나 서브그룹의 프로젝트에는 접근할 수 없습니다.
• 사용자는 항상 공유 리소스에 액세스할 수 있습니다.
• 사용자는 항상 그룹 및 프로젝트의 이름과 계층 구조를 볼 수 있습니다.
• 사용자는 항상 이메일 회신 기능을 사용하여 이슈 또는 머지 리퀘스트에 댓글을 만들고 편집할 수 있습니다.
• 사용자는 때때로 대시보드에서 푸시, 머지, 이슈 또는 댓글 이벤트를 볼 수 있습니다.
• IP 제한은 항상 공개 프로젝트에 적용되지만, 캐시된 프로젝트 파일이 때때로 접근 가능할 수 있습니다.
• IP 제한은 항상 GitLab.com 및 GitLab Dedicated에서 SSH를 통한 Git 작업에 적용됩니다. GitLab Self-Managed 인스턴스는 PROXY 프로토콜이 활성화된 gitlab-sshd를 사용해야 합니다.
• IP 제한은 항상 CI/CD 작업이 수행하는 Git clone 작업에 적용됩니다.
• IP 제한은 러너 등록이나 러너가 CI/CD 작업을 요청하거나 업데이트할 때는 적용되지 않습니다.
• IP 제한은 포크된 프로젝트나 IP 제한된 그룹의 이슈 또는 아티팩트와 간접적으로 상호 작용하는 작업에는 적용되지 않을 수 있습니다. 예를 들어, 머지 리퀘스트 설명에서 이슈 참조를 사용하여 IP 제한된 그룹의 이슈를 닫는 머지 리퀘스트.
• IP 제한은 프로젝트 및 그룹 액세스 토큰, 서비스 계정, 배포 키, 배포 토큰에 적용됩니다.

GitLab.com 액세스 제한#

IP 주소 기반 그룹 액세스 제한은 GitLab.com의 호스팅된 러너에서 작동하지 않습니다. 이러한 러너는 대형 클라우드 제공업체 풀(AWS, Google Cloud)에서 동적 IP 주소를 가진 임시 가상 머신으로 작동합니다. 이러한 광범위한 IP 범위를 허용하면 IP 주소 기반 액세스 제한의 목적이 무효화됩니다.

도메인으로 그룹 액세스 제한#

최상위 네임스페이스에서 이메일 도메인 허용 목록을 정의하여 그룹 및 해당 프로젝트에 액세스할 수 있는 사용자를 제한할 수 있습니다. 사용자의 기본 이메일 도메인이 해당 그룹에 액세스하기 위한 허용 목록의 항목과 일치해야 합니다. 서브그룹은 동일한 허용 목록을 상속합니다.

도메인으로 그룹 액세스를 제한하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 펼칩니다.
4. 이메일 도메인으로 멤버십 제한 텍스트 상자에 허용할 도메인 이름을 입력합니다.
5. 변경 사항 저장을 선택합니다.

다음에 그룹에 사용자를 추가하려고 할 때 해당 사용자의 기본 이메일이 허용된 도메인 중 하나와 일치해야 합니다.

다음과 같은 가장 인기 있는 공개 이메일 도메인을 사용하여 제한할 수 없습니다:

• aol.com, gmail.com, hotmail.co.uk, hotmail.com,
• hotmail.fr, icloud.com, live.com, mail.com,
• me.com, msn.com, outlook.com,
• proton.me, protonmail.com, tutanota.com,
• yahoo.com, yandex.com, zohomail.com

그룹을 공유할 때 소스 네임스페이스와 대상 네임스페이스 모두 멤버의 이메일 주소 도메인을 허용해야 합니다.

사용자의 그룹 액세스 요청 방지#

그룹 Owner는 비멤버가 그룹에 대한 액세스를 요청하지 못하도록 할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 펼칩니다.
4. 사용자의 액세스 요청 허용 체크박스를 선택 해제합니다.
5. 변경 사항 저장을 선택합니다.

그룹 외부로의 프로젝트 포크 방지#

기본적으로 그룹의 프로젝트는 포크할 수 있습니다. 그러나 그룹의 프로젝트가 현재 최상위 그룹 외부로 포크되는 것을 방지할 수 있습니다.

사전 요구사항:

• 이 설정은 최상위 그룹에서만 활성화됩니다.
• 모든 서브그룹은 최상위 그룹으로부터 이 설정을 상속받으며, 서브그룹 수준에서는 변경할 수 없습니다.

그룹 외부로 프로젝트가 포크되지 않도록 하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 펼칩니다.
4. 현재 그룹 외부로의 프로젝트 포크 방지를 선택합니다.
5. 변경 사항 저장을 선택합니다.

기존 포크는 제거되지 않습니다.

그룹의 프로젝트에 멤버 추가 방지#

그룹 Owner는 그룹의 모든 프로젝트에 대한 새 프로젝트 멤버십을 방지하여 프로젝트 멤버십에 대한 더 엄격한 제어를 허용할 수 있습니다.

예를 들어, 감사 이벤트를 위해 그룹을 잠그려는 경우 감사 중에 프로젝트 멤버십을 수정할 수 없도록 보장할 수 있습니다.

그룹 멤버십 잠금이 활성화된 경우에도 그룹 Owner는 다음을 수행할 수 있습니다:

• 잠긴 그룹의 프로젝트에 대한 액세스 권한을 부여하기 위해 그룹에 그룹을 초대하거나 멤버를 추가합니다.
• 그룹 멤버의 역할을 변경합니다.

이 설정은 계단식으로 적용되지 않습니다. 서브그룹의 프로젝트는 상위 그룹을 무시하고 서브그룹 구성을 따릅니다.

그룹의 프로젝트에 멤버가 추가되지 않도록 하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 펼칩니다.
4. 멤버십에서 이 그룹의 프로젝트에 사용자를 추가할 수 없음을 선택합니다.
5. 변경 사항 저장을 선택합니다.

그룹 멤버십을 잠근 후:

• 이전에 권한을 가졌던 모든 사용자는 더 이상 그룹에 멤버를 추가할 수 없습니다.
• 프로젝트에 새 사용자를 추가하는 API 요청이 불가능합니다.

LDAP로 그룹 멤버십 관리#

그룹 동기화를 통해 LDAP 그룹을 GitLab 그룹에 매핑할 수 있습니다. 이를 통해 그룹별 사용자 관리에 대한 더 많은 제어가 가능합니다. 그룹 동기화를 구성하려면 group_base DN('OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org')을 편집합니다. 이 OU에는 GitLab 그룹과 연결된 모든 그룹이 포함됩니다.

그룹 링크는 CN 또는 필터를 사용하여 생성할 수 있습니다. 이러한 그룹 링크를 생성하려면 그룹의 설정 > LDAP 동기화 페이지로 이동합니다. 링크를 구성한 후 사용자가 GitLab 그룹과 동기화되는 데 한 시간 이상 걸릴 수 있습니다. 링크를 구성한 후:

• GitLab 16.7 이하에서는 그룹 Owner가 그룹에서 멤버를 추가하거나 제거할 수 없습니다. LDAP 서버는 LDAP 자격 증명으로 로그인한 모든 사용자의 그룹 멤버십에 대한 단일 신뢰 소스로 간주됩니다.
• GitLab 16.8 이상에서는 그룹 Owner가 LDAP 동기화가 그룹에 활성화된 경우에도 멤버 역할 API 또는 그룹 멤버 API를 사용하여 서비스 계정 사용자를 그룹에 추가하거나 제거할 수 있습니다. 그룹 Owner는 서비스 계정이 아닌 사용자를 추가하거나 제거할 수 없습니다.

사용자가 동일한 GitLab 그룹에 구성된 두 LDAP 그룹에 속한 경우, GitLab은 두 연결된 역할 중 더 높은 역할을 할당합니다. 예를 들어:

• 사용자가 LDAP 그룹 Owner 및 Dev의 멤버입니다.
• GitLab 그룹은 이 두 LDAP 그룹으로 구성됩니다.
• 그룹 동기화가 완료되면 Owner가 두 LDAP 그룹 역할 중 더 높은 역할이므로 사용자에게 Owner 역할이 부여됩니다.

LDAP 관리 및 그룹 동기화에 대한 자세한 내용은 주요 LDAP 문서를 참조하세요.

LDAP 그룹을 통한 프로젝트 액세스 관리에 대한 해결 방법을 사용할 수 있습니다.

CN으로 그룹 링크 생성#

LDAP 그룹 CN으로 그룹 링크를 생성하려면:

1. 링크의 LDAP 서버를 선택합니다.
2. 동기화 방법으로 LDAP Group cn을 선택합니다.
3. LDAP Group cn 필드에 그룹의 CN을 입력하기 시작합니다. 구성된 group_base에서 일치하는 CN이 있는 드롭다운 목록이 있습니다. 이 목록에서 CN을 선택합니다.
4. LDAP 액세스 섹션에서 이 그룹에서 동기화된 사용자를 위한 기본 역할 또는 사용자 정의 역할을 선택합니다.
5. 동기화 추가를 선택합니다.

필터로 그룹 링크 생성#

LDAP 사용자 필터로 그룹 링크를 생성하려면:

1. 링크의 LDAP 서버를 선택합니다.
2. 동기화 방법으로 LDAP user filter를 선택합니다.
3. LDAP 사용자 필터 상자에 필터를 입력합니다. 사용자 필터 문서를 따르세요.
4. LDAP 액세스 섹션에서 이 그룹에서 동기화된 사용자를 위한 기본 역할 또는 사용자 정의 역할을 선택합니다.
5. 동기화 추가를 선택합니다.

그룹 링크 제거#

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 활성 동기화를 선택합니다.
3. 제거하려는 그룹 링크를 확인하고 제거를 선택합니다.

사용자 권한 재정의#

LDAP 사용자 권한은 관리자가 수동으로 재정의할 수 있습니다. 사용자의 권한을 재정의하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 관리 > 멤버를 선택합니다. LDAP 동기화가 다음과 같은 역할을 사용자에게 부여한 경우:
   • 상위 그룹 멤버십보다 더 많은 권한: 해당 사용자는 그룹의 직접 멤버십을 가진 것으로 표시됩니다.
   • 상위 그룹 멤버십과 동일하거나 더 적은 권한: 해당 사용자는 그룹의 상속된 멤버십을 가진 것으로 표시됩니다.
3. 선택사항. 편집하려는 사용자가 상속된 멤버십을 가진 것으로 표시되는 경우, LDAP 사용자 권한을 재정의하기 전에 서브그룹을 필터링하여 직접 멤버를 표시합니다.
4. 편집 중인 사용자의 행에서 연필 (✏️) 아이콘을 선택합니다.
5. 대화 상자에서 권한 편집을 선택합니다.

이제 멤버 페이지에서 사용자의 권한을 편집할 수 있습니다.

파이프라인 변수를 사용할 수 있는 기본 역할 설정#

이 그룹 설정은 파이프라인 변수로 새 파이프라인을 실행할 수 있는 최소 역할 프로젝트 설정의 기본값을 제어합니다. 그룹에서 생성된 새 프로젝트는 기본적으로 이 값이 선택됩니다.

사전 요구사항:

• 그룹에서 Maintainer 또는 Owner 역할이 있어야 합니다.
• 그룹은 서브그룹이 아닌 최상위 그룹이어야 합니다.

기본 최소 역할을 설정하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 설정 > CI/CD > 변수를 선택합니다.
3. 파이프라인 변수를 사용할 기본 역할에서 최소 역할을 선택하거나, 어떤 사용자도 파이프라인 변수를 사용하지 못하도록 허용 안 함을 선택합니다.
4. 변경 사항 저장을 선택합니다.

새 프로젝트가 생성된 후, Maintainer 또는 Owner 역할을 가진 프로젝트 멤버는 필요한 경우 프로젝트 설정을 다른 값으로 변경할 수 있습니다.

문제 해결#

IP 제한으로 액세스가 차단되었는지 확인#

사용자가 특정 그룹에 액세스하려고 할 때 404 오류가 표시되면, IP 제한으로 인해 액세스가 차단되었을 수 있습니다.

auth.log rails 로그에서 다음 항목 중 하나 이상을 검색합니다:

• json.message: 'Attempting to access IP restricted group'
• json.allowed: false

로그 항목을 볼 때 remote.ip를 그룹의 허용된 IP 주소 목록과 비교합니다.

그룹 멤버의 권한을 업데이트할 수 없음#

그룹 Owner가 그룹 멤버의 권한을 업데이트할 수 없는 경우, 어떤 멤버십이 나열되어 있는지 확인합니다. 그룹 Owner는 직접 멤버십만 업데이트할 수 있습니다.

서브그룹에 직접 추가된 멤버는 상위 그룹에서 동일하거나 더 높은 역할을 가진 경우에도 여전히 상속된 멤버로 간주됩니다.

직접 멤버십을 보고 업데이트하려면 그룹을 필터링하여 직접 멤버를 표시합니다.

이슈 337539에서는 유형별 필터링 기능과 함께 직접 및 간접 멤버십 모두를 나열하는 재설계된 멤버 페이지를 제안하고 있습니다.

IP 제한 활성화 후 SSH를 통한 클론 또는 풀 불가#

IP 주소 제한을 추가한 후 Git SSH 작업에 문제가 있는 경우, 연결이 IPv6을 기본으로 사용하는지 확인합니다.

일부 운영 체제는 두 가지가 모두 사용 가능할 때 IPv4보다 IPv6을 우선시하는데, 이는 Git 터미널 피드백에서 명확하지 않을 수 있습니다.

연결이 IPv6을 사용하는 경우 허용 목록에 IPv6 주소를 추가하여 이 문제를 해결할 수 있습니다.