GitLab Dedicated 인스턴스 구성

Tier: Ultimate Offering: GitLab Dedicated

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

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

SaaS 환경 설정의 예시로는 gitlab.rb 구성 및 쉘, Rails 콘솔, 그리고 PostgreSQL 콘솔 접근이 있습니다. 이러한 환경 설정은 테넌트에 의해 변경될 수 없습니다.

또한, GitLab 전용 엔지니어들은 긴급 상황을 제외하고 테넌트 환경에 직접적인 액세스를 가지고 있지 않습니다.

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

구성 변경

구성 변경 정책

지원 티켓을 통해 요청된 구성 변경 사항은 주간 4시간 유지보수 창에서 일괄적으로 적용됩니다.

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

다가오는 주간 유지보수 창에서 변경 사항을 고려하려면 필요한 모든 정보가 창 시작 2영업일 전까지 제출되어야 합니다.

본 기간 이내에 구성 변경이 적용되지 않을 수 있습니다. 만약 GitLab이 유지보수 창을 넘어선 고우선 순위 작업을 수행해야 할 경우, 구성 변경은 다음 주로 연기될 것입니다.

지원 티켓을 통해 요청된 변경 사항은 주간 유지보수 창 이외에 적용되지 않으며, 긴급 지원으로서 적용되어야 합니다.

Switchboard에서의 구성 변경

Switchboard를 사용하면 사용자가 GitLab 전용 인스턴스의 제한적인 구성 변경을 할 수 있습니다. Switchboard가 더욱 성숙해지면 추가 구성 변경 옵션이 제공될 것입니다.

GitLab 전용 인스턴스의 구성을 변경하거나 업데이트하려면, 관련 섹션의 지시 사항에 따라 Switchboard를 사용하거나 지원 티켓을 열어 요청하세요.

Switchboard를 통해 만든 구성 변경은 즉시 적용되거나 다음 예정된 주간 유지보수 창까지 연기될 수 있습니다.

즉시 적용할 경우, 변경 사항은 최대 90분까지 환경에 배포되기까지 시간이 소요될 수 있습니다. 각 변경 사항은 저장된 순서로 적용되거나, 일괄적으로 적용하기 위해 한꺼번에 여러 변경 사항을 저장할 수 있습니다.

수신 사설 링크

AWS Private Link는 AWS의 VPC에 있는 사용자 및 응용프로그램이 공개 인터넷을 통하지 않고 GitLab 전용 엔드포인트에 안전하게 연결되도록 합니다.

수신 사설 링크를 활성화하려면:

  1. 지원 티켓을 열어주세요. 지원 티켓의 본문에는 AWS 계정 내의 VPC 엔드포인트를 설정하는데 사용되는 IAM 주체를 포함해야 합니다. IAM 주체는 IAM 역할 주체 또는 IAM 사용자 주체 여야 합니다. GitLab Dedicated은 이 IAM 주체를 액세스 제어에 사용합니다. 이 IAM 주체만 해당 서비스에 엔드포인트를 설정할 수 있습니다.
  2. IAM 주체가 허용 목록에 추가되면, GitLab은 엔드포인트 서비스를 생성하고 지원 티켓에 서비스 엔드포인트 이름을 통지합니다. 이 서비스 이름은 AWS에서 서비스 엔드포인트를 생성할 때 생성됩니다.
    • GitLab은 사설 DNS 이름의 도메인 확인을 처리하여 VPC 내 테넌트 인스턴스 도메인 이름의 DNS 해결이 사설 링크 엔드포인트로 해결되도록 합니다.
    • GitLab은 초기 온보딩 시 지정한 가용 영역에서 엔드포인트 서비스를 사용할 수 있게 합니다. 가용 영역 ID가 명시되지 않았다면, GitLab은 가용 영역 ID를 임의로 선택합니다.
  3. 고객의 AWS 계정에서 다음과 같은 설정을 지정하여 VPC 내에서 엔드포인트 인터페이스를 생성합니다:
    • 서비스 엔드포인트 이름: 지원 티켓에서 제공한 이름 사용.
    • 사설 DNS 이름 사용 가능: 예.
    • 서브넷: 일치하는 모든 서브넷 선택.
  4. 엔드포인트를 생성한 후, 초기 온보딩 시 제공된 인스턴스 URL을 사용하여 공개 인터넷을 거치지 않고 고객의 VPC에서 GitLab 전용 인스턴스에 안전하게 연결할 수 있습니다.

아웃바운드 프라이빗 링크

참고: 환경에 인바운드 또는 아웃바운드 프라이빗 링크를 추가할 계획이 있고 연결을 특정 가용 영역에서 사용 가능하게 하려면 온보딩 중에 계정팀에 최대 두 개의 가용 영역 ID를 제공해야 합니다. 지정하지 않았다면, GitLab은 연결 가능한 두 개의 무작위 가용 영역 ID를 선택합니다.

아웃바운드 프라이빗 링크를 사용할 때 다음 사항을 고려하세요:

  • 아웃바운드 프라이빗 링크를 사용하면 GitLab 전용 인스턴스가 AWS의 VPC에서 실행되는 서비스와 안전하게 통신할 수 있습니다. 이 유형의 연결은 웹훅을 실행하고 대상 서비스가 회사의 VPC에서 실행되거나 프로젝트 및 저장소를 가져오거나 미러링하거나 기타 GitLab 기능을 사용하여 비공개 서비스에 액세스할 수 있습니다.
  • 같은 지역의 VPC 간에만 프라이빗 링크를 설정할 수 있습니다. 따라서 전용 인스턴스에 대해 선택한 지역에서만 연결을 설정할 수 있습니다.
  • 엔드포인트 서비스의 Network Load Balancer (NLB)는 전용 인스턴스가 배포된 가용 영역 중 적어도 하나에서 활성화되어 있어야 합니다. 이는 us-east-1a와 같은 사용자 표시 이름이 아니라 내부 가용 영역 ID입니다. Dedicated로의 온보딩 중에 이러한 것들을 지정하지 않았다면 다음을 수행해야 합니다:
    • 링크를 활성화하기 위해 제기한 티켓에 가용 영역 ID를 요청하고 NLB가 해당 가용 영역에서 활성화되어 있는지 확인해야 합니다.
    • NLB가 지역의 모든 가용 영역에서 활성화되어 있는지 확인해야 합니다.

Tenant Details 섹션에서 Reverse Private Link IAM Principal 속성을 확인할 수 있습니다.

아웃바운드 프라이빗 링크를 활성화하려면 다음을 수행하세요:

  1. 내부 서비스가 GitLab 전용으로 사용 가능하게 하는 엔드포인트 서비스를 생성합니다. 연관된 서비스 엔드포인트 이름을 새로운 지원 티켓에서 제공하세요.
  2. 지원 티켓에서 GitLab은 엔드포인트 서비스로의 연결을 시작할 IAM 역할의 ARN을 제공합니다. 이 ARN이 엔드포인트 서비스의 “허용된 주체” 목록에 포함되거나 다른 항목에 포함되도록 해야 합니다. 상세한 내용은 AWS 문서를 참조하세요. 선택사항이지만, Dedicated가 단일 작업으로 연결할 수 있도록 수락 필수를 No로 설정하여 명시적으로 추가하는 것이 좋습니다. 수락 필수를 Yes로 남겨두면 Dedicated가 시작한 후에 수동으로 연결을 수락해야 합니다.
  3. 엔드포인트를 사용하여 서비스에 연결하려면 전용 서비스에서 DNS 이름이 필요합니다. 프라이빗 링크는 내부 이름을 자동으로 생성하지만 일반적으로 직접적으로 유용하지는 않습니다. 두 가지 옵션이 있습니다:
    • 엔드포인트 서비스에서 프라이빗 DNS 이름을 활성화하고 필요한 유효성 검사를 수행한 후, 이 옵션을 사용한다는 사항을 지원 티켓에서 GitLab에 알려주세요. 엔드포인트 서비스에서 수락 필수가 Yes로 설정된 경우, 지원 티켓에서 이를 알릴 필요가 있습니다. Dedicated는 프라이빗 DNS를 사용하지 않고 연결을 시작한 후 여부가 확인되기를 기다린 후 연결을 업데이트하여 프라이빗 DNS 사용을 활성화해야 합니다.
    • Dedicated는 Dedicated AWS 계정 내에서 프라이빗 호스팅 존 (PHZ)을 관리하고 임의의 DNS 이름을 엔드포인트에 별칭을 지정하여 해당 이름에 대한 요청을 엔드포인트 서비스로 보냅니다. 이 옵션을 사용하는 경우 지원 티켓에서 GitLab에 알려주고 프라이빗 링크 엔드포인트에 대한 해결이 필요한 DNS 이름 목록을 제공하세요. 이 목록은 필요에 따라 나중에 업데이트할 수 있습니다.

그러면 GitLab은 테넌트 인스턴스를 구성하여 제공한 서비스 이름에 기반하여 필요한 엔드포인트 인터페이스를 생성합니다. 테넌트 인스턴스에서 수립한 아웃바운드 연결이 프라이빗 링크를 통해 회사의 VPC로 전송됩니다.

사용자 정의 인증서

일부 경우에는 GitLab 전용 인스턴스가 내부 서비스에 연결할 수 없는 경우가 있습니다. 왜냐하면 해당 서비스는 공개 인증 기관(CA)을 통해 확인할 수 없는 인증서를 노출합니다. 이러한 경우에는 사용자 정의 인증서가 필요합니다.

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

  1. Switchboard에 로그인합니다.
  2. 페이지 상단에서 Configuration을 선택합니다.
  3. Custom Certificate Authorities를 확장합니다.
  4. + Add Certificate을 선택합니다.
  5. 텍스트 상자에 인증서를 붙여넣습니다.
  6. Save를 선택합니다.
  7. 페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창으로 미룰지를 선택합니다.

지원 요청과 함께 사용자 정의 인증서 추가

개인링크를 통해 귀사의 서비스와 통신 시 GitLab이 사용자 정의 인증서를 추가하도록 요청하려면 지원 티켓에 사용자 지정 공개 인증서 파일을 첨부하십시오.

역개인링크 연결 수의 최대치

GitLab 전용은 역개인링크연결 수를 10으로 제한합니다.

IP 허용목록

GitLab 전용을 통해 IP 허용목록을 활성화할 수 있습니다. IP 허용목록에서 허용되지 않은 IP가 인스턴스에 액세스하려고 시도하면 HTTP 403 Forbidden 응답이 반환됩니다.

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

Switchboard를 사용하여 IP를 허용목록에 추가

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

지원 요청을 통해 IP를 허용목록에 추가

지원 티켓에 귀사의 GitLab 전용 인스턴스에 액세스할 수 있는 IP 주소의 쉼표로 구분된 목록을 지정하십시오. 그러면 해당 IP 주소가 인스턴스의 IP 허용목록에 추가됩니다.

SAML

참고: GitLab 전용은 제한된 수의 SAML 매개변수를 지원합니다. 아래 구성에 표시되지 않은 매개변수는 GitLab 전용 인스턴스에서 사용할 수 없습니다.

전제 조건: - 필요한 데이터를 GitLab에 제공하기 전에 식별 공급자를 구성해야 합니다.

Switchboard를 사용하여 SAML 활성화

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

  1. Switchboard에 로그인합니다.
  2. 페이지 상단에서 Configuration을 선택합니다.
  3. SAML Config를 확장합니다.
  4. Enable 토글을 켭니다.
  5. 필드를 작성합니다.
  6. Save를 선택합니다.
  7. 페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창으로 미룰지를 선택합니다.
  8. SAML 구성이 성공적으로 완료되었는지 확인하려면:
    • 인스턴스의 로그인 페이지에 SSO 버튼 설명이 표시되는지 확인합니다.
    • 인스턴스의 메타데이터 URL로 이동하여 (https://INSTANCE-URL/users/auth/saml/metadata) 식별 공급자의 구성을 단순화하고 설정을 수동으로 유효성을 검사할 수 있습니다.

지원 요청을 통해 SAML 활성화

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

  1. 필요한 변경 사항을 만들려면 지원 티켓에 귀사의 GitLab 응용 프로그램을 위한 원하는 SAML 구성 블록을 포함하십시오. 최소한 GitLab은 인스턴스에 SAML을 활성화하려면 다음 정보가 필요합니다:
    • IDP SSO 대상 URL
    • 인증서 지문 또는 인증서
    • NameID 형식
    • SSO 로그인 버튼 설명 
"saml": {
  "attribute_statements": {
      // 선택 사항
  },
  "enabled": true,
  "groups_attribute":""
  // 선택 사항
}
  1. GitLab이 SAML 구성을 인스턴스에 배포하면 지원 티켓으로 알림을 받습니다.
  2. SAML 구성이 성공적으로 완료되었는지 확인하려면:
    • 인스턴스의 로그인 페이지에 SSO 로그인 버튼 설명이 표시되는지 확인합니다.
    • 인스턴스의 메타데이터 URL로 이동하여 (https://INSTANCE-URL/users/auth/saml/metadata) 식별 공급자의 구성을 단순화하고 설정을 수동으로 유효성을 검사할 수 있습니다.

요청 서명

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

SAML 요청 서명을 활성화하려면 SAML을 사용하기 전에 수동 단계를 완료해야 합니다. 인증서 서명이 필요하기 때문에 SAML 요청 서명을 활성화하려면 지원 티켓에서 해당 사항을 알려주세요. GitLab은 고객이 서명할 수 있도록 인증서 서명 요청(CSR)을 보내거나, 공용 CA로 CSR을 서명할 수 있도록 협업합니다. 인증서가 서명되면 GitLab은 인증서와 해당 개인 키를 SAML 구성의 security 섹션에 추가합니다. 그러면 GitLab에서 신원 공급자로부터의 인증 요청을 서명할 수 있습니다.

SAML 그룹

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

SAML 그룹을 활성화하려면 필요한 요소를 SAML 구성 블록에 추가해야 합니다. 이를 위해 지원 티켓에 제공해야 합니다.

그룹 동기화

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

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

  1. SAML 구성 블록에 필요한 요소를 추가해야 합니다. 이를 위해 지원 티켓에 제공해야 합니다.
  2. 그룹 링크를 구성하세요.

인스턴스에 사용자 추가

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

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

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

  1. 테넌츠 페이지에서 테넌트 인스턴스 옆의 관리를 선택하세요.
  2. 페이지 상단에서 사용자를 선택하세요.
  3. 새 사용자를 선택하세요.
  4. 사용자의 이메일을 입력하고 사용자의 역할을 선택하세요.
  5. 생성을 선택하세요.

스위치보드 사용을 초대하는 초대장이 사용자에게 전송됩니다.

애플리케이션 로그에 액세스

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

이 버킷에 읽기 전용으로 액세스하려면:

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

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

버킷 내용 및 구조

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

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