GitLab Dedicated

GitLab Dedicated은 완전히 격리된 단일 테넌트 SaaS 솔루션이며 다음과 같습니다:

GitLab, Inc.에서 호스팅 및 관리됨.
선택한 AWS 클라우드 리전에 배포됨. 사용 가능한 AWS 리전을 확인하세요.

GitLab Dedicated는 플랫폼 관리 부담을 줄여 운영 효율성을 높이고 조직의 위험을 줄이며 속도와 민첩성을 향상시킵니다. 각 GitLab Dedicated 인스턴스는 재해 복구와 함께 고가용성을 가지며 선택한 클라우드 리전에 배포됩니다. GitLab 팀이 각 격리된 인스턴스의 유지 및 운영을 완전히 관리하므로 고객은 최신 제품 개선 사항에 접근할 수 있으면서도 가장 복잡한 규정 준수 기준을 충족할 수 있습니다.

이는 규제가 엄격한 산업의 기업과 조직을 위한 선택한 오퍼링으로, 복잡한 규정 준수 및 데이터 소재지 요구 사항을 가지고 있습니다.

사용 가능한 기능

데이터 소재지

GitLab Dedicated을 사용하면 데이터를 저장할 클라우드 리전을 선택할 수 있습니다. 온보딩 후 Dedicated 인스턴스를 배포할 클라우드 리전을 선택하세요. 일부 AWS 리전은 제한된 기능을 가지고 있어 결과적으로 해당 리전에 제품 인스턴스를 배포할 수 없습니다. GitLab Dedicated의 사용 가능한 AWS 리전 디렉터리을 참조하세요.

고급 검색

GitLab Dedicated은 고급 검색 기능을 사용합니다.

가용성 및 확장성

GitLab Dedicated은 고가용성이 활성화된 GitLab Cloud Native Hybrid 참조 아키텍처의 수정된 버전을 활용합니다. 온보딩 시, GitLab은 사용자 수에 기초하여 가장 가까운 참조 아키텍처 크기에 맞추어 매칭합니다. 현재 서비스 수준 목표에 대해 알아보세요.

게시된 참조 아키텍처는 GitLab Dedicated 환경 내에 배포된 클라우드 리소스를 정의하는 데 출발점으로 작용하지만, 포괄적이지는 않습니다. GitLab Dedicated은 향상된 보안과 환경의 안정성을 위해 표준 참조 아키텍처에 포함되지 않은 추가 클라우드 공급자 서비스를 활용합니다. 따라서 GitLab Dedicated의 비용은 표준 참조 아키텍처의 비용과 다릅니다.

재해 복구

GitLab Dedicated에 온보딩할 때, 재해 시 GitLab Dedicated 인스턴스를 복구할 Secondary AWS 리전을 제공할 수 있습니다. 모든 GitLab Dedicated 데이터 스토어(데이터베이스 및 Git 리포지터리 포함)의 정기적인 백업이 수행되고 정기적으로 테스트되며 원하는 Secondary 리전에 저장됩니다. GitLab Dedicated은 또한 이러한 백업의 사본을 더 큰 재복구성을 위해 선택한 다른 클라우드 리전에 저장할 수 있는 기능을 제공합니다.

자세한 정보는 GitLab Dedicated의 복구 계획 및 RPO 및 RTO 목표를 참조하세요. 이러한 목표는 Primary 및 Secondary 리전이 GitLab Dedicated에서 지원되는 경우에만 사용할 수 있습니다. GitLab Dedicated의 사용 가능한 AWS 리전 디렉터리을 참조하세요.

보안

인증 및 권한

GitLab Dedicated은 인스턴스 수준의 SAML OmniAuth 기능을 지원합니다. GitLab Dedicated 인스턴스는 서비스 제공자로 작용하며, GitLab이 IdP와 통신하기 위해 필요한 구성을 제공해야 합니다. 자세한 내용은 인스턴스용 SAML을 구성하는 방법을 참조하세요.

SAML 요청 서명, 그룹 동기화 및 SAML 그룹을 지원합니다.

안전한 네트워킹

GitLab Dedicated은 기본적으로 공용 연결성을 지원하며 IP 허용 디렉터리을 지원합니다. GitLab Dedicated 인스턴스에 액세스할 수 있는 IP 주소 디렉터리을 선택적으로 지정할 수 있습니다. 이후에 IP 허용 디렉터리에 없는 IP가 인스턴스에 액세스하려고 하는 경우 연결이 거부됩니다.

AWS PrivateLink를 통한 사설 연결도 옵션으로 제공됩니다. 들어오는 및 나가는 PrivateLinks를 모두 지원합니다. 공인 인증서를 사용하지 않는 내부 자원에 대한 내부 리소스에 연결할 때, GitLab이 신뢰하는 인증서 디렉터리을 지정할 수 있습니다. 이러한 인증서는 인스턴스 구성을 업데이트할 때 제공할 수 있습니다.

암호화

데이터는 새로운 암호화 표준을 사용하여 휴식 및 이동 중에 암호화됩니다.

Bring your own key encryption

온보딩 과정에서 GitLab이 Dedicated 인스턴스에 저장되는 데이터를 암호화하는 데 사용하는 본인의 AWS KMS 암호화 키를 지정할 수 있습니다. 이를 통해 GitLab에 저장하는 데이터에 대한 완전한 제어 권한을 얻을 수 있습니다.

SMTP

GitLab Dedicated에서 전송되는 이메일은 Amazon Simple Email Service (Amazon SES)를 사용합니다. Amazon SES와의 연결은 암호화됩니다.

규정 준수

인증

GitLab Dedicated은 다음 규정 준수 인증을 제공합니다:

SOC 2 유형 1 보고서 (보안 및 기밀성 기준)
ISO/IEC 27001:2013
ISO/IEC 27017:2015
ISO/IEC 27018:2019
TISAX 평가 레벨 3

격리

단일 테넌트 SaaS 솔루션으로서, GitLab Dedicated은 GitLab 환경의 인프라 수준 격리를 제공합니다. 귀하의 환경은 다른 테넌트를 위한 별도의 AWS 계정에 배치됩니다. 이 AWS 계정에는 GitLab 애플리케이션을 호스팅하기 위한 모든 기본 인프라가 포함되어 있으며 귀하의 데이터는 계정 범위 내에 유지됩니다. 당사가 인프라를 관리하면서 애플리케이션은 귀하가 관리합니다. 테넌트 환경은 또한 GitLab.com과 완전히 격리됩니다.

접근 제어

GitLab Dedicated는 최소 권한 원칙을 준수하여 고객 테넌트 환경의 액세스를 제어합니다. 테넌트 AWS 계정은 상위 수준의 GitLab Dedicated AWS 부상위 조직에 속합니다. AWS 조직의 액세스는 선택된 GitLab 팀 구성원으로 제한됩니다. AWS 조직 내의 모든 사용자 계정은 전반적인 GitLab 액세스 관리 정책을 따릅니다. 고객 테넌트 환경으로의 직접 액세스는 단일 허브 계정으로 제한됩니다. GitLab Dedicated 제어 플레인은 테넌트 계정을 관리할 때 허브 계정을 사용하여 자동화된 작업을 수행합니다. 마찬가지로, GitLab Dedicated 엔지니어에게는 고객 테넌트 환경에 직접 액세스할 수 있는 권한이 없습니다. 고신묘 상의 문제를 해결하기 위해 테넌트 환경의 리소스에 액세스가 필요한 비상용 상황에서, GitLab 엔지니어는 해당 리소스를 관리하기 위해 허브 계정을 통해 거쳐야 합니다. 이는 승인 프로세스를 거친 후, 엔지니어가 허브 계정을 통해 일시적으로 테넌트 리소스에 액세스하기 위해 IAM 역할을 가정함으로써 이루어집니다. 허브 계정 및 테넌트 계정 내의 모든 작업은 CloudTrail에 기록됩니다.

테넌트 계정 내에서 GitLab은 AWS GuardDuty에서 침입 탐지 및 악성 코드 검사 기능을 활용합니다. 인프라 로그는 GitLab 보안 사고 대응 팀에 의해 이상 사건을 탐지하기 위해 모니터링됩니다.

감사 및 관측

GitLab Dedicated는 애플리케이션이 생성하는 감사 및 시스템 로그에 액세스를 제공합니다.

유지 보수

GitLab은 매주 유지 보수 창문을 활용하여 인스턴스를 최신 상태로 유지하고, 보안 문제를 해결하며, 환경의 전반적인 신뢰성과 성능을 보장합니다.

업그레이드

GitLab은 매월 고객이 선호하는 유지 보수 창문에서 최신 보안 릴리스로 인스턴스를 업그레이드합니다. 최신 GitLab 릴리스의 한 단계 뒤인 16.7 버전에서 GitLab Dedicated가 실행됩니다.

예정되지 않은 유지 보수

GitLab은 인스턴스의 보안, 가용성 또는 신뢰성에 영향을 미치는 중대한 문제를 해결하기 위해 예정되지 않은 유지 보수를 진행할 수 있습니다.

응용 프로그램

GitLab Dedicated는 지원되는 기능을 제외한 Self-managed Ultimate 기능 세트과 함께 제공됩니다.

GitLab Pages

GitLab Dedicated에서는 정적 웹 사이트를 호스팅하기 위해 GitLab Pages를 사용할 수 있습니다. 도메인 이름은 tenant_name.gitlab-dedicated.site이며, 여기서 tenant_name은 인스턴스 URL과 동일합니다.

GitLab Pages 액세스 제어를 사용하여 Pages 웹 사이트의 액세스를 제어할 수 있습니다.

또한, IP 허용 디렉터리을 사용하여 Pages 웹 사이트의 액세스를 제한할 수 있습니다. GitLab Dedicated 인스턴스의 기존 IP 허용 디렉터리은 적용됩니다.

다음과 같은 GitLab Pages 기능을 사용할 수 없습니다:

사용자 정의 도메인
PrivateLink 액세스
인증 범위 변경

또한, GitLab Pages:

Geo가 활성화된 경우 기본 사이트에서만 작동합니다.
GitLab Dedicated로의 인스턴스 이전의 일부로 포함되지 않습니다.

GitLab Dedicated의 GitLab Pages는 모든 고객에 대해 기본적으로 활성화되어 있습니다.

GitLab Runners

GitLab에서 호스팅

Status: Beta

2024년 1월 31일에 GitLab은 폐쇄된 베타에서 호스팅 러너를 발표했습니다.

GitLab Dedicated용 호스팅 러너를 사용하면 유지 관리 오버헤드 없이 CI/CD 워크로드를 확장할 수 있습니다.

호스팅 러너의 베타 릴리스는 다음과 같은 기능을 제공합니다:

인스턴스 수준의 Linux 기반 러너
GitLab Dedicated와 동일한 원칙을 따라 다른 테넌트와 완전히 격리
자동 크기 조정
GitLab에서 완전히 관리

고객의 요구에 따라 추가 기능이 포함되며, 제한된 범위와 일반적으로 사용 가능한 범위로 이어집니다.

Dedicated용 호스팅 러너는 GitLab Dedicated 고객에게 초대를 통해 제공됩니다. Dedicated용 호스팅 러너의 폐쇄 베타에 참여하려면 고객 성공 관리자 또는 계정 담당자에게 문의하세요.

러너 IP 범위 요청

GitLab에서 호스팅하는 러너용 IP 범위는 요청에 따라 사용할 수 있습니다. IP 범위는 최상의 노력으로 유지되며 베타 동안 인프라의 변경으로 인해 언제든지 변경될 수 있습니다. 고객 성공 관리자 또는 계정 담당자에게 문의하세요.

Linux (x86-64)용 이용 가능한 머신 유형

베타 동안 사용 가능한 인스턴스 러너는 EC2 M7i 일반용 머신을 사용합니다.

Bring Your Own

GitLab Dedicated에서는 고객이 소유하거나 관리하는 인프라에 GitLab 러너 애플리케이션을 설치해야 합니다. AWS에서 GitLab 러너를 호스팅하는 경우 러너 VPC에서 GitLab Dedicated 엔드포인트로의 안전한 연결 설정을 통해 러너 플릿의 요청을 공개 인터넷을 통하지 않을 수 있습니다. 네트워킹 옵션에서 자세히 알아보세요.

마이그레이션

GitLab Dedicated로 데이터를 마이그레이션하는 데 도움을 받으려면 다음 옵션 중 하나를 선택할 수 있습니다:

다른 GitLab 인스턴스에서 마이그레이션할 때 다음 중 하나를 사용하여 그룹 및 프로젝트를 가져올 수 있습니다:
- 직접 전송 사용
- 직접 전송 API 사용
타사 서비스에서 마이그레이션할 때 GitLab importers를 사용할 수 있습니다.
전문 서비스를 활용할 수도 있습니다.

사용할 수 없는 기능

GitLab 애플리케이션 기능

다음 GitLab 애플리케이션 기능은 사용할 수 없습니다:

LDAP, 스마트 카드 또는 Kerberos 인증
다중 로그인 공급자
FortiAuthenticator 또는 FortiToken 2FA
이메일 답장
서비스 데스크
GitLab AI 기능(단편화 페이지를 참조하세요)
GitLab 사용자 인터페이스 외부에서 구성해야 하는 사용 가능한 기능 이외의 기능
GitLab 피처 플래그과 상호 작용
기본적으로 off로 토글된 피처 플래그 뒤에 숨겨진 모든 기능과 기능
다음 기능은 지원되지 않습니다:
- Mattermost
- 서버 측 Git 후크.