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

プラン: Ultimate
提供形態: GitLab Dedicated

カスタムドメイン

デフォルトの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設定の詳細を提供し、お客様はサポートと連携してそれらを実装します。

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

標準設定

この設定では、お客様のドメインがCNAMEレコードを使用してGitLabインスタンスに直接接続します。GitLabはLet’s Encryptを使用してSSL証明書を自動的に管理します。これは、公開DNSルックアップを通じてドメインの所有権を検証し、90日ごとに証明書を自動的に更新します。

プライベートネットワーク経由でインスタンスにアクセスする場合でも、SSL証明書管理のためには、カスタムドメインがパブリックインターネットからアクセス可能である必要があります。

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

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証明書を設定します。
カスタムドメインがアクティブになったことを確認します。

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

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

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

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

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

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

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

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

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

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

AWS PrivateLink接続

受信プライベートリンク

AWS PrivateLinkを使用すると、AWS上のVPC内のユーザーとアプリケーションが、ネットワークトラフィックをパブリックインターネット経由で送信することなく、GitLab Dedicatedエンドポイントに安全に接続できます。

プライベートリンクは、GitLab DedicatedインスタンスがデプロイされているプライマリおよびセカンダリのAWSリージョンでのみ作成できます。

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

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

必要なIAM権限

インターフェースVPCエンドポイントを作成するには、IAMプリンシパルは以下の権限を持っている必要があります:

ec2:CreateVpcEndpoint
ec2:DescribeVpcEndpointServices
ec2:DescribeVpcEndpoints
ec2:DescribeVpcs
route53:AssociateVPCWithHostedZone

これらの権限により、以下を行うことができます:

GitLabが提供するエンドポイントサービスを検出する。
インターフェースVPCエンドポイントを作成する。
Private DNSが有効になっている場合、エンドポイントをRoute 53プライベートホストゾーンに関連付ける。

たとえば、VPCエンドポイントを作成するロールまたはユーザーに以下のIAMポリシーをアタッチします:

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

受信プライベートリンクを作成する

前提条件:

お客様のVPCは、GitLab Dedicatedインスタンスと同じリージョンにある必要があります。
IAMプリンシパルは、必要なIAM権限を持っている必要があります。
ロール名を持つIAMプリンシパルのみを使用してください。ロールパスを含めないでください。
- 有効: arn:aws:iam::AWS_ACCOUNT_ID:role/RoleName
- 無効: arn:aws:iam::AWS_ACCOUNT_ID:role/somepath/AnotherRoleName

受信プライベートリンクを作成するには:

スイッチボードにサインインします。
ページ上部で、設定を選択します。
Inbound private linkを展開します。
Add endpoint serviceを選択します。利用可能なすべてのリージョンにすでにプライベートリンクがある場合、このボタンは利用できません。
リージョンを選択します。
VPCエンドポイントを確立するAWS組織内のAWSユーザーまたはロールのIAMプリンシパルを追加します。IAMプリンシパルはIAM role principalsまたはIAM user principalsである必要があります。
保存を選択します。
GitLabはエンドポイントサービスを作成し、プライベートDNSのドメイン検証を処理します。サービスエンドポイント名は、設定ページで利用可能になります。
お客様のAWSアカウントで、VPCにエンドポイントインターフェースを作成します。
エンドポイントインターフェースを以下の設定で設定します:
- Service endpoint name: スイッチボードの設定ページにある名前を使用します。
- Private DNS names enabled: 可能を選択します。
- Subnets: 一致するすべてのサブネットを選択します。
オンボーディング中に提供されたインスタンスURLを使用して、お客様のVPCからGitLab Dedicatedインスタンスに接続します。

受信プライベートリンク向けにKASとレジストリを有効にする

受信プライベートリンクを使用してGitLab Dedicatedインスタンスに接続する場合、メインインスタンスURLのみがプライベートネットワークを介した自動DNS解決を行います。

プライベートネットワークを介してKAS（Kubernetes向けGitLabエージェント）およびレジストリサービスにアクセスするには、お客様のVPCに新しいDNS設定を作成する必要があります。

前提条件:

GitLab Dedicatedインスタンス向けに受信プライベートリンクを設定していること。
お客様のAWSアカウントでRoute 53プライベートホストゾーンを作成する権限があること。

プライベートネットワークを介してKASとレジストリを有効にするには:

お客様のAWSコンソールで、gitlab-dedicated.comのプライベートホストゾーンを作成し、お客様のプライベートリンク接続を含む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アドレスの変更に対して堅牢です。

受信プライベートリンク向けにPagesを有効にする

お客様のVPCに追加のDNS設定を作成することで、KASとレジストリの設定と同様に、プライベートネットワークを介してGitLab Pagesにアクセスします。

プライベートネットワークを介してPagesを有効にするには:

お客様のAWSコンソールで、<your_instance_name>.gitlab-pages.siteのプライベートホストゾーンを作成し、お客様のプライベートリンク接続を含むVPCに関連付けます。
プライベートホストゾーンを作成したら、以下のDNSレコードを追加します:
1. VPCエンドポイント用のApex Aエイリアスレコードを作成します。
2. *.<your_instance_name>.gitlab-pages.siteのCNAMEワイルドカードを作成し、<your_instance_name>.gitlab-pages.siteを指すようにします。

トラブルシューティング

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

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エンドポイントの作成を再試行します。

送信プライベートリンク

送信プライベートリンクにより、GitLab Dedicatedインスタンスと、GitLab Dedicated用のホストされたRunnerが、トラフィックをパブリックインターネットに公開することなく、AWSのお客様のVPCで実行されているサービスと安全に通信できます。

この種の接続により、GitLabの機能がプライベートサービスにアクセスできます:

GitLab Dedicatedインスタンスの場合:
- Webhook
- プロジェクトとリポジトリをインポートまたはミラーする
ホストされたRunnerの場合:
- カスタムシークレットマネージャー
- お客様のインフラストラクチャに保存されているアーティファクトまたはジョブイメージ
- お客様のインフラストラクチャへのデプロイ

次の点を考慮してください:

プライベートリンクを作成できるのは、同じAWSリージョン内でのみです。お客様のVPCが、GitLab Dedicatedインスタンスがデプロイされているのと同じリージョンにあることを確認してください。
接続には、オンボーディング中に選択したリージョン内の2つのアベイラビリティゾーン (AZ) のAvailability Zone IDs (AZ IDs)が必要です。
Dedicatedへのオンボーディング中にAZを指定しなかった場合、GitLabは両方のAZ IDをランダムに選択します。AZ IDは、スイッチボードの概要ページにプライマリおよびセカンダリリージョンの両方について表示されます。
GitLab Dedicatedは、送信プライベートリンク接続の数を10に制限します。

スイッチボードで送信プライベートリンクを追加する

前提条件:

お客様の内部サービスがGitLab Dedicatedで利用可能になるように、エンドポイントサービスを作成します。
Dedicatedインスタンスがデプロイされているアベイラビリティゾーン (AZ) で、エンドポイントサービス用にネットワークロードバランサー (NLB) を設定します。次のいずれかの操作を行います:
- 設定済みのAZを使用します。AZ IDはスイッチボードの概要ページに表示されます。
- リージョン内のすべてのAZでNLBを有効にします。
GitLab Dedicatedがお客様のエンドポイントサービスに接続するために使用するロールのARNを、エンドポイントサービスのAllowed Principalsリストに追加します。このARNは、スイッチボードの送信プライベートリンクIAMプリンシパルで見つけることができます。詳細については、Manage permissionsを参照してください。
推奨。推奨。Acceptance requiredをいいえに設定して、GitLab Dedicatedが単一の操作で接続できるようにします。可能に設定されている場合、接続が開始された後に手動で承認する必要があります。
Acceptance requiredを可能に設定した場合、スイッチボードはいつリンクが承認されたかを正確に判断できません。手動でリンクを承認した後、次回のスケジュールされたメンテナンスまでは、ステータスは保留中と表示され、アクティブとは表示されません。メンテナンス後、リンクステータスは更新され、接続済みとして表示されます。
エンドポイントサービスが作成されたら、サービス名と、Private DNSを有効にしているかどうかをメモします。

スイッチボードにサインインします。
ページ上部で、設定を選択します。
Outbound private linkを展開します。
フィールドに入力します。
エンドポイントサービスを追加するには、Add endpoint serviceを選択します。各リージョンに最大10個のエンドポイントサービスを追加できます。リージョンを保存するには、少なくとも1つのエンドポイントサービスが必要です。
保存を選択します。
オプション。任意。2番目のリージョンに送信プライベートリンクを追加するには、Add outbound connectionを選択し、その後、前の手順を繰り返します。

スイッチボードで送信プライベートリンクを削除する

スイッチボードにサインインします。
ページ上部で、設定を選択します。
Outbound private linkを展開します。
削除したい送信プライベートリンクに移動し、削除 ( ) を選択します。
削除を選択します。
オプション。リージョン内のすべてのリンクを削除するには、リージョンヘッダーから削除 ( ) を選択します。これにより、リージョン設定も削除されます。

サポートチケットで送信プライベートリンクを追加する

お客様の内部サービスがGitLab Dedicatedで利用可能になるように、エンドポイントサービスを作成します。新しいサポートチケットで、関連するService Endpoint Nameを提供します。
Dedicatedインスタンスがデプロイされているアベイラビリティゾーン (AZ) で、エンドポイントサービス用にネットワークロードバランサー (NLB) を設定します。次のいずれかの操作を行います:
- 設定済みのAZを使用します。AZ IDはスイッチボードの概要ページに表示されます。
- リージョン内のすべてのAZでNLBを有効にします。
お客様のサポートチケットで、GitLabは、お客様のエンドポイントサービスへの接続を開始するIAMロールのARNを提供します。AWSのドキュメントに記載されているとおり、このARNがエンドポイントサービスの「Allowed Principals」リストに含まれているか、またはその他のエントリによってカバーされていることを確認する必要があります。オプションではありますが、Acceptance requiredをいいえに設定できるように、明示的に追加する必要があります。これにより、Dedicatedが単一の操作で接続できます。Acceptance requiredを可能のままにした場合、Dedicatedがそれを開始した後、手動で接続を承認する必要があります。
エンドポイントを使用してサービスに接続するには、DedicatedサービスにはDNS名が必要です。プライベートリンクは内部名を自動的に作成しますが、それは機械生成されたものであり、通常は直接役立ちません。2つのオプションが利用可能です:
- お客様のエンドポイントサービスでPrivate DNS nameを有効にし、必要な検証を実行し、このオプションを使用していることをサポートチケットでGitLabに通知します。お客様のエンドポイントサービスでAcceptance Requiredが可能に設定されている場合、DedicatedがPrivate DNSなしで接続を開始し、お客様がそれが承認されたことを確認するのを待ち、その後接続を更新してPrivate DNSの使用を有効にする必要があるため、サポートチケットにもこれを記載してください。
- Dedicatedは、Dedicated AWSアカウント内でプライベートホストゾーン (PHZ) を管理し、任意のDNS名をエンドポイントにエイリアスして、それらの名前に対するリクエストをお客様のエンドポイントサービスにルーティングできます。これらのエイリアスはPHZエントリとして知られています。詳細については、Private hosted zonesを参照してください。

GitLabは、お客様が提供したサービス名に基づいて、テナントインスタンスが必要なエンドポイントインターフェースを作成するように設定します。テナントインスタンスから行われるすべての一致する送信接続は、PrivateLinkを介してお客様のVPCにルーティングされます。

トラブルシューティング

送信プライベートリンクが設定された後で接続を確立するのに問題がある場合、お客様のAWSインフラストラクチャ内のいくつかのことが問題の原因である可能性があります。確認すべき具体的な事柄は、修正しようとしている予期しない動作によって異なります。確認すべき事項は以下のとおりです:

お客様のネットワークロードバランサー (NLB) でクロスゾーンロードバランシングが有効になっていることを確認してください。
適切なセキュリティグループのInbound Rulesセクションが、正しいIP範囲からのトラフィックを許可していることを確認してください。
受信トラフィックがエンドポイントサービスの正しいポートにマップされていることを確認してください。
スイッチボードでOutbound private linkを展開し、詳細が期待どおりに表示されることを確認してください。
Webhookとインテグレーションからのローカルネットワークへのリクエストを許可していることを確認してください。

プライベートホストゾーン

プライベートホストゾーン (PHZ) は、GitLab Dedicatedインスタンスのネットワークで解決されるカスタムDNSレコード（A、CNAME、またはその他のレコードタイプなど）を作成します。

PHZは次の場合に使用します:

単一のエンドポイントを使用する複数のDNSレコード（AやCNAMEレコードなど）を作成する場合（複数のサービスに接続するためにリバースプロキシを実行する場合など）。
パブリックDNSによって検証できないプライベートドメインを使用する場合。

PHZは、AWSが生成したエンドポイント名を使用する代わりに、リバースPrivateLinkと組み合わせて読みやすいドメイン名を作成するために一般的に使用されます。たとえば、vpce-0987654321fedcba0-k99y1abc.vpce-svc-0a123bcd4e5f678gh.eu-west-1.vpce.amazonaws.comの代わりにalpha.beta.tenant.gitlab-dedicated.comを使用できます。

場合によっては、PHZを使用して、公開アクセス可能なDNS名に解決されるDNSレコードを作成することもできます。たとえば、内部システムがプライベート名を通じてサービスにアクセスする必要がある場合、パブリックエンドポイントに解決される内部DNS名を作成できます。

プライベートホストゾーンへの変更は、これらのレコードを使用するサービスを最大5分間中断させる可能性があります。

PHZドメイン構造

PHZレコードは異なるタイプのターゲットを指すことができます。最も一般的で推奨されるアプローチは、AWS VPCエンドポイントのDNS名を指すことです。

GitLab DedicatedインスタンスのドメインをVPCエンドポイントとのエイリアスの一部として使用する場合、メインドメインの前に少なくとも1つのサブドメインを含める必要があります。例:

有効なPHZエントリ: subdomain1.<your-tenant-id>.gitlab-dedicated.com。
無効なPHZエントリ: <your-tenant-id>.gitlab-dedicated.com。

カスタムドメインの場合、phz-entry.phz-name.comの形式でPHZ名とPHZエントリを指定する必要があります。

PHZレコードがVPCエンドポイントではないDNS名を指す場合、メインドメインの前に少なくとも2つのサブドメインを含める必要があります。例: subdomain1.subdomain2.tenant.gitlab-dedicated.com。

スイッチボードでプライベートホストゾーンを追加する

プライベートホストゾーンを追加するには:

スイッチボードにサインインします。
ページ上部で、設定を選択します。
Private hosted zonesを展開します。
Add private hosted zone entryを選択します。
フィールドに入力します。
- ホスト名フィールドに、お客様のプライベートホストゾーン (PHZ)エントリを入力します。
- Link typeには、以下のいずれかを選択します:
  - 送信プライベートリンクPHZエントリの場合は、ドロップダウンリストからエンドポイントサービスを選択します。AvailableまたはPending Acceptanceステータスのリンクのみが表示されます。
  - その他のPHZエントリについては、DNSエイリアスのリストを提供します。
保存を選択します。お客様のPHZエントリとエイリアスはリストに表示されるはずです。
ページ上部までスクロールし、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

サポートチケットでプライベートホストゾーンを追加する

スイッチボードを使用してプライベートホストゾーンを追加できない場合は、サポートチケットを開き、送信プライベートリンク用のエンドポイントサービスに解決するべきDNS名のリストを提供できます。リストは必要に応じて更新できます。

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アドレス（例: 192.168.1.1）。
  - CIDR表記のIPv4アドレス範囲（例: 192.168.1.0/24）。
3. 説明テキストボックスに説明を入力します。
4. 追加を選択します。
- 複数のIPアドレスをインポートするには:
1. インポートを選択します。
2. CSVファイルをアップロードするか、IPアドレスのリストを貼り付けます。
3. 続行するを選択します。
4. 無効なエントリまたは重複するエントリを修正し、次に進むを選択します。
5. 変更を確認し、インポートを選択します。
ページ上部で、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

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

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

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

スイッチボードを使用してIP許可リストを更新できない場合は、サポートチケットを開き、インスタンスにアクセスできるコンマ区切りの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エンドポイントへのインターネットアクセスを有効にするようリクエストします。

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

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

カスタムドメイン

標準設定

DNSレコードを設定する

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

Cloudflareセキュリティ設定

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

DNSレコードを設定する

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

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

AWS PrivateLink接続

受信プライベートリンク

必要なIAM権限

受信プライベートリンクを作成する

受信プライベートリンク向けにKASとレジストリを有効にする

受信プライベートリンク向けにPagesを有効にする

トラブルシューティング

エラー: Service name could not be verified

送信プライベートリンク

スイッチボードで送信プライベートリンクを追加する

スイッチボードで送信プライベートリンクを削除する

サポートチケットで送信プライベートリンクを追加する

トラブルシューティング

プライベートホストゾーン

PHZドメイン構造

スイッチボードでプライベートホストゾーンを追加する

サポートチケットでプライベートホストゾーンを追加する

IP許可リスト

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

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

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

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

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

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