GitLab Dedicated 네트워크 액세스 및 보안

요약

이 설정을 사용하여 GitLab Dedicated 인스턴스가 인터넷 및 개인 인프라에 연결하는 방식을 제어합니다. 기본 your-tenant.gitlab-dedicated.com 대신 GitLab Dedicated 인스턴스에 액세스하기 위한 사용자 정의 도메인을 구성할 수 있습니다.

이 설정을 사용하여 GitLab Dedicated 인스턴스가 인터넷 및 개인 인프라에 연결하는 방식을 제어합니다. 사용자 정의 도메인 구성, 외부 서비스를 위한 인증 기관 관리, AWS PrivateLink를 통한 개인 네트워크 연결 설정, IP 허용 목록으로 액세스 제한, 인스턴스에서 사용하는 아웃바운드 IP 확인이 가능합니다.

사용자 정의 도메인#

기본 your-tenant.gitlab-dedicated.com 대신 GitLab Dedicated 인스턴스에 액세스하기 위한 사용자 정의 도메인을 구성할 수 있습니다.

사용자 정의 도메인을 추가할 때:

도메인이 인스턴스에 액세스하는 데 사용되는 외부 URL에 포함됩니다.
기본 tenant.gitlab-dedicated.com 도메인을 사용하여 인스턴스에 연결하는 것은 더 이상 사용할 수 없습니다.

GitLab은 Let's Encrypt를 사용하여 사용자 정의 도메인에 대한 SSL/TLS 인증서를 자동으로 관리합니다. Let's Encrypt는 HTTP-01 챌린지를 사용하여 도메인 소유권을 확인하며, 이를 위해 다음이 필요합니다:

CNAME 레코드가 DNS를 통해 공개적으로 확인 가능해야 합니다.
90일마다 자동 인증서 갱신을 위한 동일한 공개 확인 프로세스.

AWS PrivateLink와 같은 개인 네트워킹으로 구성된 인스턴스의 경우, 다른 모든 액세스가 개인 네트워크로 제한되더라도 공개 DNS 확인은 인증서 관리가 올바르게 작동하도록 보장합니다.

GitLab Dedicated는 두 가지 구성 방법을 통해 사용자 정의 도메인을 지원합니다:

표준 구성: CNAME 레코드와 Let's Encrypt 인증서를 사용합니다. 자체 DNS 레코드를 구성하고 지원을 통해 도메인 활성화를 요청합니다.
Cloudflare 보안 구성: NS 레코드와 Let's Encrypt 인증서를 사용합니다. GitLab이 DNS 구성 세부 정보를 제공하고 지원과 협력하여 구현합니다.

어떤 구성 방법이 인스턴스에 적용되는지 결정하려면 고객 성공 관리자에게 문의하세요.

사용자 정의 도메인 세부 정보 보기#

Custom domains 섹션은 GitLab Dedicated 인스턴스의 활성 도메인 구성을 표시합니다:

GitLab instance domain: GitLab 인스턴스의 사용자 정의 도메인.
Registry domain: 컨테이너 레지스트리의 사용자 정의 도메인.
KAS domain: Kubernetes(KAS)용 GitLab 에이전트 서버의 사용자 정의 도메인.

다음을 위해 이 정보를 사용합니다:

현재 사용자 정의 도메인 구성 확인.
외부 통합을 위한 도메인 참조.
DNS 관리를 위한 구성 세부 정보 복사.

사용자 정의 도메인 세부 정보를 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Custom domains를 확장합니다.

DNSSEC 세부 정보#

사용자 정의 도메인이 Cloudflare 웹 애플리케이션 방화벽(WAF)으로 구성된 경우, Switchboard는 FedRAMP 규정 준수를 위한 Cloudflare 네임서버 및 DNSSEC 파라미터를 포함한 추가 구성 세부 정보를 표시합니다.

추가 세부 정보는 다음을 포함합니다:

Cloudflare 네임서버: Cloudflare 관리 도메인에 대한 DNS 네임서버.
키 태그: DNSSEC 키의 숫자 식별자.
알고리즘: 사용된 암호화 알고리즘(일반적으로 SHA-256이 있는 ECDSA P-256의 경우 13).
다이제스트 유형: 사용된 해시 알고리즘(일반적으로 SHA-256의 경우 2).
다이제스트: 공개 키의 암호화 해시.

DNS 공급자와의 DNS 위임 및 DNSSEC 유효성 검사를 구성하는 데 이러한 값을 사용합니다.

표준 구성#

이 구성을 사용하면 도메인이 CNAME 레코드를 사용하여 GitLab 인스턴스에 직접 연결됩니다. 자체 DNS 레코드를 구성하고 지원을 통해 도메인 활성화를 요청합니다.

Note

SSL 인증서 관리를 위해 사용자 정의 도메인은 개인 네트워크를 통해 인스턴스에 액세스하더라도 공개 인터넷에서 액세스할 수 있어야 합니다.

DNS 레코드 구성#

필수 조건:

도메인 호스트의 DNS 설정에 대한 액세스.

DNS 레코드를 구성하려면:

도메인 호스트의 웹사이트에 로그인합니다.
DNS 설정으로 이동합니다.
사용자 정의 도메인을 GitLab Dedicated 인스턴스로 가리키는 CNAME 레코드를 추가합니다. 예를 들어:
```
gitlab.my-company.com.  CNAME  my-tenant.gitlab-dedicated.com
```
선택 사항. 도메인에 기존 CAA 레코드가 있는 경우 Let's Encrypt를 유효한 인증 기관으로 포함하도록 업데이트합니다. 예를 들어:
```
gitlab.my-company.com.  IN  CAA 0 issue "pki.goog"
gitlab.my-company.com.  IN  CAA 0 issue "letsencrypt.org"
```
CAA 레코드는 도메인에 대한 인증서를 발급할 수 있는 인증 기관을 정의합니다.
변경 사항을 저장하고 DNS 변경 사항이 적용될 때까지 기다립니다.

사용자 정의 도메인을 사용하는 동안 DNS 레코드를 유지합니다.

사용자 정의 도메인 활성화#

필수 조건:

DNS 레코드를 구성했습니다.

사용자 정의 도메인을 활성화하려면:

지원 티켓을 제출합니다.
지원 티켓에서 다음을 지정합니다:
- 사용자 정의 도메인 이름. 예를 들어 gitlab.company.com.
- 컨테이너 레지스트리 및 Kubernetes용 GitLab 에이전트 서버에 사용자 정의 도메인이 필요한 경우 사용하려는 도메인 이름을 포함합니다. 예를 들어 registry.company.com 및 kas.company.com.

Cloudflare 보안 구성#

이 구성을 사용하면 도메인이 NS 레코드를 사용하여 GitLab에 위임되어야 하며, 이를 통해 트래픽이 Cloudflare 웹 애플리케이션 방화벽(WAF)을 통해 라우팅됩니다. Cloudflare는 도메인의 모든 DNS 설정을 관리하고 향상된 보안 기능을 제공합니다.

Note

이 방법은 고객 성공 관리자와의 협력이 필요합니다. 구성은 인스턴스의 유지보수 기간 동안 적용됩니다.

사용자 정의 도메인 요청#

사용자 정의 도메인을 요청하려면:

지원 티켓을 제출합니다.
지원 티켓에서 다음을 지정합니다:
- 사용자 정의 도메인 이름. 예를 들어 gitlab.company.com.
- 컨테이너 레지스트리 및 Kubernetes용 GitLab 에이전트 서버에 사용자 정의 도메인이 필요한 경우 사용하려는 도메인 이름을 포함합니다. 예를 들어 registry.company.com 및 kas.company.com.
- 규정 준수 요구 사항. 예를 들어 FedRAMP.

GitLab은 Cloudflare에서 도메인을 구성하고 다음을 제공합니다:

name1.ns.cloudflare.com 및 name2.ns.cloudflare.com과 같은 두 개의 Cloudflare 네임서버.
DNSSEC 파라미터(FedRAMP 고객 전용), 다음을 포함:
- 키 태그: 숫자 식별자 (GitLab에서 제공)
- 알고리즘: 일반적으로 13(ECDSA P-256 with SHA-256) 또는 8(RSA/SHA-256)
- 다이제스트 유형: 일반적으로 2(SHA-256)
- 다이제스트: 공개 키의 암호화 해시 (GitLab에서 제공)

DNS 레코드 구성#

DNS 공급자에서 서브도메인을 Cloudflare에 위임하도록 NS 레코드를 구성합니다.

필수 조건:

도메인 호스트의 DNS 설정에 대한 액세스.
GitLab이 네임서버와 DNSSEC 파라미터를 제공했습니다(해당하는 경우).

DNS 레코드를 구성하려면:

도메인 호스트의 웹사이트에 로그인합니다.
DNS 설정으로 이동합니다.

GitLab에서 제공한 네임서버를 사용하여 NS 레코드를 만듭니다. 예를 들어:

gitlab.company.com.     NS    name1.ns.cloudflare.com.
gitlab.company.com.     NS    name2.ns.cloudflare.com.

동일한 서브도메인에 대해 충돌하는 A, AAAA 또는 CNAME 레코드를 제거합니다.

FedRAMP 고객 전용. GitLab에서 제공한 값을 사용하여 DS 레코드를 추가합니다:

gitlab.company.com.     DS    [Key Tag] [Algorithm] [Digest Type] [Digest]

예를 들어:

gitlab.company.com.     DS    12345 13 2 A1B2C3D4E5F6...

변경 사항을 저장합니다. DNS 변경 사항은 적용되는 데 최대 48시간이 걸릴 수 있습니다.

구성을 확인합니다:

# 네임서버 위임 확인
dig +short NS gitlab.company.com

# DNS 확인 확인
dig gitlab.company.com

# DNSSEC 확인 (구성된 경우)
dig +dnssec gitlab.company.com

DNS 구성이 완료되었음을 지원 티켓을 통해 GitLab에 알립니다.

GitLab은 다음을 수행합니다:

DNS 위임을 확인합니다.
SSL/TLS 인증서를 구성합니다.
사용자 정의 도메인이 활성화된 시기를 확인합니다.

컨테이너 레지스트리 네트워크 액세스#

컨테이너 레지스트리 FQDN(완전 정규화된 도메인 이름)은 인스턴스의 컨테이너 레지스트리 데이터를 저장하는 S3 버킷을 식별합니다.

컨테이너 레지스트리 FQDN 보기#

S3 버킷의 IP 주소는 시간이 지남에 따라 변경될 수 있으므로 IP 주소 대신 FQDN을 사용하여 레지스트리 스토리지 위치를 참조하는 방화벽 규칙 및 네트워크 정책을 구성합니다.

컨테이너 레지스트리 FQDN을 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Resource access를 확장합니다.
Container registry에서 Copy to clipboard([copy-to-clipboard])를 선택합니다.

외부 서비스에 대한 사용자 정의 인증 기관#

GitLab Dedicated는 HTTPS를 통해 외부 서비스에 연결할 때 인증서를 검증합니다. 기본적으로 GitLab Dedicated는 공개적으로 인식된 인증 기관만 신뢰하고 신뢰할 수 없는 인증 기관의 인증서가 있는 서비스에 대한 연결을 거부합니다.

외부 서비스에서 개인 또는 내부 인증 기관의 인증서를 사용하는 경우 해당 인증 기관을 GitLab Dedicated 인스턴스에 추가해야 합니다.

다음의 경우 사용자 정의 인증 기관이 필요할 수 있습니다:

내부 웹훅 엔드포인트에 연결.
개인 컨테이너 레지스트리에서 이미지 가져오기.
기업 공개 키 인프라 뒤의 온프레미스 서비스와 통합.

사용자 정의 인증서 추가#

인증서 체인 블록(단일 텍스트 블록의 여러 인증서)은 지원되지 않습니다. 체인에 여러 인증서가 있는 경우 각 인증서를 별도로 추가합니다.

사용자 정의 인증서를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Custom certificate authorities를 확장합니다.
+ Add Certificate를 선택합니다.
텍스트 박스에 단일 인증서를 붙여넣습니다. -----BEGIN CERTIFICATE----- 및 -----END CERTIFICATE----- 줄을 포함합니다.
Save를 선택합니다.
체인의 각 추가 인증서에 대해 4-6단계를 반복합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

Switchboard를 사용하여 사용자 정의 인증서를 추가할 수 없는 경우 지원 티켓을 열고 각 사용자 정의 인증서를 별도의 파일로 첨부합니다.

AWS PrivateLink 연결#

AWS PrivateLink를 사용하면 트래픽이 공개 인터넷을 통해 라우팅되지 않고 AWS 인프라와 GitLab Dedicated 인스턴스 간에 개인 네트워크 연결이 가능합니다. 모든 트래픽이 AWS 네트워크 내에 유지되므로 외부 위협에 대한 노출이 줄어들고 개인 네트워킹에 대한 규정 준수 요구 사항을 충족하는 데 도움이 됩니다.

GitLab Dedicated는 두 가지 유형의 PrivateLink 연결을 지원합니다:

인바운드 PrivateLink 연결: VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결됩니다. 공개 인터넷을 통해 인스턴스에 액세스할 수 없도록 제한하려는 경우 사용합니다.
아웃바운드 PrivateLink 연결: GitLab Dedicated 인스턴스와 호스팅 러너가 VPC에서 실행 중인 서비스에 개인적으로 연결됩니다. 웹훅, 프로젝트 미러링, 시크릿 관리자, 또는 인프라로의 배포에 사용합니다.

PrivateLink 연결은 GitLab Dedicated 인스턴스와 동일한 AWS 리전에 있어야 하며, 기본 및 보조 AWS 리전에서만 엔드포인트 서비스를 만들 수 있습니다.

AWS PrivateLink에 대한 자세한 내용은 AWS PrivateLink란 무엇인가?를 참조하세요.

인바운드 PrivateLink 연결#

인바운드 PrivateLink 연결을 사용하면 VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결할 수 있습니다.

엔드포인트 서비스를 만들 때 액세스를 제어하는 IAM 주체를 지정합니다. 지정한 IAM 주체만 인스턴스에 연결하기 위한 VPC 엔드포인트를 만들 수 있습니다.

각 엔드포인트 서비스는 온보딩 중에 선택되거나 무작위로 선택되는 두 개의 가용 영역에서 사용 가능합니다.

IAM 주체는 각 리전에 대해 독립적으로 구성됩니다. 리전 간에 동일한 주체를 재사용하거나, 보조 리전이 별도의 AWS 계정을 사용하는 경우 다른 주체를 사용할 수 있습니다.

인바운드 PrivateLink 연결 만들기#

VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결할 수 있도록 인바운드 PrivateLink 연결을 만듭니다.

리전 장애 조치(failover) 중에도 이 연결을 사용할 수 있게 유지하려면 보조 리전 엔드포인트를 구성합니다. 이를 구성하지 않으면 기본 리전을 사용할 수 없게 될 때 인스턴스에 개인적으로 액세스할 수 없습니다.

필수 조건:

구성하려는 각 리전에 VPC가 있어야 합니다.
GitLab에서 제공한 엔드포인트 서비스를 검색하고, 인터페이스 VPC 엔드포인트를 만들고, private DNS가 활성화된 경우 Route 53 프라이빗 호스팅 영역과 연결할 권한이 있는 IAM 주체.
역할 경로가 없는, 역할 이름만 있는 IAM 주체.
- 유효: arn:aws:iam::AWS_ACCOUNT_ID:role/RoleName
- 유효하지 않음: arn:aws:iam::AWS_ACCOUNT_ID:role/somepath/AnotherRoleName

인바운드 PrivateLink 연결을 만들려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Inbound PrivateLink connections를 확장합니다.
Add endpoint service를 선택합니다.
리전을 선택합니다.
IAM principals에서 엔드포인트 서비스에 대한 연결을 시작할 수 있는 AWS 사용자 또는 역할을 추가합니다. IAM 주체는 IAM 역할 주체 또는 IAM 사용자 주체여야 합니다.

AWS 계정에서 VPC 엔드포인트를 만드는 역할 또는 사용자에게 다음 권한이 있는 정책을 연결합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GitLabDedicatedInboundPrivateLink",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcEndpoint",
        "ec2:DescribeVpcEndpointServices",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeVpcs",
        "route53:AssociateVPCWithHostedZone"
      ],
      "Resource": "*"
    }
  ]
}

권장. 보조 리전을 구성하려면 Regions에서 Secondary region을 선택합니다. 이렇게 하면 지정된 IAM 주체로 두 리전 모두에 엔드포인트 서비스가 생성됩니다.
Save를 선택합니다. GitLab이 엔드포인트 서비스를 만들고 서비스 엔드포인트 이름이 Configuration 페이지에서 사용 가능해집니다.

그런 다음, 구성한 각 리전에 대해 AWS 설정을 완료합니다:

AWS 계정에서 VPC에 엔드포인트 인터페이스를 만듭니다.
다음 설정으로 엔드포인트 인터페이스를 구성합니다:
- Service endpoint name: Switchboard의 Configuration 페이지에서 해당 리전의 이름을 사용합니다.
- Private DNS names enabled: Yes를 선택합니다.
- Subnets: 일치하는 모든 서브넷을 선택합니다.
온보딩 중에 제공된 인스턴스 URL을 사용하여 VPC에서 GitLab Dedicated 인스턴스에 연결합니다.

AWS VPC 엔드포인트 설정을 자동화하려면 terraform-inbound-privatelink Terraform 모듈을 사용할 수 있습니다. 이 모듈은 DNS를 전환할 때 필요한 Route 53 레코드도 출력합니다.

KAS 및 레지스트리를 위한 DNS 구성#

개인 네트워크를 통해 KAS(Kubernetes용 GitLab 에이전트) 및 컨테이너 레지스트리에 액세스하려면 VPC에 추가 DNS 구성을 만듭니다.

필수 조건:

인바운드 PrivateLink 연결을 구성했습니다.
AWS 계정에서 Route 53 프라이빗 호스팅 영역을 만들 권한이 있습니다.

KAS 및 레지스트리를 위한 DNS를 구성하려면:

AWS 콘솔에서 gitlab-dedicated.com에 대한 프라이빗 호스팅 영역을 만들고 인바운드 PrivateLink 연결이 있는 VPC와 연결합니다.
프라이빗 호스팅 영역을 만든 후 다음 DNS 레코드를 추가합니다(example을 인스턴스 이름으로 교체):
1. GitLab Dedicated 인스턴스에 대한 A 레코드를 만듭니다:
  - 전체 인스턴스 도메인(예: example.gitlab-dedicated.com)을 VPC 엔드포인트로 Alias로 확인하도록 구성합니다.
  - 가용 영역 참조가 없는 VPC 엔드포인트를 선택합니다.
2. KAS와 레지스트리 모두가 GitLab Dedicated 인스턴스 도메인(example.gitlab-dedicated.com)으로 확인되도록 CNAME 레코드를 만듭니다:
  - kas.example.gitlab-dedicated.com
  - registry.example.gitlab-dedicated.com
연결을 확인하려면 VPC의 리소스에서 다음 명령을 실행합니다:
```
nslookup kas.example.gitlab-dedicated.com
nslookup registry.example.gitlab-dedicated.com
nslookup example.gitlab-dedicated.com
```
모든 명령이 VPC 내의 개인 IP 주소로 확인되어야 합니다.

이 구성은 특정 IP 주소 대신 VPC 엔드포인트 인터페이스를 사용하므로 IP 주소가 변경되어도 안정적입니다.

GitLab Pages를 위한 DNS 구성#

개인 네트워크를 통해 GitLab Pages에 액세스하려면 VPC에 추가 DNS 구성을 만듭니다.

GitLab Pages를 위한 DNS를 구성하려면:

AWS 콘솔에서 <tenant_name>.gitlab-dedicated.site에 대한 프라이빗 호스팅 영역을 만들고 인바운드 PrivateLink 연결이 있는 VPC와 연결합니다.
프라이빗 호스팅 영역을 만든 후 다음 DNS 레코드를 추가합니다:
1. VPC 엔드포인트에 대한 Apex A Alias 레코드를 만듭니다.
2. <tenant_name>.gitlab-dedicated.site를 가리키는 *.<tenant_name>.gitlab-dedicated.site에 대한 와일드카드 CNAME을 만듭니다.

객체 스토리지를 위한 프라이빗 S3 액세스#

GitLab Dedicated는 컨테이너 이미지, CI/CD 작업 아티팩트, LFS 객체, 패키지, 사용자 업로드를 포함한 객체 스토리지 데이터를 S3 버킷에 저장합니다. 클라이언트가 이러한 객체 중 하나를 다운로드하면 GitLab은 사전 서명된 S3 URL을 반환하고 클라이언트는 S3에 직접 연결합니다. 프록시 다운로드는 지원되지 않으므로, 이 연결은 기본적으로 공개 인터넷을 통해 이루어집니다.

객체 스토리지 트래픽을 AWS 네트워크에 유지하려면 인바운드 PrivateLink 연결을 호스팅하는 VPC에 S3 VPC 엔드포인트를 만들어 S3에 개인적으로 연결하세요. 이 트래픽을 제어하고 감사하기 위해 VPC 엔드포인트 정책을 연결할 수 있습니다. GitLab Dedicated 인스턴스에서는 구성을 변경할 필요가 없습니다.

필요한 엔드포인트는 클라이언트가 실행되는 위치에 따라 달라집니다:

클라이언트 위치	만들어야 하는 엔드포인트
VPC 내부(예: EC2 또는 EKS 러너)	S3 게이트웨이 엔드포인트
온프레미스(Direct Connect 또는 Site-to-Site VPN을 통해)	S3 인터페이스 엔드포인트 및 Route 53 Resolver 인바운드 엔드포인트, 그리고 동일한 VPC의 S3 게이트웨이 엔드포인트

게이트웨이 엔드포인트는 VPC 라우팅 테이블의 대상이므로 VPC 내부의 클라이언트만 사용할 수 있습니다. Direct Connect, Site-to-Site VPN 또는 VPC 피어링을 통해 VPC에 접근하는 클라이언트는 서브넷에 개인 IP 주소를 갖는 인터페이스 엔드포인트를 사용해야 합니다. 게이트웨이 엔드포인트에는 추가 요금이 없습니다. 인터페이스 엔드포인트와 Resolver 엔드포인트에는 시간당 요금과 데이터 처리 요금이 부과됩니다.

두 유형의 엔드포인트는 동일한 VPC에 공존할 수 있습니다. 이 구성은 인바운드 엔드포인트에만 프라이빗 DNS 활성화를 사용하므로 AWS는 해당 VPC에 S3 게이트웨이 엔드포인트를 요구하며, VPC 내부의 클라이언트는 계속 이를 사용합니다. 자세한 내용은 AWS 문서의 프라이빗 DNS를 참조하세요.

프라이빗 S3 액세스가 필요한 각 VPC에 대해 이 구성을 반복하세요. 리전 장애 조치 중에도 프라이빗 S3 액세스를 사용할 수 있도록 보조 리전에도 구성하세요.

두 시나리오의 AWS 설정을 자동화하려면 object-storage-private-access Terraform 모듈을 사용할 수 있습니다. 이 모듈은 다음 섹션에서 설명하는 엔드포인트를 만들고 온프레미스 DNS 서버를 위한 DNS 전달 구성을 출력합니다.

VPC에서 프라이빗 S3 액세스 구성#

필수 조건:

인바운드 PrivateLink 연결을 구성했습니다.
AWS 계정에서 VPC 엔드포인트를 만들고 라우팅 테이블을 수정할 권한이 있습니다.

VPC의 클라이언트에 대해 프라이빗 S3 액세스를 구성하려면:

AWS VPC 콘솔에서 인바운드 PrivateLink 연결이 있는 VPC에 Amazon S3용 게이트웨이 엔드포인트를 만들고, 해당 엔드포인트를 라우팅 테이블과 연결합니다.
권장 사항. S3 트래픽이 게이트웨이 엔드포인트를 사용하는지 확인하려면 각 라우팅 테이블에 게이트웨이 엔드포인트(vpce-xxxxxxxx)를 통한 S3 접두사 목록(pl-xxxxxxxx) 경로가 있는지 확인하거나, VPC 흐름 로그, S3 액세스 로그 또는 CloudTrail에서 vpcEndpointId 필드를 확인합니다.

연결을 확인하려면 VPC의 리소스에서 다음 명령을 실행합니다:

# 레지스트리에 인증하려면
docker login registry.example.gitlab-dedicated.com

# 다운로드를 테스트하려면
docker pull registry.example.gitlab-dedicated.com/<group>/<project>/<image>:<tag>

온프레미스 네트워크에서 프라이빗 S3 액세스 구성#

온프레미스 클라이언트는 게이트웨이 엔드포인트를 사용할 수 없습니다. S3가 VPC에 개인 IP 주소를 갖도록 인터페이스 엔드포인트를 만들고, 온프레미스 DNS 서버가 S3 호스트 이름을 해당 주소로 확인할 수 있도록 Route 53 Resolver 인바운드 엔드포인트를 만드세요. 인터페이스 엔드포인트 주소는 VPC CIDR 범위 안에 있으므로, 트래픽은 새 경로나 BGP 변경 없이 기존 Direct Connect 또는 VPN 연결을 통해 해당 주소에 도달합니다.

GitLab이 사전 서명된 URL을 생성하므로 클라이언트는 인터페이스 엔드포인트의 엔드포인트별 DNS 이름을 사용할 수 없습니다. 프라이빗 DNS와 DNS 전달을 통해 표준 S3 호스트 이름이 대신 인터페이스 엔드포인트로 확인되도록 합니다.

필수 조건:

VPC에서 프라이빗 S3 액세스를 구성했습니다. 이 구성으로 AWS가 요구하는 게이트웨이 엔드포인트가 만들어집니다.
서로 다른 가용 영역에 있는 서브넷이 두 개 이상 있습니다.
온프레미스 네트워크의 CIDR 범위를 알고 있습니다.

온프레미스 클라이언트에 대해 프라이빗 S3 액세스를 구성하려면:

AWS VPC 콘솔에서 Amazon S3용 인터페이스 엔드포인트를 만듭니다.
서브넷에서 서로 다른 가용 영역에 있는 서브넷을 두 개 이상 선택합니다.
DNS 이름 활성화를 선택합니다.
인바운드 엔드포인트에만 프라이빗 DNS 활성화를 선택합니다.
보안 그룹에서 VPC CIDR 범위와 온프레미스 CIDR 범위로부터의 인바운드 TCP 443 포트를 허용합니다.
동일한 VPC에서 온프레미스 CIDR 범위로부터의 인바운드 TCP 및 UDP 53 포트를 허용하는 보안 그룹으로 Route 53 Resolver 인바운드 엔드포인트를 만듭니다.
Resolver 인바운드 엔드포인트에 할당된 IP 주소를 기록합니다. 온프레미스 DNS 서버는 S3 쿼리를 이 주소로 전달합니다.

S3 호스트 이름에 대한 DNS 전달 구성#

인터페이스 엔드포인트와 Resolver 인바운드 엔드포인트를 만든 후, S3 쿼리를 Resolver로 전달하도록 온프레미스 DNS 서버를 구성합니다.

필수 조건:

Resolver 인바운드 엔드포인트의 IP 주소를 알고 있습니다.
온프레미스 DNS 서버에서 조건부 전달자를 추가할 권한이 있습니다.

DNS 전달을 구성하려면:

온프레미스 DNS 서버에서 s3.<region>.amazonaws.com 영역에 대해 전달 전용 조건부 전달자를 추가합니다. 여기서 <region>은 GitLab Dedicated 인스턴스의 AWS 리전입니다. 장애 조치를 위한 보조 리전이 있다면 해당 리전의 S3 도메인에 대해서도 전달자를 추가하세요. 전달자를 Resolver 인바운드 엔드포인트의 IP 주소로 설정합니다. 전달은 영역 전체에 적용되므로 <bucket>.s3.<region>.amazonaws.com과 같은 버킷 호스트 이름에 대한 쿼리도 전달됩니다.

Windows Server DNS의 경우:
```
Add-DnsServerConditionalForwarderZone `
  -Name "s3.eu-central-1.amazonaws.com" `
  -MasterServers 10.0.1.90, 10.0.1.91
```
BIND의 경우 named.conf에서:
```
zone "s3.eu-central-1.amazonaws.com" {
    type forward;
    forward only;
    forwarders { 10.0.1.90; 10.0.1.91; };
};
```
Infoblox와 같은 다른 DNS 서버의 경우 동일한 이름과 동일한 대상으로 전달 전용 영역을 만듭니다.
확인이 되는지 검증하려면 온프레미스 클라이언트에서 컨테이너 레지스트리 FQDN에 대해 다음 명령을 실행합니다:
```
dig <container_registry_fqdn>
```
이 명령은 VPC CIDR 범위의 개인 IP 주소를 반환해야 합니다. 이 값을 찾으려면 컨테이너 레지스트리 FQDN 보기를 참조하세요.

연결을 확인하려면 온프레미스 클라이언트에서 다음 명령을 실행합니다:

# 레지스트리에 인증하려면
docker login registry.example.gitlab-dedicated.com

# 다운로드를 테스트하려면
docker pull registry.example.gitlab-dedicated.com/<group>/<project>/<image>:<tag>

S3 호스트 이름이 여전히 공개적으로 확인되면 전달자 영역이 인스턴스의 리전과 일치하는지, 그리고 DNS 서버가 Resolver 엔드포인트의 53 포트에 도달할 수 있는지 확인하세요. 개인적으로 확인되지만 다운로드가 시간 초과되면 인터페이스 엔드포인트 보안 그룹이 온프레미스 CIDR 범위로부터의 443 포트를 허용하는지 확인하세요.

AWS 연결 문제는 AWS 지원에 문의하세요.

아웃바운드 PrivateLink 연결#

아웃바운드 PrivateLink 연결을 사용하면 GitLab Dedicated 인스턴스와 호스팅 러너가 트래픽을 공개 인터넷에 노출하지 않고 VPC에서 실행 중인 서비스와 개인적으로 통신할 수 있습니다.

웹훅 전송, 프로젝트 및 저장소 가져오기 또는 미러링, 호스팅 러너에게 사용자 정의 시크릿 관리자, 아티팩트, 작업 이미지, 인프라로의 배포에 대한 액세스를 제공하는 데 아웃바운드 PrivateLink 연결을 사용합니다.

리전당 최대 10개의 아웃바운드 PrivateLink 연결을 만들 수 있습니다. 단일 연결 뒤에 10개 이상의 백엔드 서비스를 통합하려면 terraform-outbound-proxy Terraform 모듈을 사용하여 TLS 패스스루, HTTP 라우팅 및 SMTP 포워딩이 있는 고가용성 NGINX 역방향 프록시를 배포할 수 있습니다.

Switchboard의 아웃바운드 PrivateLink 연결은 서비스 연결(service connection)을 사용하여 연결성을 관리합니다. 서비스 연결은 DNS 별칭을 AWS 계정의 VPC 엔드포인트 서비스에 연결합니다. 각 서비스 연결은 리전마다 하나씩(기본 및 보조) 최대 두 개의 VPC 엔드포인트를 가질 수 있습니다. 서비스 연결을 만들 때 DNS가 확인되는 방식을 선택합니다:

GitLab 관리 DNS: GitLab이 VPC 엔드포인트와 함께 별칭에 대한 프라이빗 호스팅 영역(PHZ)과 DNS 레코드를 만듭니다.
Private DNS: AWS가 엔드포인트 서비스의 프라이빗 DNS 이름을 사용하여 DNS 확인을 자동으로 처리합니다. 이 경우 GitLab은 DNS 레코드를 만들지 않습니다.

VPC 엔드포인트가 필요하지 않은 별칭의 경우 대신 사용자 정의 DNS 레코드를 만들 수 있습니다.

서비스 연결 만들기#

GitLab Dedicated 인스턴스에서 AWS PrivateLink를 통해 VPC의 서비스로 아웃바운드 트래픽을 라우팅하도록 서비스 연결을 만듭니다.

리전 장애 조치(failover) 중에도 이 연결을 사용할 수 있게 유지하려면 보조 리전 엔드포인트를 구성합니다. 이를 구성하지 않으면 기본 리전을 사용할 수 없게 될 때 아웃바운드 연결을 사용할 수 없습니다. 서비스 연결에 한 리전에만 VPC 엔드포인트가 있는 경우 Switchboard가 경고를 표시합니다.

필수 조건:

서비스 이름이 기록된, 내부 서비스에 대해 만든 엔드포인트 서비스. 자세한 내용은 엔드포인트 서비스 만들기를 참조하세요.
인스턴스가 배포된 가용 영역에 구성된 네트워크 로드 밸런서(NLB). 구성된 AZ를 사용하거나(Switchboard Overview 페이지에 표시됨) 리전의 모든 AZ에서 NLB를 활성화합니다.

서비스 연결을 만들려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장한 다음 Outbound PrivateLink connections를 선택합니다.
Set up endpoint service in AWS를 확장하고 Outbound PrivateLink IAM principal에서 ARN을 복사합니다.
AWS 엔드포인트 서비스에서 Allowed Principals 목록에 ARN을 추가합니다. 자세한 내용은 권한 관리를 참조하세요.
Service connections 탭을 선택합니다.
Create service connection을 선택합니다.
필드를 완성합니다:
- Alias: GitLab Dedicated 인스턴스가 서비스에 도달하는 데 사용하는 DNS 이름을 입력합니다. 예를 들어 my-service.example.com.
- 선택 사항. Description: 이 연결에 대한 설명을 입력합니다.
기본 리전에서 필드를 완성합니다:
- VPC endpoint: New VPC endpoint를 선택하고 AWS 계정의 VPC 엔드포인트 서비스 이름을 입력하거나(예: com.amazonaws.vpce.us-east-1.vpce-svc-0a123bcd4e5f678gh), Existing VPC endpoint를 선택하고 드롭다운 목록에서 엔드포인트를 선택합니다.
- 선택 사항. Description: 이 리전의 엔드포인트에 대한 설명을 입력합니다.
- DNS: GitLab이 프라이빗 호스팅 영역 레코드를 유지하도록 하려면 GitLab-managed DNS를 선택하고, AWS의 VPC 엔드포인트 서비스에 구성된 프라이빗 DNS 이름을 사용하려면 Private DNS를 선택합니다.
보조 리전에 대해 다음 중 하나를 수행합니다:
- VPC 엔드포인트를 추가하려면 기본 리전과 동일한 필드를 완성합니다.
- 보조 리전을 건너뛰려면 섹션 오른쪽 상단에서 Remove를 선택합니다.
Save를 선택합니다.

GitLab은 필요한 VPC 엔드포인트와 DNS 레코드를 만들도록 인스턴스를 구성합니다(Private DNS가 선택된 경우는 예외이며, 이 경우 AWS가 DNS 확인을 관리합니다). 설정 후 GitLab은 일치하는 아웃바운드 연결을 PrivateLink를 통해 VPC로 라우팅합니다.

사용자 정의 DNS 레코드 만들기#

VPC 엔드포인트를 가리키지 않는 DNS 별칭에 사용자 정의 DNS 레코드를 사용합니다. 예를 들어 GitLab Dedicated 인스턴스가 개인 도메인 이름을 공개적으로 액세스 가능하거나 내부적으로 라우팅되는 서비스로 확인해야 할 때 사용자 정의 DNS 레코드를 사용합니다.

기본적으로 별칭은 첫 번째 점에서 레코드 이름과 프라이빗 호스팅 영역 이름으로 분할됩니다. 예를 들어 service.example.com은 레코드 이름 service와 영역 example.com으로 분할됩니다. 이 분할로 인해 도메인 섀도잉이 발생하거나 기존 서비스 연결 별칭 또는 사용자 정의 도메인과 충돌하는 경우 고급 옵션을 사용하여 분할을 사용자 정의합니다.

프라이빗 호스팅 영역(PHZ)은 Amazon Route 53이 GitLab Dedicated VPC 내의 도메인 및 하위 도메인에 대한 DNS 쿼리에 응답하는 방법에 대한 정보를 담고 있는 컨테이너입니다. 자세한 내용은 프라이빗 호스팅 영역을 참조하세요.

사용자 정의 DNS 레코드에 대한 변경, 또는 GitLab 관리 DNS(프라이빗 호스팅 영역)를 사용할 때의 서비스 연결에 대한 변경은 이러한 레코드를 사용하는 서비스를 최대 5분 동안 중단시킬 수 있습니다.

사용자 정의 DNS 레코드를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장한 다음 Outbound PrivateLink connections를 선택합니다.
Custom DNS records 탭을 선택합니다.
Create DNS record를 선택합니다.
필드를 완성합니다:
- Alias: GitLab Dedicated 인스턴스가 서비스에 도달하는 데 사용하는 DNS 이름을 입력합니다. 예를 들어 my-internal-service.example.com.
- 선택 사항. Description: 이 레코드에 대한 설명을 입력합니다.
- 선택 사항. 레코드 이름이 레코드 이름과 프라이빗 호스팅 영역으로 분할되는 방식을 제어하려면 **Customize DNS record and zone split (advanced)**를 선택합니다. 선택하면 Record name 텍스트 박스가 읽기 전용이 되며 입력한 Record name 및 Private hosted zone name 값으로 자동으로 구성됩니다.
각 리전에서 별칭이 확인되는 Target domain name을 입력합니다. 장애 조치를 지원하려면 기본 및 보조 리전 모두에 대해 대상 도메인 이름을 입력합니다.
Save를 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

지원 요청으로 아웃바운드 PrivateLink 연결 구성#

Switchboard를 사용하여 아웃바운드 PrivateLink 연결을 구성할 수 없는 경우:

지원 티켓을 열고 다음을 제공합니다:
- VPC 엔드포인트 서비스 이름.
- 사용하려는 DNS 별칭(해당하는 경우).
- 엔드포인트 서비스에서 Private DNS가 활성화되었는지 여부.
GitLab에서 제공한 IAM 주체의 ARN을 복사하여 엔드포인트 서비스의 Allowed Principals 목록에 추가합니다. 자세한 내용은 권한 관리를 참조하세요.

아웃바운드 PrivateLink 연결 삭제#

서비스 연결 또는 VPC 엔드포인트를 독립적으로 삭제할 수 있습니다. 각각 Switchboard에 자체 탭이 있습니다: Service connections 및 VPC endpoints.

서비스 연결을 삭제하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장합니다.
Service connections 탭을 선택합니다.
삭제하려는 연결로 이동하여 Delete([remove])를 선택합니다.
Delete를 선택합니다.

VPC 엔드포인트를 삭제하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장합니다.
VPC endpoints 탭을 선택합니다.
삭제하려는 엔드포인트로 이동하여 Delete([remove])를 선택합니다.
Delete를 선택합니다.

IPv6 연결#

IPv6 연결을 사용하면 클라이언트가 IPv4 외에도 IPv6를 통해 GitLab Dedicated 인스턴스에 도달할 수 있습니다. Cloudflare가 이 트래픽을 수신하고 인스턴스의 기존 IPv4 인프라로 요청을 전달하기 전에 IPv4로 변환합니다. GitLab Dedicated 플랫폼 서비스 간의 내부 통신은 IPv4 전용으로 유지됩니다.

인스턴스에 IPv6를 켜면:

인스턴스가 듀얼 스택 모드로 작동합니다. IPv4 액세스는 IPv6와 함께 계속 작동합니다.
GitLab 웹 인터페이스를 IPv6를 통해 사용할 수 있게 됩니다.
clone, push, pull과 같은 SSH Git 작업을 IPv6를 통해 사용할 수 있게 됩니다.

필수 조건:

인스턴스가 Cloudflare WAF를 통해 프록시되어야 합니다. 인스턴스에 Cloudflare WAF가 켜져 있는지 확실하지 않은 경우 고객 성공 관리자에게 문의하세요.
인스턴스가 GitLab 18.11.4 이상을 실행해야 합니다.

Switchboard는 이 구성을 지원하지 않습니다. IPv6 연결을 켜려면 지원 티켓을 열고 인스턴스에 대한 HTTPS 및 SSH 액세스에 IPv6 연결을 켜려는 것을 확인합니다.

IPv6를 켠 후 인스턴스의 공개 IP 주소가 IPv4와 IPv6 모두에 대해 변경됩니다. 방화벽, DNS 레코드 또는 모니터링 시스템에서 이러한 주소를 허용 목록에 추가한 경우 변경 사항이 적용된 후 해당 구성을 업데이트합니다. IPv6를 끄면 IP 주소가 다시 변경됩니다.

구성은 다음 유지보수 창 동안 적용됩니다.

IP 허용 목록#

IP 허용 목록을 사용하여 인스턴스에 액세스할 수 있는 IP 주소를 제어합니다. IP 허용 목록을 활성화하면 허용 목록에 없는 IP 주소가 차단되고 인스턴스에 액세스하려고 할 때 HTTP 403 Forbidden 응답을 받습니다.

Switchboard를 사용하여 IP 허용 목록을 구성 및 관리하거나 Switchboard를 사용할 수 없는 경우 지원 요청을 제출합니다.

Switchboard로 허용 목록에 IP 주소 추가#

허용 목록에 IP 주소를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
IP allowlist를 확장하고 IP allowlist를 선택하여 IP 허용 목록 페이지로 이동합니다.
IP 허용 목록을 활성화하려면 수직 줄임표(⋮)를 선택하고 Enabled를 선택합니다.
다음 중 하나를 수행합니다:
- 단일 IP 주소를 추가하려면:
1. Add IP address를 선택합니다.
2. IP address 텍스트 박스에 다음 중 하나를 입력합니다:
  - 단일 IPv4 또는 IPv6 주소(예: 192.168.1.1 또는 2001:db8::1).
  - CIDR 표기법의 IPv4 또는 IPv6 주소 범위(예: 192.168.1.0/24 또는 2001:db8::/32).
3. Description 텍스트 박스에 설명을 입력합니다.
4. Add를 선택합니다.
- 여러 IP 주소를 가져오려면:
1. Import를 선택합니다.
2. CSV 파일을 업로드하거나 IP 주소 목록을 붙여넣습니다.
3. Continue를 선택합니다.
4. 유효하지 않거나 중복된 항목을 수정한 후 Continue를 선택합니다.
5. 변경 사항을 검토하고 Import를 선택합니다.
페이지 상단에서 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

Switchboard로 허용 목록에서 IP 주소 삭제#

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
IP allowlist를 확장하고 IP allowlist를 선택하여 IP 허용 목록 페이지로 이동합니다.
다음 중 하나를 수행합니다:
- 단일 IP 주소를 삭제하려면:
1. 제거하려는 IP 주소 옆에서 휴지통 아이콘([remove])을 선택합니다.
2. Delete IP address를 선택합니다.
- 여러 IP 주소를 삭제하려면:
1. 삭제하려는 IP 주소의 체크박스를 선택합니다.
2. 현재 페이지의 모든 IP 주소를 선택하려면 헤더 행의 체크박스를 선택합니다.
3. IP 주소 테이블 위에서 Delete를 선택합니다.
4. Delete를 선택하여 확인합니다.
페이지 상단에서 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

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

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

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

GitLab을 OpenID Connect ID 공급자로 사용하려면 OpenID Connect 확인 엔드포인트에 인터넷 액세스가 필요합니다.

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

지원 티켓에서 OpenID Connect 엔드포인트에 대한 액세스를 허용하도록 요청합니다.

구성은 다음 유지보수 창 동안 적용됩니다.

IP 허용 목록에 대해 SCIM 프로비저닝 활성화#

외부 ID 공급자와 함께 SCIM을 사용하여 사용자를 자동으로 프로비저닝하고 관리할 수 있습니다. SCIM을 사용하려면 ID 공급자가 인스턴스 SCIM API 엔드포인트에 액세스할 수 있어야 합니다. 기본적으로 IP 허용 목록은 이러한 엔드포인트에 대한 통신을 차단합니다.

IP 허용 목록을 유지하면서 SCIM을 활성화하려면:

지원 티켓에서 SCIM 엔드포인트를 인터넷에 활성화하도록 요청합니다.

구성은 다음 유지보수 창 동안 적용됩니다.

NAT 게이트웨이 IP 주소#

NAT 게이트웨이 IP 주소는 외부 서비스에 대한 인스턴스의 아웃바운드 연결을 식별합니다. 이 IP는 일반적으로 일관성을 유지하지만 리전 장애 조치(failover)가 발생하면 인스턴스가 새 인프라로 재구축되므로 변경될 수 있습니다.

이 IP 주소를 사용하여 웹훅 수신자를 구성하고 인스턴스에서의 연결을 수락하도록 외부 서비스에 대한 허용 목록을 설정합니다.

NAT 게이트웨이 IP 주소를 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Resource access를 확장합니다.
NAT gateways에서 Copy to clipboard([copy-to-clipboard])를 선택합니다.

AWS PrivateLink 연결 트러블슈팅#

AWS PrivateLink 연결 작업 시 다음 문제가 발생할 수 있습니다.

오류: `Service name could not be verified`#

인바운드 PrivateLink 연결을 위한 VPC 엔드포인트를 만들 때 Service name could not be verified라는 오류가 발생할 수 있습니다.

이 문제는 지원 티켓에 제공된 사용자 정의 IAM 역할이 AWS 계정에 필요한 권한 또는 신뢰 정책이 구성되지 않은 경우에 발생합니다.

이 문제를 해결하려면:

지원 티켓에서 GitLab에 제공된 사용자 정의 IAM 역할을 가정할 수 있는지 확인합니다.

사용자 정의 역할에 이를 가정할 수 있는 신뢰 정책이 있는지 확인합니다. 예를 들어:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::CONSUMER_ACCOUNT_ID:user/user-name"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

사용자 정의 역할에 VPC 엔드포인트 및 EC2 작업을 허용하는 권한 정책이 있는지 확인합니다. 예를 들어:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": "vpce:*",
         "Resource": "*"
      },
      {
         "Sid": "Statement1",
         "Effect": "Allow",
         "Action": [
               "ec2:CreateVpcEndpoint",
               "ec2:DescribeVpcEndpointServices",
               "ec2:DescribeVpcEndpoints"
         ],
         "Resource": "*"
      }
   ]
}

사용자 정의 역할을 사용하여 AWS 콘솔 또는 CLI에서 VPC 엔드포인트 만들기를 재시도합니다.

아웃바운드 PrivateLink 연결 실패#

아웃바운드 PrivateLink 연결이 작동하지 않는 경우 다음을 확인합니다:

네트워크 로드 밸런서(NLB)에서 교차 영역 로드 밸런싱이 켜져 있는지 확인합니다.
적절한 보안 그룹의 인바운드 규칙 섹션이 올바른 IP 범위에서의 트래픽을 허용하는지 확인합니다.
인바운드 트래픽이 엔드포인트 서비스의 올바른 포트에 매핑되어 있는지 확인합니다.
Switchboard에서 Outbound PrivateLink connections를 확장하고 세부 정보가 예상대로 표시되는지 확인합니다.
웹훅과 통합에서 로컬 네트워크에 대한 요청을 허용했는지 확인합니다.

GitLab Dedicated 네트워크 액세스 및 보안

GitLab v19.3

Tier: Ultimate
Offering: GitLab Dedicated for Government

원문 보기

번역일: 2026-08-21

요약

사용자 정의 도메인#

기본 your-tenant.gitlab-dedicated.com 대신 GitLab Dedicated 인스턴스에 액세스하기 위한 사용자 정의 도메인을 구성할 수 있습니다.

사용자 정의 도메인을 추가할 때:

도메인이 인스턴스에 액세스하는 데 사용되는 외부 URL에 포함됩니다.
기본 tenant.gitlab-dedicated.com 도메인을 사용하여 인스턴스에 연결하는 것은 더 이상 사용할 수 없습니다.

CNAME 레코드가 DNS를 통해 공개적으로 확인 가능해야 합니다.
90일마다 자동 인증서 갱신을 위한 동일한 공개 확인 프로세스.

GitLab Dedicated는 두 가지 구성 방법을 통해 사용자 정의 도메인을 지원합니다:

표준 구성: CNAME 레코드와 Let's Encrypt 인증서를 사용합니다. 자체 DNS 레코드를 구성하고 지원을 통해 도메인 활성화를 요청합니다.
Cloudflare 보안 구성: NS 레코드와 Let's Encrypt 인증서를 사용합니다. GitLab이 DNS 구성 세부 정보를 제공하고 지원과 협력하여 구현합니다.

어떤 구성 방법이 인스턴스에 적용되는지 결정하려면 고객 성공 관리자에게 문의하세요.

사용자 정의 도메인 세부 정보 보기#

Custom domains 섹션은 GitLab Dedicated 인스턴스의 활성 도메인 구성을 표시합니다:

GitLab instance domain: GitLab 인스턴스의 사용자 정의 도메인.
Registry domain: 컨테이너 레지스트리의 사용자 정의 도메인.
KAS domain: Kubernetes(KAS)용 GitLab 에이전트 서버의 사용자 정의 도메인.

다음을 위해 이 정보를 사용합니다:

현재 사용자 정의 도메인 구성 확인.
외부 통합을 위한 도메인 참조.
DNS 관리를 위한 구성 세부 정보 복사.

사용자 정의 도메인 세부 정보를 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Custom domains를 확장합니다.

DNSSEC 세부 정보#

추가 세부 정보는 다음을 포함합니다:

Cloudflare 네임서버: Cloudflare 관리 도메인에 대한 DNS 네임서버.
키 태그: DNSSEC 키의 숫자 식별자.
알고리즘: 사용된 암호화 알고리즘(일반적으로 SHA-256이 있는 ECDSA P-256의 경우 13).
다이제스트 유형: 사용된 해시 알고리즘(일반적으로 SHA-256의 경우 2).
다이제스트: 공개 키의 암호화 해시.

DNS 공급자와의 DNS 위임 및 DNSSEC 유효성 검사를 구성하는 데 이러한 값을 사용합니다.

표준 구성#

Note

SSL 인증서 관리를 위해 사용자 정의 도메인은 개인 네트워크를 통해 인스턴스에 액세스하더라도 공개 인터넷에서 액세스할 수 있어야 합니다.

DNS 레코드 구성#

필수 조건:

도메인 호스트의 DNS 설정에 대한 액세스.

DNS 레코드를 구성하려면:

도메인 호스트의 웹사이트에 로그인합니다.
DNS 설정으로 이동합니다.
사용자 정의 도메인을 GitLab Dedicated 인스턴스로 가리키는 CNAME 레코드를 추가합니다. 예를 들어:
```
gitlab.my-company.com.  CNAME  my-tenant.gitlab-dedicated.com
```
선택 사항. 도메인에 기존 CAA 레코드가 있는 경우 Let's Encrypt를 유효한 인증 기관으로 포함하도록 업데이트합니다. 예를 들어:
```
gitlab.my-company.com.  IN  CAA 0 issue "pki.goog"
gitlab.my-company.com.  IN  CAA 0 issue "letsencrypt.org"
```
CAA 레코드는 도메인에 대한 인증서를 발급할 수 있는 인증 기관을 정의합니다.
변경 사항을 저장하고 DNS 변경 사항이 적용될 때까지 기다립니다.

사용자 정의 도메인을 사용하는 동안 DNS 레코드를 유지합니다.

사용자 정의 도메인 활성화#

필수 조건:

DNS 레코드를 구성했습니다.

사용자 정의 도메인을 활성화하려면:

지원 티켓을 제출합니다.
지원 티켓에서 다음을 지정합니다:
- 사용자 정의 도메인 이름. 예를 들어 gitlab.company.com.
- 컨테이너 레지스트리 및 Kubernetes용 GitLab 에이전트 서버에 사용자 정의 도메인이 필요한 경우 사용하려는 도메인 이름을 포함합니다. 예를 들어 registry.company.com 및 kas.company.com.

Cloudflare 보안 구성#

Note

이 방법은 고객 성공 관리자와의 협력이 필요합니다. 구성은 인스턴스의 유지보수 기간 동안 적용됩니다.

사용자 정의 도메인 요청#

사용자 정의 도메인을 요청하려면:

지원 티켓을 제출합니다.
지원 티켓에서 다음을 지정합니다:
- 사용자 정의 도메인 이름. 예를 들어 gitlab.company.com.
- 컨테이너 레지스트리 및 Kubernetes용 GitLab 에이전트 서버에 사용자 정의 도메인이 필요한 경우 사용하려는 도메인 이름을 포함합니다. 예를 들어 registry.company.com 및 kas.company.com.
- 규정 준수 요구 사항. 예를 들어 FedRAMP.

GitLab은 Cloudflare에서 도메인을 구성하고 다음을 제공합니다:

name1.ns.cloudflare.com 및 name2.ns.cloudflare.com과 같은 두 개의 Cloudflare 네임서버.
DNSSEC 파라미터(FedRAMP 고객 전용), 다음을 포함:
- 키 태그: 숫자 식별자 (GitLab에서 제공)
- 알고리즘: 일반적으로 13(ECDSA P-256 with SHA-256) 또는 8(RSA/SHA-256)
- 다이제스트 유형: 일반적으로 2(SHA-256)
- 다이제스트: 공개 키의 암호화 해시 (GitLab에서 제공)

DNS 레코드 구성#

DNS 공급자에서 서브도메인을 Cloudflare에 위임하도록 NS 레코드를 구성합니다.

필수 조건:

도메인 호스트의 DNS 설정에 대한 액세스.
GitLab이 네임서버와 DNSSEC 파라미터를 제공했습니다(해당하는 경우).

DNS 레코드를 구성하려면:

도메인 호스트의 웹사이트에 로그인합니다.
DNS 설정으로 이동합니다.

GitLab에서 제공한 네임서버를 사용하여 NS 레코드를 만듭니다. 예를 들어:

gitlab.company.com.     NS    name1.ns.cloudflare.com.
gitlab.company.com.     NS    name2.ns.cloudflare.com.

동일한 서브도메인에 대해 충돌하는 A, AAAA 또는 CNAME 레코드를 제거합니다.

FedRAMP 고객 전용. GitLab에서 제공한 값을 사용하여 DS 레코드를 추가합니다:

gitlab.company.com.     DS    [Key Tag] [Algorithm] [Digest Type] [Digest]

예를 들어:

gitlab.company.com.     DS    12345 13 2 A1B2C3D4E5F6...

변경 사항을 저장합니다. DNS 변경 사항은 적용되는 데 최대 48시간이 걸릴 수 있습니다.

구성을 확인합니다:

# 네임서버 위임 확인
dig +short NS gitlab.company.com

# DNS 확인 확인
dig gitlab.company.com

# DNSSEC 확인 (구성된 경우)
dig +dnssec gitlab.company.com

DNS 구성이 완료되었음을 지원 티켓을 통해 GitLab에 알립니다.

GitLab은 다음을 수행합니다:

DNS 위임을 확인합니다.
SSL/TLS 인증서를 구성합니다.
사용자 정의 도메인이 활성화된 시기를 확인합니다.

컨테이너 레지스트리 네트워크 액세스#

컨테이너 레지스트리 FQDN(완전 정규화된 도메인 이름)은 인스턴스의 컨테이너 레지스트리 데이터를 저장하는 S3 버킷을 식별합니다.

컨테이너 레지스트리 FQDN 보기#

컨테이너 레지스트리 FQDN을 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Resource access를 확장합니다.
Container registry에서 Copy to clipboard([copy-to-clipboard])를 선택합니다.

외부 서비스에 대한 사용자 정의 인증 기관#

외부 서비스에서 개인 또는 내부 인증 기관의 인증서를 사용하는 경우 해당 인증 기관을 GitLab Dedicated 인스턴스에 추가해야 합니다.

다음의 경우 사용자 정의 인증 기관이 필요할 수 있습니다:

내부 웹훅 엔드포인트에 연결.
개인 컨테이너 레지스트리에서 이미지 가져오기.
기업 공개 키 인프라 뒤의 온프레미스 서비스와 통합.

사용자 정의 인증서 추가#

인증서 체인 블록(단일 텍스트 블록의 여러 인증서)은 지원되지 않습니다. 체인에 여러 인증서가 있는 경우 각 인증서를 별도로 추가합니다.

사용자 정의 인증서를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Custom certificate authorities를 확장합니다.
+ Add Certificate를 선택합니다.
텍스트 박스에 단일 인증서를 붙여넣습니다. -----BEGIN CERTIFICATE----- 및 -----END CERTIFICATE----- 줄을 포함합니다.
Save를 선택합니다.
체인의 각 추가 인증서에 대해 4-6단계를 반복합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

Switchboard를 사용하여 사용자 정의 인증서를 추가할 수 없는 경우 지원 티켓을 열고 각 사용자 정의 인증서를 별도의 파일로 첨부합니다.

AWS PrivateLink 연결#

GitLab Dedicated는 두 가지 유형의 PrivateLink 연결을 지원합니다:

인바운드 PrivateLink 연결: VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결됩니다. 공개 인터넷을 통해 인스턴스에 액세스할 수 없도록 제한하려는 경우 사용합니다.
아웃바운드 PrivateLink 연결: GitLab Dedicated 인스턴스와 호스팅 러너가 VPC에서 실행 중인 서비스에 개인적으로 연결됩니다. 웹훅, 프로젝트 미러링, 시크릿 관리자, 또는 인프라로의 배포에 사용합니다.

PrivateLink 연결은 GitLab Dedicated 인스턴스와 동일한 AWS 리전에 있어야 하며, 기본 및 보조 AWS 리전에서만 엔드포인트 서비스를 만들 수 있습니다.

AWS PrivateLink에 대한 자세한 내용은 AWS PrivateLink란 무엇인가?를 참조하세요.

인바운드 PrivateLink 연결#

인바운드 PrivateLink 연결을 사용하면 VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결할 수 있습니다.

각 엔드포인트 서비스는 온보딩 중에 선택되거나 무작위로 선택되는 두 개의 가용 영역에서 사용 가능합니다.

인바운드 PrivateLink 연결 만들기#

VPC의 사용자 및 애플리케이션이 GitLab Dedicated 인스턴스에 개인적으로 연결할 수 있도록 인바운드 PrivateLink 연결을 만듭니다.

필수 조건:

구성하려는 각 리전에 VPC가 있어야 합니다.
GitLab에서 제공한 엔드포인트 서비스를 검색하고, 인터페이스 VPC 엔드포인트를 만들고, private DNS가 활성화된 경우 Route 53 프라이빗 호스팅 영역과 연결할 권한이 있는 IAM 주체.
역할 경로가 없는, 역할 이름만 있는 IAM 주체.
- 유효: arn:aws:iam::AWS_ACCOUNT_ID:role/RoleName
- 유효하지 않음: arn:aws:iam::AWS_ACCOUNT_ID:role/somepath/AnotherRoleName

인바운드 PrivateLink 연결을 만들려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Inbound PrivateLink connections를 확장합니다.
Add endpoint service를 선택합니다.
리전을 선택합니다.
IAM principals에서 엔드포인트 서비스에 대한 연결을 시작할 수 있는 AWS 사용자 또는 역할을 추가합니다. IAM 주체는 IAM 역할 주체 또는 IAM 사용자 주체여야 합니다.

AWS 계정에서 VPC 엔드포인트를 만드는 역할 또는 사용자에게 다음 권한이 있는 정책을 연결합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GitLabDedicatedInboundPrivateLink",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcEndpoint",
        "ec2:DescribeVpcEndpointServices",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeVpcs",
        "route53:AssociateVPCWithHostedZone"
      ],
      "Resource": "*"
    }
  ]
}

권장. 보조 리전을 구성하려면 Regions에서 Secondary region을 선택합니다. 이렇게 하면 지정된 IAM 주체로 두 리전 모두에 엔드포인트 서비스가 생성됩니다.
Save를 선택합니다. GitLab이 엔드포인트 서비스를 만들고 서비스 엔드포인트 이름이 Configuration 페이지에서 사용 가능해집니다.

그런 다음, 구성한 각 리전에 대해 AWS 설정을 완료합니다:

AWS 계정에서 VPC에 엔드포인트 인터페이스를 만듭니다.
다음 설정으로 엔드포인트 인터페이스를 구성합니다:
- Service endpoint name: Switchboard의 Configuration 페이지에서 해당 리전의 이름을 사용합니다.
- Private DNS names enabled: Yes를 선택합니다.
- Subnets: 일치하는 모든 서브넷을 선택합니다.
온보딩 중에 제공된 인스턴스 URL을 사용하여 VPC에서 GitLab Dedicated 인스턴스에 연결합니다.

KAS 및 레지스트리를 위한 DNS 구성#

개인 네트워크를 통해 KAS(Kubernetes용 GitLab 에이전트) 및 컨테이너 레지스트리에 액세스하려면 VPC에 추가 DNS 구성을 만듭니다.

필수 조건:

인바운드 PrivateLink 연결을 구성했습니다.
AWS 계정에서 Route 53 프라이빗 호스팅 영역을 만들 권한이 있습니다.

KAS 및 레지스트리를 위한 DNS를 구성하려면:

AWS 콘솔에서 gitlab-dedicated.com에 대한 프라이빗 호스팅 영역을 만들고 인바운드 PrivateLink 연결이 있는 VPC와 연결합니다.
프라이빗 호스팅 영역을 만든 후 다음 DNS 레코드를 추가합니다(example을 인스턴스 이름으로 교체):
1. GitLab Dedicated 인스턴스에 대한 A 레코드를 만듭니다:
  - 전체 인스턴스 도메인(예: example.gitlab-dedicated.com)을 VPC 엔드포인트로 Alias로 확인하도록 구성합니다.
  - 가용 영역 참조가 없는 VPC 엔드포인트를 선택합니다.
2. KAS와 레지스트리 모두가 GitLab Dedicated 인스턴스 도메인(example.gitlab-dedicated.com)으로 확인되도록 CNAME 레코드를 만듭니다:
  - kas.example.gitlab-dedicated.com
  - registry.example.gitlab-dedicated.com
연결을 확인하려면 VPC의 리소스에서 다음 명령을 실행합니다:
```
nslookup kas.example.gitlab-dedicated.com
nslookup registry.example.gitlab-dedicated.com
nslookup example.gitlab-dedicated.com
```
모든 명령이 VPC 내의 개인 IP 주소로 확인되어야 합니다.

이 구성은 특정 IP 주소 대신 VPC 엔드포인트 인터페이스를 사용하므로 IP 주소가 변경되어도 안정적입니다.

GitLab Pages를 위한 DNS 구성#

개인 네트워크를 통해 GitLab Pages에 액세스하려면 VPC에 추가 DNS 구성을 만듭니다.

GitLab Pages를 위한 DNS를 구성하려면:

AWS 콘솔에서 <tenant_name>.gitlab-dedicated.site에 대한 프라이빗 호스팅 영역을 만들고 인바운드 PrivateLink 연결이 있는 VPC와 연결합니다.
프라이빗 호스팅 영역을 만든 후 다음 DNS 레코드를 추가합니다:
1. VPC 엔드포인트에 대한 Apex A Alias 레코드를 만듭니다.
2. <tenant_name>.gitlab-dedicated.site를 가리키는 *.<tenant_name>.gitlab-dedicated.site에 대한 와일드카드 CNAME을 만듭니다.

객체 스토리지를 위한 프라이빗 S3 액세스#

필요한 엔드포인트는 클라이언트가 실행되는 위치에 따라 달라집니다:

클라이언트 위치	만들어야 하는 엔드포인트
VPC 내부(예: EC2 또는 EKS 러너)	S3 게이트웨이 엔드포인트
온프레미스(Direct Connect 또는 Site-to-Site VPN을 통해)	S3 인터페이스 엔드포인트 및 Route 53 Resolver 인바운드 엔드포인트, 그리고 동일한 VPC의 S3 게이트웨이 엔드포인트

VPC에서 프라이빗 S3 액세스 구성#

필수 조건:

인바운드 PrivateLink 연결을 구성했습니다.
AWS 계정에서 VPC 엔드포인트를 만들고 라우팅 테이블을 수정할 권한이 있습니다.

VPC의 클라이언트에 대해 프라이빗 S3 액세스를 구성하려면:

AWS VPC 콘솔에서 인바운드 PrivateLink 연결이 있는 VPC에 Amazon S3용 게이트웨이 엔드포인트를 만들고, 해당 엔드포인트를 라우팅 테이블과 연결합니다.
권장 사항. S3 트래픽이 게이트웨이 엔드포인트를 사용하는지 확인하려면 각 라우팅 테이블에 게이트웨이 엔드포인트(vpce-xxxxxxxx)를 통한 S3 접두사 목록(pl-xxxxxxxx) 경로가 있는지 확인하거나, VPC 흐름 로그, S3 액세스 로그 또는 CloudTrail에서 vpcEndpointId 필드를 확인합니다.

연결을 확인하려면 VPC의 리소스에서 다음 명령을 실행합니다:

# 레지스트리에 인증하려면
docker login registry.example.gitlab-dedicated.com

# 다운로드를 테스트하려면
docker pull registry.example.gitlab-dedicated.com/<group>/<project>/<image>:<tag>

온프레미스 네트워크에서 프라이빗 S3 액세스 구성#

필수 조건:

VPC에서 프라이빗 S3 액세스를 구성했습니다. 이 구성으로 AWS가 요구하는 게이트웨이 엔드포인트가 만들어집니다.
서로 다른 가용 영역에 있는 서브넷이 두 개 이상 있습니다.
온프레미스 네트워크의 CIDR 범위를 알고 있습니다.

온프레미스 클라이언트에 대해 프라이빗 S3 액세스를 구성하려면:

AWS VPC 콘솔에서 Amazon S3용 인터페이스 엔드포인트를 만듭니다.
서브넷에서 서로 다른 가용 영역에 있는 서브넷을 두 개 이상 선택합니다.
DNS 이름 활성화를 선택합니다.
인바운드 엔드포인트에만 프라이빗 DNS 활성화를 선택합니다.
보안 그룹에서 VPC CIDR 범위와 온프레미스 CIDR 범위로부터의 인바운드 TCP 443 포트를 허용합니다.
동일한 VPC에서 온프레미스 CIDR 범위로부터의 인바운드 TCP 및 UDP 53 포트를 허용하는 보안 그룹으로 Route 53 Resolver 인바운드 엔드포인트를 만듭니다.
Resolver 인바운드 엔드포인트에 할당된 IP 주소를 기록합니다. 온프레미스 DNS 서버는 S3 쿼리를 이 주소로 전달합니다.

S3 호스트 이름에 대한 DNS 전달 구성#

인터페이스 엔드포인트와 Resolver 인바운드 엔드포인트를 만든 후, S3 쿼리를 Resolver로 전달하도록 온프레미스 DNS 서버를 구성합니다.

필수 조건:

Resolver 인바운드 엔드포인트의 IP 주소를 알고 있습니다.
온프레미스 DNS 서버에서 조건부 전달자를 추가할 권한이 있습니다.

DNS 전달을 구성하려면:

온프레미스 DNS 서버에서 s3.<region>.amazonaws.com 영역에 대해 전달 전용 조건부 전달자를 추가합니다. 여기서 <region>은 GitLab Dedicated 인스턴스의 AWS 리전입니다. 장애 조치를 위한 보조 리전이 있다면 해당 리전의 S3 도메인에 대해서도 전달자를 추가하세요. 전달자를 Resolver 인바운드 엔드포인트의 IP 주소로 설정합니다. 전달은 영역 전체에 적용되므로 <bucket>.s3.<region>.amazonaws.com과 같은 버킷 호스트 이름에 대한 쿼리도 전달됩니다.

Windows Server DNS의 경우:
```
Add-DnsServerConditionalForwarderZone `
  -Name "s3.eu-central-1.amazonaws.com" `
  -MasterServers 10.0.1.90, 10.0.1.91
```
BIND의 경우 named.conf에서:
```
zone "s3.eu-central-1.amazonaws.com" {
    type forward;
    forward only;
    forwarders { 10.0.1.90; 10.0.1.91; };
};
```
Infoblox와 같은 다른 DNS 서버의 경우 동일한 이름과 동일한 대상으로 전달 전용 영역을 만듭니다.
확인이 되는지 검증하려면 온프레미스 클라이언트에서 컨테이너 레지스트리 FQDN에 대해 다음 명령을 실행합니다:
```
dig <container_registry_fqdn>
```
이 명령은 VPC CIDR 범위의 개인 IP 주소를 반환해야 합니다. 이 값을 찾으려면 컨테이너 레지스트리 FQDN 보기를 참조하세요.

연결을 확인하려면 온프레미스 클라이언트에서 다음 명령을 실행합니다:

# 레지스트리에 인증하려면
docker login registry.example.gitlab-dedicated.com

# 다운로드를 테스트하려면
docker pull registry.example.gitlab-dedicated.com/<group>/<project>/<image>:<tag>

AWS 연결 문제는 AWS 지원에 문의하세요.

아웃바운드 PrivateLink 연결#

GitLab 관리 DNS: GitLab이 VPC 엔드포인트와 함께 별칭에 대한 프라이빗 호스팅 영역(PHZ)과 DNS 레코드를 만듭니다.
Private DNS: AWS가 엔드포인트 서비스의 프라이빗 DNS 이름을 사용하여 DNS 확인을 자동으로 처리합니다. 이 경우 GitLab은 DNS 레코드를 만들지 않습니다.

VPC 엔드포인트가 필요하지 않은 별칭의 경우 대신 사용자 정의 DNS 레코드를 만들 수 있습니다.

서비스 연결 만들기#

GitLab Dedicated 인스턴스에서 AWS PrivateLink를 통해 VPC의 서비스로 아웃바운드 트래픽을 라우팅하도록 서비스 연결을 만듭니다.

필수 조건:

서비스 이름이 기록된, 내부 서비스에 대해 만든 엔드포인트 서비스. 자세한 내용은 엔드포인트 서비스 만들기를 참조하세요.
인스턴스가 배포된 가용 영역에 구성된 네트워크 로드 밸런서(NLB). 구성된 AZ를 사용하거나(Switchboard Overview 페이지에 표시됨) 리전의 모든 AZ에서 NLB를 활성화합니다.

서비스 연결을 만들려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장한 다음 Outbound PrivateLink connections를 선택합니다.
Set up endpoint service in AWS를 확장하고 Outbound PrivateLink IAM principal에서 ARN을 복사합니다.
AWS 엔드포인트 서비스에서 Allowed Principals 목록에 ARN을 추가합니다. 자세한 내용은 권한 관리를 참조하세요.
Service connections 탭을 선택합니다.
Create service connection을 선택합니다.
필드를 완성합니다:
- Alias: GitLab Dedicated 인스턴스가 서비스에 도달하는 데 사용하는 DNS 이름을 입력합니다. 예를 들어 my-service.example.com.
- 선택 사항. Description: 이 연결에 대한 설명을 입력합니다.
기본 리전에서 필드를 완성합니다:
- VPC endpoint: New VPC endpoint를 선택하고 AWS 계정의 VPC 엔드포인트 서비스 이름을 입력하거나(예: com.amazonaws.vpce.us-east-1.vpce-svc-0a123bcd4e5f678gh), Existing VPC endpoint를 선택하고 드롭다운 목록에서 엔드포인트를 선택합니다.
- 선택 사항. Description: 이 리전의 엔드포인트에 대한 설명을 입력합니다.
- DNS: GitLab이 프라이빗 호스팅 영역 레코드를 유지하도록 하려면 GitLab-managed DNS를 선택하고, AWS의 VPC 엔드포인트 서비스에 구성된 프라이빗 DNS 이름을 사용하려면 Private DNS를 선택합니다.
보조 리전에 대해 다음 중 하나를 수행합니다:
- VPC 엔드포인트를 추가하려면 기본 리전과 동일한 필드를 완성합니다.
- 보조 리전을 건너뛰려면 섹션 오른쪽 상단에서 Remove를 선택합니다.
Save를 선택합니다.

사용자 정의 DNS 레코드 만들기#

사용자 정의 DNS 레코드를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장한 다음 Outbound PrivateLink connections를 선택합니다.
Custom DNS records 탭을 선택합니다.
Create DNS record를 선택합니다.
필드를 완성합니다:
- Alias: GitLab Dedicated 인스턴스가 서비스에 도달하는 데 사용하는 DNS 이름을 입력합니다. 예를 들어 my-internal-service.example.com.
- 선택 사항. Description: 이 레코드에 대한 설명을 입력합니다.
- 선택 사항. 레코드 이름이 레코드 이름과 프라이빗 호스팅 영역으로 분할되는 방식을 제어하려면 **Customize DNS record and zone split (advanced)**를 선택합니다. 선택하면 Record name 텍스트 박스가 읽기 전용이 되며 입력한 Record name 및 Private hosted zone name 값으로 자동으로 구성됩니다.
각 리전에서 별칭이 확인되는 Target domain name을 입력합니다. 장애 조치를 지원하려면 기본 및 보조 리전 모두에 대해 대상 도메인 이름을 입력합니다.
Save를 선택합니다.
페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

지원 요청으로 아웃바운드 PrivateLink 연결 구성#

Switchboard를 사용하여 아웃바운드 PrivateLink 연결을 구성할 수 없는 경우:

지원 티켓을 열고 다음을 제공합니다:
- VPC 엔드포인트 서비스 이름.
- 사용하려는 DNS 별칭(해당하는 경우).
- 엔드포인트 서비스에서 Private DNS가 활성화되었는지 여부.
GitLab에서 제공한 IAM 주체의 ARN을 복사하여 엔드포인트 서비스의 Allowed Principals 목록에 추가합니다. 자세한 내용은 권한 관리를 참조하세요.

아웃바운드 PrivateLink 연결 삭제#

서비스 연결 또는 VPC 엔드포인트를 독립적으로 삭제할 수 있습니다. 각각 Switchboard에 자체 탭이 있습니다: Service connections 및 VPC endpoints.

서비스 연결을 삭제하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장합니다.
Service connections 탭을 선택합니다.
삭제하려는 연결로 이동하여 Delete([remove])를 선택합니다.
Delete를 선택합니다.

VPC 엔드포인트를 삭제하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Outbound PrivateLink connections를 확장합니다.
VPC endpoints 탭을 선택합니다.
삭제하려는 엔드포인트로 이동하여 Delete([remove])를 선택합니다.
Delete를 선택합니다.

IPv6 연결#

인스턴스에 IPv6를 켜면:

인스턴스가 듀얼 스택 모드로 작동합니다. IPv4 액세스는 IPv6와 함께 계속 작동합니다.
GitLab 웹 인터페이스를 IPv6를 통해 사용할 수 있게 됩니다.
clone, push, pull과 같은 SSH Git 작업을 IPv6를 통해 사용할 수 있게 됩니다.

필수 조건:

인스턴스가 Cloudflare WAF를 통해 프록시되어야 합니다. 인스턴스에 Cloudflare WAF가 켜져 있는지 확실하지 않은 경우 고객 성공 관리자에게 문의하세요.
인스턴스가 GitLab 18.11.4 이상을 실행해야 합니다.

구성은 다음 유지보수 창 동안 적용됩니다.

IP 허용 목록#

Switchboard를 사용하여 IP 허용 목록을 구성 및 관리하거나 Switchboard를 사용할 수 없는 경우 지원 요청을 제출합니다.

Switchboard로 허용 목록에 IP 주소 추가#

허용 목록에 IP 주소를 추가하려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
IP allowlist를 확장하고 IP allowlist를 선택하여 IP 허용 목록 페이지로 이동합니다.
IP 허용 목록을 활성화하려면 수직 줄임표(⋮)를 선택하고 Enabled를 선택합니다.
다음 중 하나를 수행합니다:
- 단일 IP 주소를 추가하려면:
1. Add IP address를 선택합니다.
2. IP address 텍스트 박스에 다음 중 하나를 입력합니다:
  - 단일 IPv4 또는 IPv6 주소(예: 192.168.1.1 또는 2001:db8::1).
  - CIDR 표기법의 IPv4 또는 IPv6 주소 범위(예: 192.168.1.0/24 또는 2001:db8::/32).
3. Description 텍스트 박스에 설명을 입력합니다.
4. Add를 선택합니다.
- 여러 IP 주소를 가져오려면:
1. Import를 선택합니다.
2. CSV 파일을 업로드하거나 IP 주소 목록을 붙여넣습니다.
3. Continue를 선택합니다.
4. 유효하지 않거나 중복된 항목을 수정한 후 Continue를 선택합니다.
5. 변경 사항을 검토하고 Import를 선택합니다.
페이지 상단에서 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

Switchboard로 허용 목록에서 IP 주소 삭제#

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
IP allowlist를 확장하고 IP allowlist를 선택하여 IP 허용 목록 페이지로 이동합니다.
다음 중 하나를 수행합니다:
- 단일 IP 주소를 삭제하려면:
1. 제거하려는 IP 주소 옆에서 휴지통 아이콘([remove])을 선택합니다.
2. Delete IP address를 선택합니다.
- 여러 IP 주소를 삭제하려면:
1. 삭제하려는 IP 주소의 체크박스를 선택합니다.
2. 현재 페이지의 모든 IP 주소를 선택하려면 헤더 행의 체크박스를 선택합니다.
3. IP 주소 테이블 위에서 Delete를 선택합니다.
4. Delete를 선택하여 확인합니다.
페이지 상단에서 변경 사항을 즉시 적용할지 다음 유지보수 창 동안 적용할지 선택합니다.

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

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

GitLab을 OpenID Connect ID 공급자로 사용하려면 OpenID Connect 확인 엔드포인트에 인터넷 액세스가 필요합니다.

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

지원 티켓에서 OpenID Connect 엔드포인트에 대한 액세스를 허용하도록 요청합니다.

구성은 다음 유지보수 창 동안 적용됩니다.

IP 허용 목록에 대해 SCIM 프로비저닝 활성화#

IP 허용 목록을 유지하면서 SCIM을 활성화하려면:

지원 티켓에서 SCIM 엔드포인트를 인터넷에 활성화하도록 요청합니다.

구성은 다음 유지보수 창 동안 적용됩니다.

NAT 게이트웨이 IP 주소#

이 IP 주소를 사용하여 웹훅 수신자를 구성하고 인스턴스에서의 연결을 수락하도록 외부 서비스에 대한 허용 목록을 설정합니다.

NAT 게이트웨이 IP 주소를 보려면:

Switchboard에 로그인합니다.
왼쪽 사이드바에서 Configuration을 선택합니다.
Resource access를 확장합니다.
NAT gateways에서 Copy to clipboard([copy-to-clipboard])를 선택합니다.

AWS PrivateLink 연결 트러블슈팅#

AWS PrivateLink 연결 작업 시 다음 문제가 발생할 수 있습니다.

오류: `Service name could not be verified`#

인바운드 PrivateLink 연결을 위한 VPC 엔드포인트를 만들 때 Service name could not be verified라는 오류가 발생할 수 있습니다.

이 문제는 지원 티켓에 제공된 사용자 정의 IAM 역할이 AWS 계정에 필요한 권한 또는 신뢰 정책이 구성되지 않은 경우에 발생합니다.

이 문제를 해결하려면:

지원 티켓에서 GitLab에 제공된 사용자 정의 IAM 역할을 가정할 수 있는지 확인합니다.

사용자 정의 역할에 이를 가정할 수 있는 신뢰 정책이 있는지 확인합니다. 예를 들어:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::CONSUMER_ACCOUNT_ID:user/user-name"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

사용자 정의 역할에 VPC 엔드포인트 및 EC2 작업을 허용하는 권한 정책이 있는지 확인합니다. 예를 들어:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": "vpce:*",
         "Resource": "*"
      },
      {
         "Sid": "Statement1",
         "Effect": "Allow",
         "Action": [
               "ec2:CreateVpcEndpoint",
               "ec2:DescribeVpcEndpointServices",
               "ec2:DescribeVpcEndpoints"
         ],
         "Resource": "*"
      }
   ]
}

사용자 정의 역할을 사용하여 AWS 콘솔 또는 CLI에서 VPC 엔드포인트 만들기를 재시도합니다.

아웃바운드 PrivateLink 연결 실패#

아웃바운드 PrivateLink 연결이 작동하지 않는 경우 다음을 확인합니다:

네트워크 로드 밸런서(NLB)에서 교차 영역 로드 밸런싱이 켜져 있는지 확인합니다.
적절한 보안 그룹의 인바운드 규칙 섹션이 올바른 IP 범위에서의 트래픽을 허용하는지 확인합니다.
인바운드 트래픽이 엔드포인트 서비스의 올바른 포트에 매핑되어 있는지 확인합니다.
Switchboard에서 Outbound PrivateLink connections를 확장하고 세부 정보가 예상대로 표시되는지 확인합니다.
웹훅과 통합에서 로컬 네트워크에 대한 요청을 허용했는지 확인합니다.

GitLab Dedicated 네트워크 액세스 및 보안

사용자 정의 도메인#

사용자 정의 도메인 세부 정보 보기#

DNSSEC 세부 정보#

표준 구성#

DNS 레코드 구성#

사용자 정의 도메인 활성화#

Cloudflare 보안 구성#

사용자 정의 도메인 요청#

DNS 레코드 구성#

컨테이너 레지스트리 네트워크 액세스#

컨테이너 레지스트리 FQDN 보기#

외부 서비스에 대한 사용자 정의 인증 기관#

사용자 정의 인증서 추가#

AWS PrivateLink 연결#

인바운드 PrivateLink 연결#

인바운드 PrivateLink 연결 만들기#

KAS 및 레지스트리를 위한 DNS 구성#

GitLab Pages를 위한 DNS 구성#

객체 스토리지를 위한 프라이빗 S3 액세스#

VPC에서 프라이빗 S3 액세스 구성#

온프레미스 네트워크에서 프라이빗 S3 액세스 구성#

S3 호스트 이름에 대한 DNS 전달 구성#

아웃바운드 PrivateLink 연결#

서비스 연결 만들기#

사용자 정의 DNS 레코드 만들기#

지원 요청으로 아웃바운드 PrivateLink 연결 구성#

아웃바운드 PrivateLink 연결 삭제#

IPv6 연결#

IP 허용 목록#

Switchboard로 허용 목록에 IP 주소 추가#

Switchboard로 허용 목록에서 IP 주소 삭제#

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

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

IP 허용 목록에 대해 SCIM 프로비저닝 활성화#

NAT 게이트웨이 IP 주소#

AWS PrivateLink 연결 트러블슈팅#

오류: Service name could not be verified#

아웃바운드 PrivateLink 연결 실패#

GitLab Dedicated 네트워크 액세스 및 보안

사용자 정의 도메인#

사용자 정의 도메인 세부 정보 보기#

DNSSEC 세부 정보#

표준 구성#

DNS 레코드 구성#

사용자 정의 도메인 활성화#

Cloudflare 보안 구성#

사용자 정의 도메인 요청#

DNS 레코드 구성#

컨테이너 레지스트리 네트워크 액세스#

컨테이너 레지스트리 FQDN 보기#

외부 서비스에 대한 사용자 정의 인증 기관#

사용자 정의 인증서 추가#

AWS PrivateLink 연결#

인바운드 PrivateLink 연결#

인바운드 PrivateLink 연결 만들기#

KAS 및 레지스트리를 위한 DNS 구성#

GitLab Pages를 위한 DNS 구성#

객체 스토리지를 위한 프라이빗 S3 액세스#

VPC에서 프라이빗 S3 액세스 구성#

온프레미스 네트워크에서 프라이빗 S3 액세스 구성#

S3 호스트 이름에 대한 DNS 전달 구성#

아웃바운드 PrivateLink 연결#

서비스 연결 만들기#

사용자 정의 DNS 레코드 만들기#

지원 요청으로 아웃바운드 PrivateLink 연결 구성#

아웃바운드 PrivateLink 연결 삭제#

IPv6 연결#

IP 허용 목록#

Switchboard로 허용 목록에 IP 주소 추가#

Switchboard로 허용 목록에서 IP 주소 삭제#

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

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

IP 허용 목록에 대해 SCIM 프로비저닝 활성화#

NAT 게이트웨이 IP 주소#

AWS PrivateLink 연결 트러블슈팅#

오류: Service name could not be verified#

아웃바운드 PrivateLink 연결 실패#

오류: `Service name could not be verified`#

오류: `Service name could not be verified`#