GitLab 전용 인스턴스 구성

Tier: Ultimate Offering: GitLab Dedicated

이 페이지의 지침은 GitLab Dedicated 인스턴스를 구성하는 방법, 즉 사용 가능한 기능의 설정을 활성화 및 업데이트하는 방법을 안내합니다.

GitLab 애플리케이션에서 SaaS 환경에 의해 제어되지 않는 모든 기능은 Admin 영역을 사용하여 구성할 수 있습니다.

SaaS 환경 설정의 예로는 gitlab.rb 구성 및 셸, Rails 콘솔 및 PostgreSQL 콘솔에 대한 액세스가 있습니다.
이러한 환경 설정은 테넌트에 의해 변경될 수 없습니다.

GitLab Dedicated 엔지니어는 긴급 상황을 제외하고 테넌트 환경에 직접 액세스할 수 없습니다.

인스턴스는 GitLab Dedicated 배포를 의미하고, 테넌트는 고객을 의미합니다.

구성 변경

Switchboard를 사용하여 인스턴스 구성

Switchboard를 사용하여 GitLab Dedicated 인스턴스에 대한 제한된 구성 변경을 할 수 있습니다.

Switchboard에서 사용할 수 있는 구성 설정은 다음과 같습니다:

IP 허용 목록
SAML 설정
사용자 지정 인증서

사전 조건:

Admin 역할이 있어야 합니다.

구성 변경을 하려면:

Switchboard에 로그인합니다.
페이지 상단에서 Configuration을 선택합니다.
아래의 관련 섹션의 지침을 따릅니다.

인스턴스 구성의 다른 모든 경우, 구성 변경 요청 정책에 따라 지원 티켓을 제출합니다.

Switchboard에서 구성 변경 적용

Switchboard에서 수행된 구성 변경은 즉시 적용하거나 다음 예약된 주간 유지 관리 창까지 연기할 수 있습니다.

변경 사항을 즉시 적용할 경우:

배포는 최대 90분이 소요될 수 있습니다.
변경 사항은 저장된 순서대로 적용됩니다.
여러 변경 사항을 저장하고 한 번에 배포할 수 있습니다.

배포 후, 이메일 알림을 받게 됩니다. 메인 수신함에 보이지 않으면 스팸 폴더를 확인하세요.
Switchboard에서 테넌트를 보고 편집할 수 있는 모든 사용자는 각 변경 사항에 대해 알림을 받습니다. 자세한 내용은 Switchboard 알림 기본 설정 관리를 참조하세요.

Switchboard 테넌트 관리자가 수행한 변경 사항에 대해서만 이메일 알림을 받습니다. 유지 관리 창 동안 완료된 GitLab 버전 업데이트와 같은 GitLab 운영자가 수행한 변경 사항은 이메일 알림을 트리거하지 않습니다.

구성 변경 로그 보기

구성 변경 로그를 사용하여 GitLab Dedicated 인스턴스에 대한 변경 사항을 추적할 수 있습니다, 여기에는 다음이 포함됩니다:

구성 변경: 변경된 구성 설정의 이름.
사용자: 구성 변경을 수행한 사용자의 이메일 주소. GitLab 운영자가 수행한 변경사항에 대해서는 GitLab Operator로 표시됩니다.
IP: 구성 변경을 수행한 사용자의 IP 주소. GitLab 운영자가 수행한 변경사항에 대해서는 사용 불가능로 표시됩니다.
상태: 구성 변경이 시작됨, 진행 중, 완료되었거나 연기되었는지를 나타냅니다.
시작 시간: 구성 변경이 시작되었을 때의 날짜 및 시간 (UTC).
종료 시간: 구성 변경이 배포되었을 때의 날짜 및 시간 (UTC).

각 구성 변경에는 상태가 있습니다:

시작됨: Switchboard에서 구성 변경이 이루어졌지만 인스턴스에 배포되지 않았습니다.
진행 중: 구성 변경이 인스턴스에 활성으로 배포되고 있습니다.
완료: 구성 변경이 인스턴스에 배포되었습니다.
지연됨: 변경 사항을 배포하는 초기 작업이 실패하였고 변경 사항이 새 작업에 할당되지 않았습니다.

구성 변경 로그를 보려면:

Switchboard에 로그인합니다.
테넌트를 선택합니다.
페이지 상단에서 Configuration change log를 선택합니다.

구성 변경 요청 정책

이 정책은 Switchboard를 사용하는 GitLab 전용 인스턴스 관리자가 수행한 구성 변경에는 적용되지 않습니다.

support ticket로 요청한 구성 변경:

귀하의 환경에서 주간 4시간 유지보수 기간 동안 적용됩니다.
온보딩 중에 지정된 옵션이나 이 페이지에 나열된 선택적 기능에 대해 요청할 수 있습니다.
GitLab이 고우선 유지보수 작업을 수행해야 하는 경우 다음 주로 연기될 수 있습니다.
비상 지원 자격이 없으면 주간 유지보수 기간 외에는 적용될 수 없습니다.

주의:

변경 요청이 최소 리드 타임을 충족하더라도, 다가오는 유지보수 기간 동안 적용되지 않을 수 있습니다.

도메인 가져오기 (BYOD)

GitLab 전용 인스턴스에 대해 사용자 정의 호스트 이름을 추가할 수 있습니다. 선택적으로, 번들된 컨테이너 레지스트리 및 KAS 서비스에 대한 사용자 정의 호스트 이름을 제공할 수도 있습니다.

전제 조건:

DNS 레코드를 설정하기 위해 도메인 서버 제어판에 접근해야 합니다.

DNS 레코드 설정

사용자 정의 도메인은 다음이 필요합니다:

CNAME 레코드: 사용자 정의 호스트 이름을 tenant_name.gitlab-dedicated.com으로 지정하는 CNAME 레코드를 추가하세요.
```
gitlab.my-company.com.  CNAME  tenant_name.gitlab-dedicated.com
```
CAA 레코드: 도메인에 기존의 CAA (인증 기관 승인) 레코드가 있는 경우, Let’s Encrypt용 CAA 레코드를 추가하세요. 이는 Let’s Encrypt가 귀하의 도메인에 대한 인증서도 발급할 수 있도록 허용합니다.
```
example.com.  IN  CAA 0 issue "pki.goog"
example.com.  IN  CAA 0 issue "letsencrypt.org"
```
이 예에서 CAA 레코드는 Google Trust Services ("pki.goog") 및 Let’s Encrypt ("letsencrypt.org")를 귀하의 도메인에 대한 인증서를 발급할 수 있는 인증 기관으로 정의합니다.

사용자 정의 호스트 이름 추가

인스턴스가 생성된 후 사용자 정의 호스트 이름을 추가하려면 support ticket를 제출하세요.

SMTP 이메일 서비스

GitLab 전용 인스턴스에 대한 SMTP 이메일 서비스를 구성할 수 있습니다.

SMTP 이메일 서비스를 구성하려면 SMTP 서버의 자격 증명 및 설정과 함께 support ticket를 제출하세요.

수신 개인 링크

AWS Private Link는 AWS 내 VPC의 사용자와 애플리케이션이 공용 인터넷을 통하지 않고 GitLab 전용 엔드포인트에 안전하게 연결할 수 있도록 합니다.

수신 개인 링크를 활성화하려면:

support ticket를 엽니다. 지원 요청의 본문에, AWS 계정 내 VPC 엔드포인트를 설정하는 AWS 사용자 또는 역할에 대한 IAM 원칙을 포함합니다. IAM 원칙은 IAM 역할 원칙 또는 IAM 사용자 원칙이어야 합니다. GitLab 전용은 이러한 IAM 원칙을 액세스 제어에 사용합니다. 이러한 IAM 원칙만이 서비스에 대한 엔드포인트를 설정할 수 있습니다.
IAM 원칙이 허용 목록에 추가된 후, GitLab은 엔드포인트 서비스를 생성하고 지원 요청에 서비스 엔드포인트 이름을 전달합니다. 서비스 이름은 서비스 엔드포인트 생성 시 AWS에서 생성됩니다.
- GitLab은 Private DNS 이름에 대한 도메인 검증을 처리하므로 귀하의 VPC에서 테넌트 인스턴스 도메인 이름의 DNS 해상도가 PrivateLink 엔드포인트로 해결됩니다.
- 엔드포인트 서비스는 두 개의 가용성 영역에서 제공됩니다. 이는 온보딩 중 선택한 영역이거나 지정하지 않은 경우 무작위로 선택된 두 개의 영역입니다.
자신의 AWS 계정에서, 다음 설정으로 VPC 내에 엔드포인트 인터페이스를 생성합니다:
- 서비스 엔드포인트 이름: 지원 요청에 GitLab이 제공한 이름을 사용합니다.
- 개인 DNS 이름 활성화: 예.
- 서브넷: 모든 일치하는 서브넷을 선택합니다.
엔드포인트를 생성한 후 온보딩 중 제공된 인스턴스 URL을 사용하여 공용 인터넷을 통하지 않고 VPC에서 GitLab 전용 인스턴스에 안전하게 연결합니다.

아웃바운드 프라이빗 링크

아웃바운드 프라이빗 링크는 GitLab Dedicated 인스턴스와 GitLab Dedicated를 위한 호스팅 러너가 AWS의 VPC에서 실행 중인 서비스와 안전하게 통신할 수 있도록 하며, 공개 인터넷에 트래픽을 노출하지 않습니다.

이런 유형의 연결은 GitLab 기능이 개인 서비스에 접근할 수 있도록 합니다:

GitLab Dedicated 인스턴스의 경우:
- 웹훅
- 프로젝트 및 저장소 가져오기 또는 미러링
호스팅 러너의 경우:
- 사용자 정의 비밀 관리기
- 인프라에 저장된 아티팩트 또는 작업 이미지
- 인프라에 배포

다음 사항을 고려하세요:

VPC가 같은 지역에 있을 때만 프라이빗 링크를 설정할 수 있습니다. 따라서, Dedicated 인스턴스에 지정된 지역에서만 연결을 설정할 수 있습니다.
연결을 위해 온보딩 중에 선택한 지역의 두 개의 가용 영역(AZ)의 가용 영역 ID(AZ IDs)가 필요합니다.
전용으로 온보딩할 때 AZ를 지정하지 않으면, GitLab이 두 AZ ID를 무작위로 선택합니다.

Reverse Private Link IAM Principal 속성은 Switchboard의 테넌트 세부정보 섹션에서 확인할 수 있습니다.

아웃바운드 프라이빗 링크를 활성화하려면:

엔드포인트 서비스 생성하여 내부 서비스가 GitLab Dedicated에 사용할 수 있도록 합니다. 관련 서비스 엔드포인트 이름을 새로운 지원 티켓에 제공하세요.
Dedicated 인스턴스가 배포된 두 개의 AZ에 대해 엔드포인트 서비스용 네트워크 로드 밸런서(NLB)가 구성되어 있는지 확인합니다. 온보딩 중에 이를 지정하지 않았다면 다음 중 하나를 수행해야 합니다:
- 지원 티켓을 제출하여 연결을 활성화하는 데 필요한 AZ ID를 요청하고 NLB가 해당 AZ에서 활성화되도록 합니다.
- 지역의 모든 AZ에서 NLB가 활성화되었는지 확인합니다.
지원 티켓에서 GitLab은 엔드포인트 서비스에 연결을 시작할 IAM 역할의 ARN을 제공합니다. 이 ARN이 “허용된 주체” 목록에 포함되도록 하거나 다른 항목으로 커버되도록 해야 합니다. 이는 AWS 문서에 설명되어 있습니다. 선택 사항이지만, 이를 명시적으로 추가하여 Acceptance required를 No로 설정하여 Dedicated가 한 번의 작업으로 연결되도록 하는 것이 좋습니다. Acceptance required를 Yes로 남기면 Dedicated가 연결을 시작한 후 수동으로 수락해야 합니다.
엔드포인트를 사용하여 서비스에 연결하려면 전용 서비스에 DNS 이름이 필요합니다. Private Link는 자동으로 내부 이름을 생성하지만, 이는 기계 생성으로 일반적으로 직접 유용하지 않습니다. 사용 가능한 두 가지 옵션이 있습니다:
- 엔드포인트 서비스에서 프라이빗 DNS 이름을 활성화하고, 필수 검증을 수행한 후 이 옵션을 사용하고 있다는 것을 지원 티켓에 알려주세요. 엔드포인트 서비스에서 Acceptance Required가 Yes로 설정되어 있으면, 지원 티켓에 이를 주의 깊게 적어주세요. Dedicated가 Private DNS 없이 연결을 시작하고, 수락되었다고 확인한 후 Private DNS 사용을 활성화해야 합니다.
- Dedicated는 Dedicated AWS 계정 내에서 프라이빗 호스티드 존(PHZ)을 관리하고 DNS 이름을 엔드포인트에 별칭하여 해당 이름에 대한 요청을 엔드포인트 서비스로 전달할 수 있습니다. 이러한 별칭은 종종 PHZ 항목이라고 합니다. 자세한 내용은 프라이빗 호스티드 존을 참조하세요.

그런 다음 GitLab은 제공한 서비스 이름을 기반으로 필요한 엔드포인트 인터페이스를 생성하기 위해 테넌트 인스턴스를 구성합니다. 테넌트 인스턴스에서 이루어진 모든 일치하는 아웃바운드 연결은 PrivateLink를 통해 VPC로 안내됩니다.

개인 호스팅 영역

개인 호스팅 영역(PHZ)을 사용할 수 있는 경우:

단일 엔드포인트를 사용하여 액세스할 여러 DNS 이름 또는 별칭이 있는 경우. 예를 들어, 환경 내 여러 서비스에 연결하기 위해 리버스 프록시를 실행하는 경우입니다.
사용하려는 도메인이 공개되지 않으며 개인 DNS에서 사용을 검증할 수 없는 경우입니다.

개인 호스팅 영역을 사용하려면 지원 요청서를 제출하세요. 지원 요청서에 아웃바운드 개인 링크를 위한 엔드포인트 서비스에 해결되어야 할 DNS 이름 목록을 제공하세요. 필요에 따라 목록을 업데이트할 수 있습니다.

전용 인스턴스의 도메인을 별칭의 일부로 사용하는 경우, 주 도메인 앞에 두 개의 하위 도메인을 포함해야 합니다. 그 이유는 다음과 같습니다:

첫 번째 하위 도메인이 PHZ의 이름이 됩니다.
두 번째 하위 도메인이 별칭의 레코드 항목이 됩니다.

예를 들어:

유효한 PHZ 항목: subdomain2.subdomain1.<your-tenant-id>.gitlab-dedicated.com.
유효하지 않은 PHZ 항목: subdomain1.<your-tenant-id>.gitlab-dedicated.com.

전용 인스턴스 도메인을 사용하지 않는 경우, PHZ 이름과 phz-entry.phz-name.com 형식의 PHZ 항목이 여전히 필요합니다.

사용자 지정 인증서

일부 경우, GitLab 전용 인스턴스가 소유하고 있는 내부 서비스에 도달할 수 없는 경우가 있습니다. 그 이유는 공인 인증 기관(CA)을 사용하여 검증할 수 없는 인증서를 노출하기 때문입니다. 이러한 경우, 사용자 지정 인증서가 필요합니다.

Switchboard로 사용자 지정 인증서 추가

Switchboard에 로그인합니다.
페이지 상단에서 구성을 선택합니다.
사용자 지정 인증 기관을 확장합니다.
+ 인증서 추가를 선택합니다.
인증서를 텍스트 상자에 붙여넣습니다.
저장을 선택합니다.
페이지 상단으로 스크롤하고 변경 사항을 즉시 적용할지 또는 다음 유지 관리 창에서 적용할지 선택합니다.

지원 요청으로 사용자 지정 인증서 추가

Switchboard를 사용하여 사용자 지정 인증서를 추가할 수 없는 경우 지원 요청서를 열고 사용자 지정 공개 인증서 파일을 첨부하여 변경 요청을 할 수 있습니다.

최대 리버스 PrivateLink 연결 수

GitLab 전용 인스턴스는 리버스 PrivateLink 연결 수를 10으로 제한합니다.

IP 허용 목록

GitLab 전용 인스턴스는 IP 허용 목록을 통해 어떤 IP 주소가 인스턴스에 액세스할 수 있는지를 제어할 수 있습니다. IP 허용 목록이 활성화되면, 허용 목록에 없는 IP가 인스턴스에 액세스하려고 할 때 HTTP 403 Forbidden 응답이 반환됩니다.

IP 허용 목록에 추가된 IP 주소는 Switchboard의 구성 페이지에서 볼 수 있습니다. Switchboard를 사용하여 허용 목록에서 IP 주소를 추가하거나 제거할 수 있습니다.

Switchboard로 허용 목록에 IP 추가

Switchboard에 로그인합니다.
페이지 상단에서 구성을 선택합니다.
허용된 소스 목록 구성 / IP 허용 목록을 확장합니다.
사용하도록 설정 토글을 켭니다.
항목 추가를 선택합니다.
IP 주소와 설명을 입력합니다. 다른 IP 주소를 추가하려면 5단계와 6단계를 반복합니다.
저장을 선택합니다.
페이지 상단으로 스크롤하고 변경 사항을 즉시 적용할지 또는 다음 유지 관리 창에서 적용할지 선택합니다. 변경 사항이 적용된 후, IP 주소는 인스턴스의 IP 허용 목록에 추가됩니다.

지원 요청으로 IP를 허용 목록에 추가하기

Switchboard를 사용하여 IP 허용 목록을 업데이트할 수 없는 경우, 지원 티켓을 열고 GitLab 전용 인스턴스에 액세스할 수 있는 IP 주소의 쉼표로 구분된 목록을 지정할 수 있습니다.

IP 허용 목록에 대해 OpenID Connect 활성화

OpenID Connect ID 공급자로서 GitLab 사용하기를 위해서는 OpenID Connect 검증 엔드포인트에 대한 인터넷 액세스가 필요합니다.

IP 허용 목록을 유지하면서 OpenID Connect 엔드포인트에 대한 액세스를 활성화하려면:

지원 티켓에서 OpenID Connect 엔드포인트에 대한 액세스를 요청하세요.

구성은 다음 유지 관리 시간 동안 적용됩니다.

SAML

GitLab 전용 인스턴스에 대해 SAML 단일 로그인(SSO) 구성을 할 수 있습니다.

다음 SAML SSO 옵션이 제공됩니다:

전제 조건:

GitLab 전용 인스턴스에 대해 SAML을 구성하기 전에 ID 공급자(IdP)를 설정해야 합니다.
GitLab이 SAML 인증 요청에 서명하도록 구성하려면, GitLab 전용 인스턴스를 위한 개인 키와 공개 인증서 쌍을 생성해야 합니다.

Switchboard로 SAML 활성화

GitLab 전용 인스턴스에 대해 SAML을 활성화하려면:

Switchboard에 로그인합니다.
페이지 상단에서 구성을 선택합니다.
SAML 구성을 확장합니다.
활성화 토글을 켭니다.
필수 필드를 완료합니다:
- SAML 레이블
- IdP 인증서 지문
- IdP SSO 대상 URL
선택 사항. SAML 그룹 멤버십에 따라 사용자를 구성하거나 그룹 동기화를 사용하려면 다음 필드를 완료합니다:
- SAML 그룹 속성
- 관리 그룹
- 감사 그룹
- 외부 그룹
- 필수 그룹
선택 사항. SAML 요청 서명을 구성하려면 다음 필드를 완료합니다:
- 이름 식별자 형식
- 발급자
- 속성 진술
- 보안
저장을 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할 것인지 또는 다음 유지 관리 시간 동안 적용할 것인지 선택합니다.
선택 사항. 그룹 동기화를 사용하려면, SAML 그룹 링크를 구성합니다.
SAML 구성이 성공적으로 완료되었는지 확인하려면:
- SSO 버튼 설명이 인스턴스의 로그인 페이지에 표시되는지 확인합니다.
- 인스턴스의 메타데이터 URL(https://INSTANCE-URL/users/auth/saml/metadata)로 이동합니다. 이 페이지는 ID 공급자의 구성을 간소화하고 설정을 수동으로 검증하는 데 사용할 수 있습니다.

SAML 활성화 지원 요청

Switchboard를 사용하여 GitLab 전용 인스턴스의 SAML을 활성화하거나 업데이트할 수 없는 경우, 지원 티켓을 열 수 있습니다:

필요한 변경 사항을 만들기 위해 지원 티켓에 GitLab 애플리케이션에 대한 원하는 SAML 구성 블록을 포함하십시오. GitLab은 인스턴스의 SAML을 활성화하기 위해 다음 정보를 최소한으로 필요로 합니다:

IDP SSO 대상 URL
인증서 지문 또는 인증서
NameID 형식
SSO 로그인 버튼 설명

"saml": {
  "attribute_statements": {
      //optional
  },
  "enabled": true,
  "groups_attribute": "",
  "admin_groups": [
    // optional
  ],
  "idp_cert_fingerprint": "43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8",
  "idp_sso_target_url": "https://login.example.com/idp",
  "label": "IDP Name",
  "name_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
  "security": {
    // optional
  },
  "auditor_groups": [
    // optional
  ],
  "external_groups": [
    // optional
  ],
  "required_groups": [
    // optional
  ],
}

GitLab이 인스턴스에 SAML 구성을 배포한 후 지원 티켓에서 알림을 받게 됩니다.
SAML 구성이 성공적인지 확인하려면:
- SSO 로그인 버튼 설명이 인스턴스의 로그인 페이지에 표시되는지 확인합니다.
- 인스턴스의 메타데이터 URL(https://INSTANCE-URL/users/auth/saml/metadata)로 이동합니다. 이 페이지는 ID 공급자의 구성 대부분을 단순화하고 설정을 수동으로 검증하는 데 사용할 수 있습니다.

요청 서명

SAML 요청 서명이 필요한 경우 인증서를 얻어야 합니다. 이 인증서는 자체 서명할 수 있으며, 이는 임의의 공통 이름(CN)의 소유권을 공개 인증 기관(CA)에 입증할 필요가 없다는 장점이 있습니다.

참고: SAML 요청 서명에는 인증서 서명이 필요하므로, 이 기능이 활성화된 SAML을 사용하려면 이러한 단계를 완료해야 합니다.

SAML 요청 서명을 활성화하려면:

지원 티켓을 열고 요청 서명 활성화를 요청합니다.
GitLab은 귀하가 서명할 수 있도록 인증서 서명 요청(CSR)을 보내는 데 협력합니다. 또는 CSR은 공개 CA로 서명할 수 있습니다.
인증서에 서명한 후에는 인증서와 관련된 개인 키를 사용하여 Switchboard의 SAML 구성에서 security 섹션을 완료할 수 있습니다.

이제 GitLab에서 ID 공급자에 대한 인증 요청이 서명될 수 있습니다.

SAML 그룹

SAML 그룹을 사용하여 SAML 그룹 구성원에 따라 GitLab 사용자를 구성할 수 있습니다.

SAML 그룹을 활성화하려면, Switchboard에서 SAML 구성에 필요한 요소를 추가하거나 지원 티켓에서 제공하는 SAML 블록에 추가하십시오.

그룹 동기화

그룹 동기화를 사용하면, 아이덴티티 제공자 그룹의 사용자들을 GitLab의 매핑된 그룹으로 동기화할 수 있습니다.

그룹 동기화를 활성화하려면:

필수 요소를 Switchboard의 SAML 구성에 추가하거나, 지원 티켓에서 제공한 SAML 구성 블록에 추가합니다.
그룹 링크를 구성합니다.

인스턴스에 사용자 추가하기

관리자는 Switchboard 사용자를 GitLab 전용 인스턴스에 추가할 수 있습니다. 두 가지 유형의 사용자가 있습니다:

읽기 전용: 사용자는 인스턴스 데이터를 볼 수만 있습니다.
관리자: 사용자는 인스턴스 구성을 편집하고 사용자를 관리할 수 있습니다.

GitLab 전용 인스턴스에 새 사용자를 추가하려면:

테넌트 페이지에서 테넌트 인스턴스 옆의 관리를 선택합니다.
페이지 상단에서 사용자를 선택합니다.
새 사용자를 선택합니다.
이메일을 입력하고 사용자에 대한 역할을 선택합니다.
생성을 선택합니다.

Switchboard를 사용하기 위한 초대가 사용자에게 전송됩니다.

알림 기본 설정 관리

Switchboard에서 이메일 알림을 받을지 여부를 지정할 수 있습니다. 다음을 수행한 후에만 알림을 받을 수 있습니다:

이메일 초대를 받고 첫 로그인 시 Switchboard에 로그인합니다.
사용자 계정에 대한 비밀번호 및 이중 인증(2FA)을 설정합니다.

자신의 이메일 알림 기본 설정을 관리하려면:

모든 페이지에서 사용자 이름 옆의 드롭다운을 엽니다.
이메일 알림 수신을 중지하려면 이메일 알림 끄기를 선택합니다.
이메일 알림 수신을 재개하려면 이메일 알림 켜기를 선택합니다.

알림 기본 설정이 업데이트되었음을 확인하는 경고가 표시됩니다.

Switchboard 테넌트 관리자는 조직의 테넌트에 대한 접근 권한이 있는 다른 사용자의 이메일 알림도 관리할 수 있습니다:

사용자 페이지에서 사용자의 이메일 옆의 이메일 알림 열의 드롭다운을 엽니다.
해당 사용자의 이메일 알림을 끄려면 아니요를 선택합니다.
해당 사용자의 이메일 알림을 켜려면 예를 선택합니다.

알림 기본 설정이 업데이트되었음을 확인하는 경고가 표시됩니다.

애플리케이션 로그에 접근하기

GitLab 애플리케이션 로그는 GitLab 테넌트 계정의 S3 버킷으로 전송되며, 귀하와 공유될 수 있습니다. S3 버킷에 저장된 로그는 1년 보존 정책이 완전히 시행될 때까지 무기한 유지됩니다. GitLab 팀원은 이 기밀 문제에서 추가 정보를 볼 수 있습니다: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/483.

이 버킷에 대한 읽기 전용 액세스를 얻으려면:

“고객 로그 접근”이라는 제목의 지원 티켓을 엽니다. 티켓 본문에는 S3에서 로그를 가져오는 IAM Principal ARN(사용자 또는 역할)의 목록을 포함합니다.
GitLab은 S3 버킷의 이름을 알려줍니다. 지정된 사용자/역할은 S3 버킷에서 모든 객체를 나열하고 가져올 수 있습니다.

AWX CLI를 사용하여 S3 버킷에 대한 액세스가 예상대로 작동하는지 확인할 수 있습니다.

버킷 내용 및 구조

S3 버킷에는 GitLab 로그 시스템에서의 인프라 로그와 애플리케이션 로그가 조합되어 있습니다. 버킷의 로그는 GitLab에서 관리하는 AWS KMS 키를 사용하여 암호화됩니다. BYOK를 활성화하도록 선택하는 경우, 애플리케이션 로그는 제공한 키로 암호화되지 않습니다.

S3 버킷의 로그는 YYYY/MM/DD/HH 형식으로 날짜별로 정리되어 있습니다. 예를 들어, 2023/10/12/13와 같은 디렉토리가 있을 것입니다. 해당 디렉토리에는 2023년 10월 12일 1300 UTC의 로그가 포함됩니다. 로그는 Amazon Kinesis Data Firehose를 통해 버킷으로 스트리밍됩니다.

문제 해결

아웃바운드 프라이빗 링크

아웃바운드 프라이빗 링크가 설정된 후 연결 문제를 겪고 있다면, AWS 인프라에서 문제의 원인일 수 있는 몇 가지 사항이 있습니다. 확인해야 할 특정 사항은 수정하고자 하는 예상치 못한 동작에 따라 달라집니다. 확인할 사항은 다음과 같습니다:

네트워크 로드 밸런서(NLB)에서 크로스 존 로드 밸런싱이 켜져 있는지 확인하십시오.
해당 보안 그룹의 인바운드 규칙 섹션이 올바른 IP 범위에서의 트래픽을 허용하는지 확인하십시오.
인바운드 트래픽이 엔드포인트 서비스의 올바른 포트에 매핑되어 있는지 확인하십시오.
스위치보드에서 리버스 프라이빗 링크 구성을 확장하고 세부정보가 예상대로 나타나는지 확인하십시오.
웹훅 및 통합에서 로컬 네트워크에 대한 요청을 허용했는지 확인하십시오.

GitLab 전용 인스턴스 구성

구성 변경

Switchboard를 사용하여 인스턴스 구성

Switchboard에서 구성 변경 적용

구성 변경 로그 보기

구성 변경 요청 정책

도메인 가져오기 (BYOD)

DNS 레코드 설정

사용자 정의 호스트 이름 추가

SMTP 이메일 서비스

수신 개인 링크

아웃바운드 프라이빗 링크

개인 호스팅 영역

사용자 지정 인증서

Switchboard로 사용자 지정 인증서 추가

지원 요청으로 사용자 지정 인증서 추가

최대 리버스 PrivateLink 연결 수

IP 허용 목록

Switchboard로 허용 목록에 IP 추가

지원 요청으로 IP를 허용 목록에 추가하기

IP 허용 목록에 대해 OpenID Connect 활성화

SAML

Switchboard로 SAML 활성화

SAML 활성화 지원 요청

요청 서명

SAML 그룹

그룹 동기화

인스턴스에 사용자 추가하기

알림 기본 설정 관리

애플리케이션 로그에 접근하기

버킷 내용 및 구조

문제 해결

아웃바운드 프라이빗 링크

도움말

기능 사용 가능성과 제품 평가판

도움받기