GitLab Dedicated 인스턴스 구성

Tier: Ultimate
Offering: GitLab Dedicated

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

SaaS 환경에서 제어되지 않는 GitLab 응용프로그램의 기능은 관리자 영역을 사용하여 구성할 수 있습니다.

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

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

note
인스턴스는 GitLab Dedicated 배포를 가리키며, 테넌트는 고객을 가리킵니다.

구성 변경

구성 변경 정책

지원 티켓으로 요청된 구성 변경 사항은 매주 4시간 진행되는 환경 주간 유지 보수 창에서 일괄적으로 적용됩니다.

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

다가오는 주간 유지 보수 창에 구성 변경을 적용하려면 필요한 모든 정보를 창 시작 2 영업일 전에 모두 제출해야 합니다.

구성 변경이 최소 선행 시간을 충족하더라도, GitLab이 유지 보수 창을 넘어 고도로 시급한 유지 보수 작업을 실행해야 하는 경우에는 구성 변경이 다음 주로 연기될 수 있습니다.

지원 티켓으로 요청된 변경은 주간 유지 보수 창 외에 긴급 지원에 적합한 경우가 아닌 이상 적용되지 않습니다.

Switchboard에서의 구성 변경

Switchboard는 사용자가 GitLab Dedicated 인스턴스의 제한적인 구성 변경을 수행할 수 있도록 지원합니다. Switchboard가 더 발전함에 따라 구성 변경이 추가로 이용 가능해질 것입니다.

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

Switchboard에서 수행된 구성 변경은 즉시 적용되거나 다음 예정된 주간 유지 보수 창에서 연기될 수 있습니다.

즉시 적용되는 경우, 변경 내용이 환경에 배포되는 데 최대 90분이 소요될 수 있습니다. 개별 변경 내용은 저장한 순서대로 적용되거나, 일괄로 저장한 후 한 번에 적용할 수도 있습니다.

인바운드 프라이빗 링크

AWS 프라이빗 링크를 사용하면 AWS VPC 내의 사용자 및 응용프로그램이 공개 인터넷을 경유하지 않고 GitLab Dedicated 엔드포인트에 안전하게 연결할 수 있습니다.

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

  1. 지원 티켓을 열어야 합니다. 지원 티켓의 본문에는 AWS 조직 내의 IAM 사용자 또는 역할에 대한 IAM principal을 포함해야 합니다. IAM principal은 IAM 역할 principal 또는 IAM 사용자 principal이어야 합니다. GitLab Dedicated은 이 IAM principal을 액세스 제어에 사용합니다. 이 IAM principal은 해당 서비스의 엔드포인트를 설정할 수 있는 유일한 역할입니다.
  2. IAM principal이 허용 디렉터리에 추가되면, GitLab은 엔드포인트 서비스를 생성하고 지원 티켓에서 Service Endpoint Name을 알려드립니다. 서비스 이름은 서비스 엔드포인트를 생성할 때 AWS에서 생성한 이름입니다.
    • GitLab은 프라이빗 DNS 이름의 도메인 확인을 처리하여 VPC 내 테넌트 인스턴스 도메인 이름의 DNS 해결을 프라이빗링크 엔드포인트로 변환합니다.
    • GitLab은 초기 온보딩 중에 지정한 가용 영역에서 엔드포인트 서비스를 사용 가능하게 만듭니다. 가용 영역을 지정하지 않았다면 GitLab은 일관된 가용 영역 ID를 무작위로 선택합니다.
  3. 사용 중인 AWS 계정에서 VPC 내에 엔드포인트 인터페이스를 생성하고 다음과 같은 설정을 구성하세요:
    • 서비스 엔드포인트 이름: 지원 티켓에서 제공한 이름 사용.
    • 프라이빗 DNS 이름 사용: 예.
    • 서브넷: 해당되는 모든 서브넷 선택.

엔드포인트를 생성한 후, 온보딩 중에 제공받은 인스턴스 URL을 사용하여 공개 인터넷을 경유하지 않고 VPC에서 GitLab Dedicated 인스턴스에 안전하게 연결할 수 있습니다.

아웃바운드 프라이빗 링크

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

아웃바운드 프라이빗 링크 사용 시 고려해야 할 사항:

  • 아웃바운드 프라이빗 링크를 사용하면 GitLab Dedicated 인스턴스가 AWS VPC 내에서 실행되는 서비스와 안전하게 통신할 수 있습니다. 이 유형의 연결로 웹훅을 실행할 수 있으며 대상 서비스가 실행 중인 VPC 내의 프로젝트 및 리포지터리를 가져오거나 미러하거나 다른 GitLab 기능을 사용하여 해당 서비스에 접근할 수 있습니다.
  • 동일한 지역의 VPC 간에만 프라이빗 링크를 설정할 수 있습니다. 따라서 전용 인스턴스를 위해 선택한 지역에서만 연결을 설정할 수 있습니다.
  • 엔드포인트 서비스를 지원하는 네트워크 로드 밸런서(NLB)는 전용 인스턴스가 배포된 최소한 한 가용 영역에서 사용 가능해야 합니다. 이는 us-east-1a와 같은 사용자 표시용 영역 이름이 아니라, 기본 가용 영역 ID입니다. 온보딩 시 지정하지 않은 경우에는 연결을 활성화하고 NLB가 해당 AZs에서 활성화되도록 하는 티켓을 올려야 하며,
    • 연결을 활성화한 후NLB가 해당 AZ에서 활성화되도록하는 티켓을 올리거나
    • 지정하지 않은 경우 연결을 활성화한 후 아마존 계정 팀에 AZ IDs를 요청하여 해당 AZ에 NLB를 활성화하도록 요청해야 합니다.

Switchboard의 Tenant Details 섹션에서 Reverse Private Link IAM Principal 속성을 볼 수 있습니다.

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

  1. 내부 서비스가 GitLab Dedicated에 사용할 수 있도록 엔드포인트 서비스를 생성하세요. 연관된 Service Endpoint Name을 새로운 지원 티켓에 제공하세요.
  2. 지원 티켓에서 GitLab은 내부 서비스에 연결을 시작할 IAM 역할의 ARN을 제공합니다. 이 ARN은 해당 서비스의 엔드포인트 서비스의 “허용된 주체” 디렉터리에 제공되어야 합니다. 자세한 정보는 AWS 문서를 참조하세요. 선택적이지만 명시적으로 추가하면, 단일 동작에서 전용이 연결할 수 있도록 Acceptance required를 No로 설정할 수 있습니다. Acceptance required를 Yes로 두면, 전용이 시작한 연결을 매뉴얼으로 수락해야 합니다.
  3. Endpoint를 사용하여 서비스에 연결하기 위해 전용 서비스는 DNS 이름이 필요합니다. 프라이빗 링크는 자동으로 내부 이름을 생성하지만 일반적으로 직접 사용할 수는 없습니다. 다음 두 가지 옵션이 있습니다:
    • 엔드포인트 서비스에서 프라이빗 DNS 이름을 활성화하고 필요한 확인을 수행한 후 지원 티켓에 사용 중임을 알리세요. 만약 당신의 엔드포인트 서비스가 Acceptance Required로 설정되어 있는 경우, 지원 티켓에 이를 명시해야 합니다. 이렇게 하면 전용이 프라이빗 DNS를 사용하도록 갱신할 때 연결을 수락하도록 기다릴 필요없이 연결을 초기화하면 됩니다.
    • 전용은 Dedicated AWS 계정에서 Private Hosted Zone (PHZ)를 관리하고 임의의 DNS 이름을 엔드포인트에 별칭 지어서 해당 이름으로 접근하는 요청을 내부로 연결합니다. 이는 하나의 엔드포인트에 액세스할 여러 DNS 이름/별칭(예: 환경 내에서 여러 서비스에 연결하려면 역방향 프록시를 실행 중인 경우) 또는 사용할 수 없는 공개 도메인을 가진 경우에 유용할 수 있습니다. 이 옵션을 사용하는 경우, 지원 티켓에서 전용이 이를 사용하고자 한다고 알리고 프라이빗 링크 엔드포인트로 해결될 DNS 이름 디렉터리을 제공하세요. 필요할 때마다 디렉터리을 업데이트할 수 있습니다.

그럼으로써 GitLab은 제공한 서비스 이름을 기반으로 테넌트 인스턴스에 필요한 Endpoint 인터페이스를 구성합니다. 테넌트 인스턴스에서 생성된 일치하는 아웃바운드 연결은 프라이빗 링크를 통해 당신의 VPC로 전달됩니다.

사용자 정의 인증서

일부 경우에는 GitLab Dedicated 인스턴스가 내부 서비스에 연결할 수 없는 경우가 있습니다. 이는 내부 서비스에서 공용 인증 기관(CA)를 사용하여 인증할 수 없는 인증서를 노출하기 때문입니다. 이러한 경우에는 사용자 정의 인증서가 필요합니다.

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

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

지원 요청을 통한 사용자 정의 인증서 추가

PrivateLink를 통해 서비스와 통신할 때 GitLab에게 사용자 정의 인증서를 추가해 달라는 요청을 하려면 커스텀 공개 인증서 파일을 지원 티켓에 첨부하시기 바랍니다.

GitLab Dedicated은 역방향 PrivateLink 연결 수를 10개로 제한합니다.

IP 허용 디렉터리

GitLab Dedicated을 사용하면 IP 허용 디렉터리을 통해 인스턴스에 액세스할 수 있는 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 Dedicated 인스턴스에 액세스할 수 있는 IP 주소의 쉼표로 구분된 디렉터리을 지원 티켓에 지정합니다. 그러면 해당 IP 주소가 인스턴스의 IP 허용 디렉터리에 추가됩니다.

SAML

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

필수 조건:

  • 필수 데이터를 GitLab에 보내기 전에 신원 공급자를 구성해야 합니다.

Switchboard를 사용하여 SAML 활성화

GitLab Dedicated 인스턴스에 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 Dedicated 인스턴스에 SAML을 활성화하려면:

  1. 필요한 변경 사항을 하려면 지원 티켓에 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",
  "name_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
  "security": {
    // 옵션
  },
  "auditor_groups": [
    // 옵션
  ],
  "external_groups": [
    // 옵션
  ],
  "required_groups": [
    // 옵션
  ],
}
  2. GitLab이 SAML 구성을 인스턴스에 배포한 후, 지원 티켓으로 알림을 받게 됩니다.
  3. SAML 구성이 성공적인지 확인하려면:
    • 인스턴스의 로그인 페이지에 SSO 로그인 버튼 설명이 표시되는지 확인합니다.
    • 인스턴스의 메타데이터 URL로 이동합니다 (https://INSTANCE-URL/users/auth/saml/metadata). 이 페이지를 사용하여 신원 공급자의 구성을 단순화하고 설정을 매뉴얼으로 확인할 수 있습니다.

요청 서명

SAML 요청 서명을 활성화하려면 인증서를 획들어야 합니다. 이 인증서는 공용 인증 기관(CA)에 임의의 공통 이름(CN)의 소유권을 증명할 필요가 없어 장점이 있는 자체 서명될 수 있습니다. SAML 요청 서명을 활성화하려면, 요청 서명을 위한 지원 티켓에서 요청 서명을 활성화하고 싶다는 것을 명시하십시오. GitLab은 서명할 인증서 서명 요청(CSR)을 보내드리는 데 함께 협력합니다. 또는 CSR은 공용 CA로 서명할 수 있습니다. 인증서가 서명되면, GitLab은 해당 인증서와 관련된 개인 키를 SAML 구성의 security 섹션에 추가합니다. GitLab에서 신원 공급자로부터의 인증 요청을 서명할 수 있습니다.

SAML 그룹

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

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

그룹 동기화

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

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

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

인스턴스에 사용자 추가

관리자는 스위치보드 사용자를 GitLab Dedicated 인스턴스에 추가할 수 있습니다. 사용자 유형은 다음과 같습니다:

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

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

  1. Tenants 페이지에서 테넌트 인스턴스 옆에 있는 관리를 선택하십시오.
  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 Principal ARN(사용자 또는 역할) 디렉터리을 포함하십시오.
  2. 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시의 로그가 포함됩니다. 로그는 Amazon Kinesis Data Firehose를 사용하여 버킷으로 스트리밍됩니다.