GitLab 전용 인스턴스 구성

Tier: Ultimate Offering: GitLab Dedicated

이 페이지의 지침은 GitLab 전용 인스턴스를 구성하는 과정을 안내합니다. 이 과정에는 사용 가능한 기능을 활성화하고 업데이트하는 것도 포함됩니다.

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

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

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

참고: 인스턴스는 GitLab 전용 배포를 나타내고, 테넌트는 고객을 나타냅니다.

구성 변경

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

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

Switchboard에서 다음 구성 설정을 사용할 수 있습니다:

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

전제 조건:

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

구성 변경 방법:

Switchboard에 로그인합니다.
페이지 상단에서 구성(Configuration)을 선택합니다.
아래의 관련 섹션 안내를 따릅니다.

나머지 인스턴스 구성 변경 사항에 대해서는 구성 변경 요청 정책에 따라 지원 티켓을 제출하세요.

Switchboard에서 구성 변경 적용

Switchboard에서 만든 구성 변경 사항을 즉시 적용하거나 다음 예정된 주간 유지 관리 창까지 지연할 수 있습니다.

즉시 변경 사항을 적용하는 경우:

배포에 최대 90분이 걸릴 수 있습니다.
변경 사항은 저장된 순서대로 적용됩니다.
여러 변경 사항을 저장하고 일괄적으로 적용할 수 있습니다.

배포가 완료되면 이메일 통지를 받습니다. 주 메일함에 통지가 표시되지 않으면 스팸함을 확인하세요. Switchboard에서 테넌트를 보거나 편집할 수 있는 모든 사용자는 각 변경 사항마다 알림을 받습니다. 자세한 내용은 Switchboard 알림 환경 관리를 참조하세요.

참고: Switchboard 테넌트 관리자가 만든 변경 사항에 대해서만 이메일 통지를 받습니다. GitLab Operator(예: 유지 관리 창 동안 완료된 GitLab 버전 업데이트)가 만든 변경 사항에 대해서는 이메일 알림이 트리거되지 않습니다.

구성 변경 로그 보기

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

구성 변경: 변경된 구성 설정의 이름.
사용자: 구성 변경을 한 사용자의 이메일 주소. GitLab Operator에 의해 변경된 경우, 이 값은 GitLab Operator로 나타납니다.
IP: 구성 변경을 한 사용자의 IP 주소. GitLab Operator에 의해 변경된 경우, 이 값은 사용 불가로 나타납니다.
상태: 구성 변경이 시작되었는지, 진행 중인지, 완료되었는지, 또는 지연되었는지.
시작 시간: 구성 변경이 시작된 UTC 날짜 및 시간.
종료 시간: 구성 변경이 완료된 UTC 날짜 및 시간.

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

시작됨: Switchboard에서 구성 변경은 되었지만 아직 인스턴스에 배포되지 않은 상태입니다.
진행 중: 구성 변경이 현재 인스턴스에 배포 중입니다.
완료됨: 구성 변경이 인스턴스에 배포되었습니다.
지연됨: 초기 작업으로 변경 배포에 실패하여 새로운 작업에 할당되지 않은 경우입니다.

구성 변경 로그 보기 방법:

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

구성 변경 요청 정책

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

지원 티켓을 통해 요청된 구성 변경 사항:

환경의 주간 4시간 유지 관리 창 동안에만 적용됩니다.
온보딩 중에 지정된 옵션이나 본 페이지에 나열된 선택적 기능에 대해 요청할 수 있습니다.
GitLab이 긴급한 유지 관리 작업을 수행해야 할 경우 다음 주차로 연기될 수 있습니다.
긴급 지원을 받아야만 유지 관리 창 외에 구성 변경을 적용할 수 없습니다.

참고: 구성 변경 요청 사항이 최소 리드 타임을 충족하더라도 다음 주간 유지 관리 창 중에 적용되지 않을 수도 있습니다.

Bring your own domain (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")을 해당 도메인의 인증 기관으로 허용합니다.

사용자 정의 호스트명 추가

인스턴스 생성 후 사용자 정의 호스트명을 추가하려면 지원 티켓을 제출하세요.

SMTP 이메일 서비스

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

SMTP 이메일 서비스를 구성하려면, SMTP 서버의 자격 증명 및 설정과 함께 지원 티켓을 제출하십시오.

인바운드 프라이빗 링크

AWS Private Link를 사용하면 AWS VPC의 사용자 및 응용 프로그램이 공개 인터넷을 통과하지 않고 GitLab 전용 엔드포인트에 안전하게 연결할 수 있습니다.

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

지원 티켓을 엽니다. 지원 티켓의 본문에는 AWS 사용자 또는 역할의 IAM 주체를 포함하십시오. 이러한 IAM 주체는 AWS 계정의 VPC 엔드포인트를 설정 중인 역할 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-roles) 또는 IAM 사용자 주체여야 합니다. GitLab Dedicated는 이러한 IAM 주체를 액세스 제어에 사용합니다. 이러한 IAM 주체만 서비스에 엔드포인트를 설정할 수 있습니다.
IAM 주체가 허용 목록에 올라가면, GitLab은 엔드포인트 서비스를 생성하고 지원 티켓에 서비스 엔드포인트 이름을 알려드립니다. 서비스 이름은 서비스 엔드포인트를 생성할 때 AWS에서 생성됩니다.
- GitLab은 프라이빗 DNS 이름의 도메인 확인을 처리하여 VPC의 테넌트 인스턴스 도메인 이름의 DNS 해상도가 프라이빗링크 엔드포인트로 해결되도록 합니다.
- 엔드포인트 서비스는 두 가용 영역에서 사용할 수 있습니다. 이 두 가용 영역은 온보딩 중에 선택한 영역이거나 온보딩 시에 지정하지 않은 경우에는 무작위로 선택된 두 가용 영역입니다.
귀하의 AWS 계정에서 다음과 같은 설정으로 VPC에 엔드포인트 인터페이스를 생성하십시오:
- 서비스 엔드포인트 이름: GitLab에서 제공한 이름 사용.
- 프라이빗 DNS 이름 활성화: 예.
- 서브넷: 모든 일치하는 서브넷 선택.
엔드포인트를 생성한 후, 공개 인터넷을 경유하지 않고 VPC에서 GitLab 전용 인스턴스로 안전하게 연결하려면 온보딩 중에 제공된 인스턴스 URL을 사용하십시오.

아웃바운드 프라이빗 링크

아웃바운드 프라이빗 링크를 사용하면 GitLab 전용 인스턴스 및 GitLab 전용의 호스팅 러너가 AWS의 VPC에서 실행되는 서비스와 안전하게 통신하면서 모든 트래픽을 공개 인터넷에 노출하지 않을 수 있습니다.

이 유형의 연결을 통해 GitLab 기능이 개인 서비스에 액세스할 수 있습니다: - GitLab 전용 인스턴스: - 웹훅 - 프로젝트 및 저장소 가져오기 또는 미러

호스팅 러너:
- 사용자 지정 비밀 관리자
- 인프라에 저장된 아티팩트 또는 작업 이미지
- 인프라로의 배포

다음을 고려하십시오: - 동일한 지역의 VPC 간에만 프라이빗 링크를 설정할 수 있습니다. 따라서 Dedicated 인스턴스용으로 지정된 지역에 대해서만 연결을 설정할 수 있습니다. - 이 연결에는 온보딩 중에 선택한 지역의 두 가용 영역 (AZ IDs)이 필요합니다. - Dedicated로 온보딩 중에 아무런 AZ를 지정하지 않은 경우, GitLab은 두 가용 영역의 AZ ID를 무작위로 선택합니다.

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

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

내부 서비스가 GitLab 전용에 사용 가능하게 하는 엔드포인트 서비스를 생성하십시오. 연결을 위해 연결된 서비스 엔드포인트 이름을 새로운 지원 티켓에 제공하십시오.
Dedicated 인스턴스가 배포된 두 가용 영역에 대해 엔드포인트 서비스의 네트워크 로드 밸런서(NLB)를 구성했는지 확인하십시오. Dedicated에 대한 온보딩 중에 이러한 항목을 지정하지 않은 경우, 해당 AZ IDs를 요청하기 위해 지원 티켓을 제출하고 해당 AZs에서 NLB가 활성화되어 있는지 확인하십시오.
지원 티켓에 따라, GitLab은 엔드포인트 서비스에서 연결을 시작할 IAM 역할의 ARN을 제공합니다. 이 ARN이 엔드포인트 서비스의 “허용된 주체” 목록에 명시되거나 다른 항목으로 처리되어야 합니다. 선택 사항이지만 명시적으로 추가하여 단일 작업으로 Dedicoated가 연결을 설정한 후 수락이 필요하다면 “수락 필요”를 No로 설정할 수 있습니다.
연결을 사용하려면 Dedicated 서비스가 DNS 이름이 필요합니다. Private Link는 내부 이름을 자동으로 생성하지만 일반적으로 직접 사용하기에는 적합하지 않습니다. 두 가지 옵션이 있습니다:
- 엔드포인트 서비스에서 프라이빗 DNS 이름을 활성화하고 필요한 확인을 수행하도록 하여 이 방식을 사용한다는 사실을 지원 티켓에서 알려주십시오. 엔드포인트 서비스에서 수락 필요가 Yes로 설정된 경우, Dedicated가 프라이빗 DNS를 사용하도록 업데이트하려면 수락을 확인하기 전까지 연결을 시작한 후 기다리고, 그런 다음 연결을 업데이트해야 합니다.
- Dedicated는 Dedicated AWS 계정 내에서 프라이빗 호스트존(PHZ)을 관리하고 엔드포인트를 위해 DNS 이름을 에일리어스로 만들어 PHZ 항목을 사용하여 요청을 끝점 서비스로 보내는데 사용할 수 있습니다. 이러한 에일리어스는 종종 PHZ 항목이라고도 합니다. 자세한 내용은 프라이빗 호스트존을 참조하십시오.

GitLab은 제공된 서비스 이름을 기반으로 테넌트 인스턴스를 구성하여 엔드포인트 인터페이스를 생성합니다. 테넌트 인스턴스에서 수립한 일치하는 아웃바운드 연결은 프라이빗링크를 통해 귀하의 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에 로그인합니다.
페이지 상단에서 Configuration을 선택합니다.
Custom Certificate Authorities를 확장합니다.
+ Add Certificate를 선택합니다.
인증서를 텍스트 상자에 붙여넣습니다.
Save를 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창을 기다릴지 선택합니다.

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

Switchboard를 사용하여 사용자 지정 인증서를 추가할 수 없는 경우, 지원 티켓을 여십시오 및 사용자 지정 공용 인증서 파일을 첨부하여 이 변경을 요청할 수 있습니다.

역방향 PrivateLink 연결의 최대 수

GitLab 전용 인스턴스는 역방향 PrivateLink 연결의 수를 10개로 제한합니다.

IP 허용 목록

GitLab 전용은 IP 허용 목록을 통해 인스턴스에 액세스할 수 있는 IP 주소를 제어할 수 있게 합니다. IP 허용 목록이 활성화된 후, 허용 목록에 없는 IP가 인스턴스에 액세스하려고 시도하면 HTTP 403 Forbidden 응답이 반환됩니다.

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

Switchboard에서 IP를 허용 목록에 추가

Switchboard에 로그인합니다.
페이지 상단에서 Configuration을 선택합니다.
Allowed Source List Config / IP allowlist를 확장합니다.
Enable 토글을 켭니다.
Add Item을 선택합니다.
IP 주소와 설명을 입력합니다. 다른 IP 주소를 추가하려면 단계 5와 6을 반복합니다.
Save를 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창을 기다릴지 선택합니다. 변경 사항이 적용된 후에는 IP 주소가 인스턴스의 IP 허용 목록에 추가됩니다.

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

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

IP 허용 목록을 위해 OpenID Connect 활성화

GitLab을 OpenID Connect 싱글 사인온(SSO) 식별 공급자로 사용하려면 OpenID Connect 검증 엔드포인트에 대한 인터넷 액세스가 필요합니다.

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

지원 티켓에서 OpenID Connect 엔드포인트에 액세스할 수 있도록 요청하십시오.

이 구성은 다음 유지 보수 창에서 적용됩니다.

SAML

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

다음과 같은 SAML SSO 옵션을 사용할 수 있습니다:

전제 조건:

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

Switchboard에서 SAML 활성화

GitLab Dedicated 인스턴스에 SAML을 활성화하려면:

Switchboard에 로그인합니다.
페이지 상단에서 Configuration을 선택합니다.
SAML Config를 확장합니다.
Enable 토글을 켭니다.
필수 입력란을 완료합니다:
- SAML 레이블
- IdP cert fingerprint
- IdP SSO target URL
옵션. SAML 그룹 멤버십에 따라 사용자를 구성하거나 그룹 동기화를 사용하려면 다음 입력란을 완료합니다:
- SAML 그룹 속성
- 관리자 그룹
- 감사자 그룹
- 외부 그룹
- 필수 그룹
옵션. SAML 요청 서명을 구성하려면 다음 입력란을 완료합니다:
- 이름 식별자 형식
- 발행자
- 속성 명시
- 보안
Save를 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창을 기다릴지 선택합니다.
그룹 동기화를 사용하려면 SAML 그룹 링크를 구성합니다.
SAML 구성이 성공적인지 확인하려면:
- 인스턴스 로그인 페이지에 SSO 버튼 설명이 표시되는지 확인합니다.
- 인스턴스의 메타데이터 URL(https://INSTANCE-URL/users/auth/saml/metadata)로 이동합니다. 이 페이지는 신원 공급자의 구성을 단순화하고 수동으로 설정을 확인하는 데 사용할 수 있습니다.

지원 요청으로 SAML 활성화하기

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

필요한 변경 사항을 하려면, GitLab 애플리케이션을 위한 원하는 SAML 구성 블록을 지원 티켓에 포함하세요. 최소한 GitLab은 SAML을 인스턴스에 활성화하려면 다음 정보가 필요합니다:

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

"saml": {
  "attribute_statements": {
      //옵션
  },
  "enabled": true,
  "groups_attribute": "",
  "admin_groups": [
    // 옵션
  ],
  "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_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
  "security": {
    // 옵션
  },
  "auditor_groups": [
    // 옵션
  ],
  "external_groups": [
    // 옵션
  ],
  "required_groups": [
    // 옵션
  ],
}

GitLab이 SAML 구성을 인스턴스에 배포한 후, 해당 지원 티켓으로 알림을 받습니다.
SAML 구성이 성공적으로 완료되었는지 확인하려면:
- 인스턴스 로그인 페이지에 SSO 로그인 버튼 설명이 표시되는지 확인하세요.
- 인스턴스의 메타데이터 URL(https://INSTANCE-URL/users/auth/saml/metadata)로 이동하세요. 이 페이지를 사용하여 식별 공급자의 구성을 간소화하고 설정을 수동으로 확인할 수 있습니다.

요청 서명

SAML 요청 서명을 원하는 경우, 인증서를 획들해야 합니다. 이 인증서는 임의의 공통 이름(CN)의 소유권을 입증할 필요가 없다는 장점이 있는 자체 서명될 수 있습니다 (자체 서명).

참고: SAML 요청 서명은 인증서 서명을 필요로 하므로, 이 기능을 사용하려면 이 단계를 완료해야 합니다.

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

지원 티켓을 열고 서명이 활성화되길 원한다고 표시합니다.
GitLab이 서명할 인증서 서명 요청 (CSR)을 보내줄 것입니다. 또는 CSR은 공용 CA로 서명할 수 있습니다.
인증서가 서명되면, 해당 인증서와 관련된 개인 키를 사용하여 Switchboard의 SAML 구성의 security 섹션을 완료할 수 있습니다.

GitLab에서 식별 공급자로부터의 인증 요청을 서명할 수 있게 되었습니다.

SAML 그룹

SAML 그룹을 사용하면 SAML 그룹 멤버십에 따라 GitLab 사용자를 구성할 수 있습니다.

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

그룹 동기화

그룹 동기화를 사용하여 식별 공급자 그룹에서 GitLab에 매핑된 그룹으로 사용자를 동기화할 수 있습니다.

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

Switchboard의 SAML 구성이나 지원 티켓에 필요한 요소를 추가하세요.
그룹 링크를 구성하세요.

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

관리자는 Switchboard 사용자를 GitLab Dedicated 인스턴스에 추가할 수 있습니다. 두 종류의 사용자가 있습니다:

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

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

Tenants 페이지에서 테넌트 인스턴스 옆에 있는 관리를 선택하세요.
페이지 상단에서 사용자를 선택하세요.
새 사용자를 선택하세요.
사용자의 이메일을 입력하고 사용자의 역할을 선택하세요.
만들기를 선택하세요.

Switchboard 사용을 위한 초대장이 사용자에게 전송됩니다.

알림 설정 관리

Switchboard로부터 이메일 알림을 받을지 여부를 지정할 수 있습니다. 알림을 받으려면 다음을 수행해야 합니다:

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

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

페이지 내의 사용자 이름 옆의 드롭다운을 엽니다.
이메일 알림을 끄려면 이메일 알림 전환 끄기를 선택하세요.
이메일 알림을 다시 받으려면 이메일 알림 전환 켜기를 선택하세요.

알림 설정이 변경되었음을 알리는 경고가 표시됩니다.

Switchboard 테넌트 관리자는 자신의 조직 테넌트에 액세스할 수 있는 다른 사용자들의 이메일 알림도 관리할 수 있습니다:

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

알림 설정이 변경되었음을 알리는 경고가 표시됩니다.

애플리케이션 로그 액세스

GitLab 애플리케이션 로그는 GitLab 테넌트 계정의 S3 버킷으로 전달되어 여러분과 공유될 수 있습니다. S3 버킷에 저장된 로그는 1년 임 rention 정책이 완전히 시행될 때까지 무기한 보관됩니다. GitLab 팀원들은 이 기밀 문제에서 더 많은 정보를 확인할 수 있습니다: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/483.

이 버킷에 대한 읽기 전용 액세스를 획들하려면:

“고객 로그 액세스”라는 제목의 지원 티켓을 엽니다. 티켓의 본문에 S3에서 로그를 가져오는 IAM 주요 ARN (사용자 또는 역할) 목록을 포함하세요.
그런 다음 GitLab은 S3 버킷의 이름을 알려줄 것입니다. 지정된 사용자/역할은 이후 S3 버킷에 있는 모든 객체를 나열하고 가져올 수 있습니다.

여러분은 AWS CLI를 사용하여 S3 버킷의 액세스가 예상대로 작동하는지 확인할 수 있습니다.

버킷 내용 및 구조

S3 버킷에는 GitLab 로그 시스템에서 가져온 인프라 로그와 애플리케이션 로그가 결합되어 있습니다. 버킷 내의 로그는 GitLab에서 관리하는 AWS KMS 키를 사용하여 암호화되어 있습니다. BYOK를 활성화하면 제공하는 키로 애플리케이션 로그가 암호화되지 않습니다.

S3 버킷 내의 로그는 YYYY/MM/DD/HH 형식으로 날짜별로 구성됩니다. 예를 들어 2023/10/12/13과 같은 디렉터리가 있을 수 있습니다. 해당 디렉터리에는 2023년 10월 12일 13시(UTC)의 로그가 포함되어 있습니다. 로그는 Amazon Kinesis Data Firehose를 통해 버킷으로 스트리밍됩니다.

Troubleshooting

아웃바운드 프라이빗 링크

아웃바운드 프라이빗 링크를 설정한 후에 연결을 수립하는 데 문제가 있는 경우, 문제의 원인이 되는 AWS 인프라의 몇 가지 사항이 있을 수 있습니다. 해결하려는 예기치 않은 동작에 따라 확인해야 할 특정 사항이 달라집니다. 확인해야 할 사항에는 다음이 포함됩니다.

Network Load Balancer (NLB)에서 교차 존 부하 분산이 켜져 있는지 확인합니다.
적절한 보안 그룹의 Inbound Rules 섹션이 올바른 IP 범위에서의 트래픽을 허용하는지 확인합니다.
인바운드 트래픽이 엔드포인트 서비스의 올바른 포트에 매핑되어 있는지 확인합니다.
Switchboard에서 Reverse Private Link Config를 확장하고 예상대로 세부 정보가 나타나는지 확인합니다.
웹훅 및 통합에서 로컬 네트워크로의 요청 허용을 확인합니다.

GitLab 전용 인스턴스 구성

구성 변경

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

Switchboard에서 구성 변경 적용

구성 변경 로그 보기

구성 변경 요청 정책

Bring your own domain (BYOD)

DNS 레코드 설정

사용자 정의 호스트명 추가

SMTP 이메일 서비스

인바운드 프라이빗 링크

아웃바운드 프라이빗 링크

사설 호스트 영역

사용자 지정 인증서

Switchboard를 사용하여 사용자 지정 인증서 추가

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

역방향 PrivateLink 연결의 최대 수

IP 허용 목록

Switchboard에서 IP를 허용 목록에 추가

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

IP 허용 목록을 위해 OpenID Connect 활성화

SAML

Switchboard에서 SAML 활성화

지원 요청으로 SAML 활성화하기

요청 서명

SAML 그룹

그룹 동기화

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

알림 설정 관리

애플리케이션 로그 액세스

버킷 내용 및 구조

Troubleshooting

아웃바운드 프라이빗 링크

도움말

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

도움받기