GitLab Dedicatedのネットワークアクセスとセキュリティ

プラン: Ultimate
提供形態: 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 challengeを使用します。これには以下が必要です:

CNAMEレコードがDNSを通じて公開で解決可能であること。
90日ごとの証明書自動更新に対する、同じ公開検証プロセス。

プライベートネットワーキング（AWS PrivateLinkなど）で設定されたインスタンスの場合、他のすべてのアクセスがプライベートネットワークに制限されている場合でも、パブリックDNS解決により証明書管理が適切に機能することが保証されます。

GitLab Dedicatedは、次の2つの設定方法でカスタムドメインをサポートしています:

標準設定: CNAMEレコードとLet’s Encrypt証明書を使用します。お客様ご自身でDNSレコードを設定し、サポートを通じてドメインアクティベーションをリクエストします。
Cloudflareセキュリティ設定: NSレコードとLet’s Encrypt証明書を使用します。GitLabはDNS設定の詳細を提供し、お客様はサポートと連携してそれらを実装します。

お客様のインスタンスにどの設定方法が適用されるかを決定するために、カスタマーサクセスマネージャーに連絡してください。

カスタムドメインの詳細を表示

Custom domainsセクションには、GitLab Dedicatedインスタンスのアクティブなドメイン設定が表示されます。これには以下が含まれます:

GitLabインスタンスドメイン: GitLabインスタンスのカスタムドメイン。
レジストリドメイン: コンテナレジストリのカスタムドメイン。
KASドメイン: Kubernetes向けGitLabエージェントサーバー（KAS）のカスタムドメイン。

この情報を使用して、次を行います:

現在のカスタムドメイン設定を確認します。
外部インテグレーションの参照ドメイン。
DNS管理用の設定詳細をコピーします。

カスタムドメインの詳細を表示するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Custom domainsを展開します。

DNSSECの詳細

プラン: Ultimate
提供形態: 政府機関向けGitLab Dedicated

カスタムドメインがCloudflare Web Application Firewall（WAF）で構成されている場合、スイッチボードはCloudflareネームサーバーやFedRAMPコンプライアンス向けのDNSSECパラメータを含む追加の設定詳細を表示します。

追加の詳細には以下が含まれます:

Cloudflareネームサーバー: Cloudflare管理ドメイン用のDNSネームサーバー。
キータグ: DNSSECキーの数値識別子。
アルゴリズム: 使用される暗号学的アルゴリズム（通常、ECDSA P-256 with SHA-256の場合は13）。
ダイジェストタイプ: 使用されるハッシュアルゴリズム（通常、SHA-256の場合は2）。
ダイジェスト: 公開キーの暗号学的ハッシュ。

これらの値を使用して、DNSプロバイダーでDNS委任およびDNSSEC検証を構成します。

標準設定

この設定では、お客様のドメインがCNAMEレコードを使用してGitLabインスタンスに直接接続します。お客様ご自身でDNSレコードを設定し、サポートを通じてドメインアクティベーションをリクエストします。

プライベートネットワーキングを介してインスタンスにアクセスする場合でも、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セキュリティ設定

この設定では、Cloudflare Web Application Firewall（WAF）を介してトラフィックをルーティングできるように、お客様のドメインをNSレコードを使用してGitLabに委任する必要があります。Cloudflareは、お客様のドメインのすべてのDNS設定を管理し、強化されたセキュリティ機能を提供します。

このアプローチには、カスタマーサクセスマネージャーとの連携が必要です。設定はインスタンスのメンテナンス期間中に適用されます。

カスタムドメインをリクエストする

カスタムドメインをリクエストするには:

サポートチケットを提出します。
サポートチケットで、以下を指定します:
- カスタムドメイン名。例: gitlab.company.com。
- コンテナレジストリとKubernetes向けGitLabエージェントサーバーにカスタムドメインが必要な場合は、使用したいドメイン名を含めます。たとえば、registry.company.comおよびkas.company.com。
- お客様のコンプライアンス要件。たとえば、FedRAMP。

GitLabはCloudflareでお客様のドメインを設定し、以下を提供します:

2つのCloudflareネームサーバー（name1.ns.cloudflare.comおよびname2.ns.cloudflare.comなど）。
DNSSECパラメータ（FedRAMPのお客様のみ）、以下を含む:
- キータグ: 数値識別子（GitLabによって提供）
- アルゴリズム: 通常13（ECDSA P-256 with SHA-256）または8（RSA/SHA-256）
- ダイジェストタイプ: 通常2（SHA-256）
- ダイジェスト: 公開キーの暗号学的ハッシュ（GitLabによって提供）

DNSレコードを設定する

DNSプロバイダーでNSレコードを設定し、サブドメインをCloudflareに委任します。

前提条件:

ドメインホストの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時間かかることがあります。

構成を検証する:

# Verify nameserver delegation
dig +short NS gitlab.company.com

# Verify DNS resolution
dig gitlab.company.com

# Verify DNSSEC (if configured)
dig +dnssec gitlab.company.com

サポートチケットを通じて、DNS設定が完了したことをGitLabに通知します。

その後、GitLabは次の処理を行います。

DNS委任を検証します。
SSL/TLS証明書を設定します。
カスタムドメインがアクティブになったことを確認します。

コンテナレジストリのネットワーキングアクセス

コンテナレジストリのFQDN（完全修飾ドメイン名）は、インスタンスのコンテナレジストリデータを保存するS3バケットを識別します。

コンテナレジストリのFQDNを表示

IPアドレスの代わりにFQDNを使用して、レジストリのストレージ場所を参照するファイアウォールルールとネットワーキングポリシーを構成します。S3バケットのIPアドレスは時間とともに変化する可能性があります。

コンテナレジストリのFQDNを表示するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
リソースアクセスを展開します。
コンテナレジストリで、クリップボードにコピー（）を選択します。

外部サービス向けのカスタム認証局

GitLab Dedicatedは、HTTPS経由で外部サービスに接続する際に証明書を検証します。デフォルトでは、GitLab Dedicatedは公開で認識された認証局のみを信頼し、信頼できない認証局からの証明書を持つサービスへの接続を拒否します。

外部サービスがプライベートまたは内部認証局からの証明書を使用している場合、その認証局をGitLab Dedicatedインスタンスに追加する必要があります。

カスタム認証局が必要となる場合があります:

内部Webhookエンドポイントに接続します。
プライベートコンテナレジストリからイメージをプルします。
企業の公開キーインフラストラクチャの背後にあるオンプレミスサービスと統合します。

カスタム証明書を追加する

証明書チェーンブロック（単一のテキストブロックに複数の証明書）はサポートされていません。チェーンに複数の証明書がある場合は、各証明書を個別にインストールします。

カスタム証明書を追加するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Custom certificate authoritiesを展開します。
+ Add Certificateを選択します。
単一の証明書をテキストボックスに貼り付けます。-----BEGIN CERTIFICATE-----と-----END CERTIFICATE-----の行を含めます。
保存を選択します。
チェーン内の追加の各証明書について、手順4～6を繰り返します。
ページ上部までスクロールし、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

スイッチボードを使用してカスタム証明書を追加できない場合は、サポートチケットを開き、各カスタム証明書を個別のファイルとして添付します。

AWS PrivateLink接続

AWS PrivateLinkは、AWSインフラストラクチャとGitLab Dedicatedインスタンス間のプライベートネットワーキング接続を、パブリックインターネット経由でトラフィックをルーティングすることなく有効にします。すべてのトラフィックはAWSネットワーク内にとどまり、外部の脅威への露出を減らし、プライベートネットワーキングのコンプライアンス要件を満たすのに役立ちます。

GitLab Dedicatedは2種類のPrivateLink接続をサポートしています:

受信PrivateLink接続: VPC内のユーザーとアプリケーションは、GitLab Dedicatedインスタンスにプライベートに接続します。インスタンスがパブリックインターネット経由でアクセスできないようにアクセスを制限する場合にこれを使用します。
送信PrivateLink接続: GitLab DedicatedインスタンスとホストされたRunnerは、VPCで実行されているサービスにプライベートに接続します。これをWebhook、プロジェクトミラーリング、シークレットマネージャー、またはインフラストラクチャへのデプロイに使用します。

PrivateLink接続はGitLab Dedicatedインスタンスと同じAWSリージョンにある必要があり、プライマリおよびセカンダリAWSリージョンでのみエンドポイントサービスを作成できます。

AWS PrivateLinkの詳細については、what is AWS PrivateLink?を参照してください。

受信PrivateLink接続

受信PrivateLink接続により、VPC内のユーザーとアプリケーションがGitLab Dedicatedインスタンスにプライベートに接続できます。

エンドポイントサービスを作成する際、アクセスを制御するIAMプリンシパルを指定します。指定したIAMプリンシパルのみが、インスタンスに接続するためのVPCエンドポイントを作成できます。

各エンドポイントサービスは、オンボーディング中に選択されるか、ランダムに選択される2つのアベイラビリティーゾーンで利用できます。

IAMプリンシパルは、地域ごとに個別に構成されます。地域間で同じプリンシパルを再利用することも、セカンダリ地域が別のAWSアカウントを使用している場合は異なるプリンシパルを使用することもできます。

受信PrivateLink接続を作成する

受信PrivateLink接続を作成して、VPC内のユーザーとアプリケーションがGitLab Dedicatedインスタンスにプライベートに接続できるようにします。

地域的なフェイルオーバー中にこの接続を維持するには、セカンダリ地域エンドポイントを構成します。これがないと、プライマリ地域が利用できなくなった場合、インスタンスにプライベートにアクセスできません。

前提条件:

構成したい地域ごとのVPC。
GitLabが提供するエンドポイントサービスを検出する権限、インターフェースVPCエンドポイントを作成する権限、およびプライベートDNSが有効な場合にそれをRoute 53プライベートホストゾーンに関連付ける権限を持つIAMプリンシパル。
ロールパスなしで、ロール名のみを持つIAMプリンシパル。
- 有効: arn:aws:iam::AWS_ACCOUNT_ID:role/RoleName
- 無効: arn:aws:iam::AWS_ACCOUNT_ID:role/somepath/AnotherRoleName

受信PrivateLink接続を作成するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Inbound PrivateLink connectionsを展開します。
Add endpoint serviceを選択します。
リージョンを選択します。
IAM principalsの下で、エンドポイントサービスへの接続を開始できるAWSユーザーまたはロールを追加します。IAMプリンシパルは、IAM role principalsまたはIAM user principalsである必要があります。

AWSアカウントで、VPCエンドポイントを作成するロールまたはユーザーに、以下の権限を持つポリシーをアタッチします:

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

推奨。推奨。セカンダリ地域を構成するには、地域の下のSecondary regionを選択します。これにより、指定されたIAMプリンシパルを使用して、両方の地域にエンドポイントサービスが作成されます。
保存を選択します。GitLabはエンドポイントサービスを作成し、サービスエンドポイント名は設定ページで利用可能になります。

次に、構成した地域ごとに、AWSセットアップを完了します:

お客様のAWSアカウントで、VPCにエンドポイントインターフェースを作成します。
エンドポイントインターフェースを以下の設定で設定します:
- Service endpoint name: スイッチボードの設定ページから、その地域の名前を使用します。
- Private DNS names enabled: 可能を選択します。
- Subnets: 一致するすべてのサブネットを選択します。
オンボーディング中に提供されたインスタンスURLを使用して、お客様のVPCからGitLab Dedicatedインスタンスに接続します。

AWS VPCエンドポイントの設定を自動化するには、terraform-inbound-privatelink Terraformモジュールを使用できます。このモジュールは、DNSをスイッチする際に必要となるRoute 53レコードも出力します。

KASとレジストリのDNSを構成する

VPCに追加のDNS設定を作成して、プライベートネットワーキング経由でKAS（Kubernetes向けGitLabエージェントサーバー）とコンテナレジストリにアクセスします。

前提条件:

受信PrivateLink接続を構成済みであること。
AWSアカウントでRoute 53プライベートホストゾーンを作成する権限があること。

KASとレジストリのDNSを構成するには:

AWSコンソールで、gitlab-dedicated.com用のプライベートホストゾーンを作成し、受信PrivateLink接続を含むVPCに関連付けます。
プライベートホストゾーンを作成したら、以下のDNSレコードを追加します（exampleをお客様のインスタンス名に置き換えます）:
1. GitLab DedicatedインスタンスのAレコードを作成します:
  - 完全なインスタンスドメイン（例: example.gitlab-dedicated.com）を、VPCエンドポイントをエイリアスとして解決するように構成します。
  - アベイラビリティーゾーンの参照を含まない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エイリアスレコードを作成します。
2. *.<tenant_name>.gitlab-dedicated.siteを<tenant_name>.gitlab-dedicated.siteにポイントするワイルドカードCNAMEを作成します。

送信PrivateLink接続

送信PrivateLink接続により、GitLab DedicatedインスタンスとホストされたRunnerは、パブリックインターネットにトラフィックを公開することなく、VPCで実行されているサービスとプライベートに通信できます。

送信PrivateLink接続を使用して、Webhookを送信したり、プロジェクトをインポートまたはミラーリングしたり、ホストされたRunnerにカスタムシークレットマネージャー、アーティファクト、ジョブイメージ、インフラストラクチャへのデプロイへのアクセス権を付与したりします。

地域ごとに最大10個の送信PrivateLink接続を作成できます。10を超えるバックエンドサービスを単一の接続の背後に統合するには、terraform-outbound-proxy Terraformモジュールを使用して、TLSパススルー、HTTPルーティング、およびSMTP転送を備えた高可用性NGINXリバースプロキシをデプロイできます。

スイッチボードの送信PrivateLink接続は、接続を管理するためにサービス接続を使用します。サービス接続は、DNSエイリアスをAWSアカウントのVPCエンドポイントサービスにリンクします。各サービス接続には、地域ごとに1つ（プライマリとセカンダリ）の、最大2つのVPCエンドポイントを持つことができます。サービス接続を作成するときに、DNSがどのように解決されるかを選択します:

GitLab管理DNS: GitLabは、VPCエンドポイントとともにエイリアスのプライベートホストゾーン（PHZ）とDNSレコードを作成します。
プライベートDNS: AWSは、エンドポイントサービスのプライベートDNS名を使用してDNS解決を自動的に処理します。この場合、GitLabはDNSレコードを作成しません。

VPCエンドポイントを必要としないエイリアスの場合は、代わりにcreate a custom DNS recordを作成できます。

サービス接続を作成する

GitLab Dedicatedインスタンスからの送信トラフィックを、AWS PrivateLink経由でVPC内のサービスにルーティングするサービス接続を作成します。

地域的なフェイルオーバー中にこの接続を維持するには、セカンダリ地域エンドポイントを構成します。これがないと、プライマリ地域が利用できなくなった場合、送信接続は利用できなくなります。サービス接続が1つの地域にのみVPCエンドポイントを持っている場合、スイッチボードは警告を表示します。

前提条件:

内部サービス用に作成されたエンドポイントサービス（サービス名をメモ済み）。詳細については、create an endpoint serviceを参照してください。
インスタンスがデプロイされているアベイラビリティーゾーンで構成されたネットワークロードバランサー（NLB）。構成済みのAZ（スイッチボードの概要ページに表示）を使用するか、地域のすべてのAZでNLBを有効にします。

サービス接続を作成するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Outbound PrivateLink connectionsを展開し、次にOutbound PrivateLink connectionsを選択します。
Set up endpoint service in AWSを展開し、Outbound PrivateLink IAM principalからARNをコピーします。
AWSエンドポイントサービスで、ARNをAllowed Principalsリストに追加します。詳細については、manage permissionsを参照してください。
Service connectionsタブを選択します。
Create service connectionを選択します。
フィールドに入力します:
- Alias: GitLab Dedicatedインスタンスがサービスに到達するために使用するDNS名を入力します。例: my-service.example.com。
- オプション。説明: この接続の説明を入力します。
プライマリ地域の下で、フィールドに入力します:
- VPC endpoint: New VPC endpointを選択し、AWSアカウントからVPCエンドポイントサービス名（例: com.amazonaws.vpce.us-east-1.vpce-svc-0a123bcd4e5f678gh）を入力するか、Existing VPC endpointを選択してドロップダウンリストからエンドポイントを選択します。
- オプション。説明: この地域のエンドポイントの説明を入力します。
- DNS: GitLabにプライベートホストゾーンレコードを保持させるにはGitLab-managed DNSを選択するか、AWSのVPCエンドポイントサービスで構成されたプライベートDNS名を使用するにはPrivate DNSを選択します。
セカンダリ地域に対して、次のいずれかを実行します:
- VPCエンドポイントを追加するには、プライマリ地域と同じフィールドに入力します。
- セカンダリ地域をスキップするには、セクションの右上にある削除を選択します。
保存を選択します。

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クエリにどのように応答するかに関する情報を保持するコンテナです。詳細については、private hosted zonesを参照してください。

カスタムDNSレコードの変更、またはGitLab管理DNS（プライベートホストゾーン）を使用している場合のサービス接続の変更は、これらのレコードを使用するサービスを最大5分間中断する可能性があります。

カスタムDNSレコードを追加するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Outbound PrivateLink connectionsを展開し、次にOutbound PrivateLink connectionsを選択します。
Custom DNS recordsタブを選択します。
Create DNS recordを選択します。
フィールドに入力します:
- Alias: GitLab Dedicatedインスタンスがサービスに到達するために使用するDNS名を入力します。例: my-internal-service.example.com。
- オプション。説明: このレコードの説明を入力します。
- オプション。オプション。Customize DNS record and zone split（advanced）を選択して、レコード名がレコード名とプライベートホストゾーンに分割される方法を制御します。選択すると、Record nameテキストボックスは読み取り専用になり、入力したRecord nameとPrivate hosted zone nameの値から自動的に構成されます。
各地域の下で、エイリアスが解決するTarget domain nameを入力します。フェイルオーバーをサポートするために、プライマリとセカンダリの両方の地域にターゲットドメイン名を入力します。
保存を選択します。
ページ上部までスクロールし、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

サポートリクエストで送信PrivateLink接続を構成する

スイッチボードを使用して送信PrivateLink接続を構成できない場合:

support ticketを開き、以下を提供します:
- VPCエンドポイントサービス名。
- 該当する場合、使用したいDNSエイリアス。
- エンドポイントサービスでプライベートDNSが有効になっているかどうか。
GitLabから提供されたIAMプリンシパルのARNをコピーし、エンドポイントサービスのAllowed Principalsリストに追加します。詳細については、manage permissionsを参照してください。

送信PrivateLink接続を削除する

サービス接続またはVPCエンドポイントを個別に削除できます。それぞれがスイッチボードに独自のタブを持っています: Service connectionsとVPC endpoints。

サービス接続を削除するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Outbound PrivateLink connectionsを展開します。
Service connectionsタブを選択します。
削除したい接続に移動し、削除（）を選択します。
削除を選択します。

VPCエンドポイントを削除するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
Outbound PrivateLink connectionsを展開します。
VPC endpointsタブを選択します。
削除したいエンドポイントに移動し、削除（）を選択します。
削除を選択します。

IPv6接続

IPv6接続により、クライアントはIPv4に加えてIPv6経由でGitLab Dedicatedインスタンスに到達できます。Cloudflareはこのトラフィックを受信し、IPv4に変換してから、インスタンスの既存のIPv4インフラストラクチャにリクエストを転送します。GitLab Dedicatedプラットフォームサービス間の内部通信はIPv4のみです。

インスタンスでIPv6を有効にすると:

インスタンスはデュアルスタックモードで動作します。IPv4アクセスはIPv6とともに動作し続けます。
GitLabウェブインターフェースはIPv6経由で利用可能になります。
SSH Git操作（クローン、プッシュ、プルなど）はIPv6経由で利用可能になります。

前提条件:

インスタンスはCloudflare WAFを経由してプロキシされる必要があります。インスタンスでCloudflare WAFが有効になっているかどうかわからない場合は、カスタマーサクセスマネージャーに問い合わせてください。
インスタンスはGitLab 18.11.4以降を実行している必要があります。

スイッチボードはこの設定をサポートしていません。IPv6接続を有効にするには、support ticketを開き、インスタンスへのHTTPSおよびSSHアクセスにIPv6接続を有効にしたいことを確認してください。

IPv6が有効になると、インスタンスのパブリックIPアドレスはIPv4とIPv6の両方で変更されます。これらのアドレスをファイアウォール、DNSレコード、またはモニタリングシステムで許可リストに登録している場合は、変更が適用された後にこれらの設定を更新してください。IPv6を無効にすると、IPアドレスが再び変更されます。

この設定は、次回のメンテナンス期間中に適用されます。

IP許可リスト

IP許可リストを使用して、どのIPアドレスがインスタンスにアクセスできるかを制御します。IP許可リストを有効にすると、IP許可リストにないIPアドレスはブロックされ、インスタンスにアクセスしようとするとHTTP 403 Forbidden応答を受け取ります。

スイッチボードを使用してIP許可リストを設定および管理するか、スイッチボードが利用できない場合はサポートチケットを提出してください。

スイッチボードでIPアドレスを許可リストに追加する

IPアドレスを許可リストに追加するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
IP allowlistを展開し、IP allowlistを選択してIP許可リストページに移動します。
IP許可リストを有効にするには、縦方向の省略記号（）を選択し、有効を選択します。
次のいずれかを実行します。
- 単一のIPアドレスを追加するには:
1. Add IP addressを選択します。
2. IPアドレステキストボックスに、以下のいずれかを入力します:
  - 単一のIPv4またはIPv6アドレス（例: 192.168.1.1または2001:db8::1）。
  - CIDR表記のIPv4またはIPv6アドレス範囲（例: 192.168.1.0/24または2001:db8::/32）。
3. 説明テキストボックスに説明を入力します。
4. 追加を選択します。
- 複数のIPアドレスをインポートするには:
1. インポートを選択します。
2. CSVファイルをアップロードするか、IPアドレスのリストを貼り付けます。
3. 続行するを選択します。
4. 無効なエントリまたは重複するエントリを修正し、次に進むを選択します。
5. 変更を確認し、インポートを選択します。
ページ上部で、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

スイッチボードで許可リストからIPアドレスを削除する

許可リストからIPアドレスを削除するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
IP allowlistを展開し、IP allowlistを選択してIP許可リストページに移動します。
次のいずれかを実行します。
- 単一のIPアドレスを削除するには:
1. 削除したいIPアドレスの横にあるゴミ箱アイコン（）を選択します。
2. Delete IP addressを選択します。
- 複数のIPアドレスを削除するには:
1. 削除したいIPアドレスのチェックボックスを選択します。
2. 現在のページのすべてのIPアドレスを選択するには、ヘッダー行のチェックボックスを選択します。
3. IPアドレステーブルの上で、削除を選択します。
4. 削除を選択して確定します。
ページ上部で、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

サポートチケットでIPを許可リストに追加する

スイッチボードを使用してIP許可リストを更新できない場合は、support ticketを開き、インスタンスにアクセスできるIPアドレスのコンマ区切りリストを指定してください。

IP許可リスト向けにOpenID Connectを有効にする

OpenID Connect identity providerとしてGitLabを使用すると、OpenID Connect検証エンドポイントへのインターネットアクセスが必要です。

IP許可リストを維持しながらOpenID Connectエンドポイントへのアクセスを有効にするには:

サポートチケットで、OpenID Connectエンドポイントへのアクセスを許可するようリクエストします。

この設定は、次回のメンテナンス期間中に適用されます。

IP許可リスト向けにSCIMプロビジョニングを有効にする

外部Identity Providerと組み合わせてSCIMを使用し、ユーザーを自動的にプロビジョニングおよび管理できます。SCIMを使用するには、お客様のIdentity ProviderがインスタンスSCIMAPIエンドポイントにアクセスできる必要があります。デフォルトでは、IP許可リストはこれらのエンドポイントへの通信をブロックします。

IP許可リストを維持しながらSCIMを有効にするには:

サポートチケットで、SCIMエンドポイントへのインターネットアクセスを有効にするようリクエストします。

この設定は、次回のメンテナンス期間中に適用されます。

NATゲートウェイIPアドレス

NATゲートウェイIPアドレスは、インスタンスの外部サービスへの送信接続を識別します。通常は一貫していますが、地域的なフェイルオーバーが発生した場合は、インスタンスが新しいインフラストラクチャで再構築されるため、変更される可能性があります。

これらのIPアドレスを使用して、Webhookレシーバーを構成し、インスタンスからの接続を受け入れる外部サービス用の許可リストを設定します。

NATゲートウェイIPアドレスを表示するには:

スイッチボードにサインインします。
左サイドバーで、設定を選択します。
リソースアクセスを展開します。
NAT gatewaysの下で、クリップボードにコピー（）を選択します。

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範囲からのトラフィックを許可していることを確認します。
インバウンドトラフィックが、エンドポイントサービスの正しいポートにマップされていることを確認します。
スイッチボードでOutbound PrivateLink connectionsを展開し、詳細が期待どおりに表示されていることを確認します。
Webhookとインテグレーションからのローカルネットワークへのリクエストを許可していることを確認してください。

GitLab Dedicatedのネットワークアクセスとセキュリティ

カスタムドメイン

カスタムドメインの詳細を表示

DNSSECの詳細

標準設定

DNSレコードを設定する

カスタムドメインを有効にする

Cloudflareセキュリティ設定

カスタムドメインをリクエストする

DNSレコードを設定する

コンテナレジストリのネットワーキングアクセス

コンテナレジストリのFQDNを表示

外部サービス向けのカスタム認証局

カスタム証明書を追加する

AWS PrivateLink接続

受信PrivateLink接続

受信PrivateLink接続を作成する

KASとレジストリのDNSを構成する

GitLab PagesのDNSを構成する

送信PrivateLink接続

サービス接続を作成する

カスタムDNSレコードを作成する

サポートリクエストで送信PrivateLink接続を構成する

送信PrivateLink接続を削除する

IPv6接続

IP許可リスト

スイッチボードでIPアドレスを許可リストに追加する

スイッチボードで許可リストからIPアドレスを削除する

サポートチケットでIPを許可リストに追加する

IP許可リスト向けにOpenID Connectを有効にする

IP許可リスト向けにSCIMプロビジョニングを有効にする

NATゲートウェイIPアドレス

AWS PrivateLink接続のトラブルシューティング

エラー: Service name could not be verified

送信PrivateLink接続が失敗する

エラー: `Service name could not be verified`