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

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

Bring your own domain（BYOD）

デフォルトでは、GitLab Dedicatedインスタンスには、your-tenant.gitlab-dedicated.comのようなURLでアクセスできます。Bring your own domain（BYOD）を使用すると、独自のカスタムドメイン名を使用して、GitLab Dedicatedインスタンスとそのサービスにアクセスできます。たとえば、gitlab.company.comの代わりにyour-tenant.gitlab-dedicated.comでインスタンスにアクセスできます。

カスタムドメインを追加すると:

ドメインは、インスタンスへのアクセスに使用される外部URLに含まれます。
デフォルトのtenant.gitlab-dedicated.comドメインを使用しているインスタンスへの接続は利用できなくなります。

GitLabは、Let’s Encryptを使用して、カスタムドメインのSSL/TLS証明書を自動的に管理します。Let’s Encryptは、ドメインの所有権を検証するためにHTTP-01 Challengeを使用します。これには以下が必要です:

DNSを介してパブリックに解決できるCNAMEレコード。
90日ごとの自動証明書更新のための同じパブリック検証プロセス。

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

DNSレコードの設定

カスタムドメインを使用するには、まずドメインのDNSレコードを更新します。

前提要件:

ドメインホストのDNS設定へのアクセス。

GitLab DedicatedでカスタムドメインのDNSレコードを設定するには:

ドメインホストのウェブサイトにサインインします。
DNS設定に移動します。
カスタムドメインをGitLab Dedicatedテナントに向けるCNAMEレコードを追加します。例:
```
gitlab.my-company.com.  CNAME  my-tenant.gitlab-dedicated.com
```
オプション。ドメインに既存のCAAレコードがある場合は、有効な認証局としてLet’s Encryptを含めるように更新します。ドメインにCAAレコードがない場合は、このステップをスキップできます。例:
```
example.com.  IN  CAA 0 issue "pki.goog"
example.com.  IN  CAA 0 issue "letsencrypt.org"
```
この例では、CAAレコードは、ドメインの証明書を発行できる認証局として、Google Trust Services（pki.goog）とLet’s Encrypt（letsencrypt.org）を定義します。
変更を保存し、DNSの変更が反映されるまで待ちます。

GitLab Dedicatedインスタンスでカスタムドメインを使用している限り、これらのDNSレコードをそのままにしておきます。

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

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

DNSレコードを設定したら、サポートチケットを送信して、カスタムドメインを有効にします。

サポートチケットで、次を指定します:

カスタムドメイン名。
バンドルされたcontainer registryとKubernetes向けGitLabエージェントサーバーにカスタムドメインが必要かどうか。例えば、registry.company.com、kas.company.com。

カスタム認証局

GitLab Dedicatedインスタンスが、プライベートまたは内部認証局（CA）からの証明書を使用して外部サービスに接続する場合、そのCAをインスタンスに追加する必要があります。デフォルトでは、GitLabは、パブリックに認識された認証局のみを信頼し、信頼できないソースからの証明書を持つサービスへの接続を拒否します。

たとえば、次のものに接続するために認証局を追加する必要がある場合があります:

内部Webhookエンドポイント
プライベートコンテナレジストリ

スイッチボードを使用したカスタム証明書の追加

スイッチボードにサインインします。
ページの上部にある設定を選択します。
Custom certificates（カスタム証明書）を展開します。
+ Add Certificate（+ 証明書を追加）を選択します。
証明書をテキストボックスに貼り付けます。
保存を選択します。
ページの上部までスクロールし、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

サポートリクエストを使用したカスタム証明書の追加

スイッチボードを使用してカスタム証明書を追加できない場合は、サポートチケットを開き、この変更をリクエストするためにカスタムパブリック証明書ファイルを添付できます。

AWS PrivateLink接続

受信プライベートリンク

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

以下を検討してください:

同じAWSリージョン内にのみプライベートリンクを作成できます。VPCが、GitLab Dedicatedインスタンスがデプロイされているリージョンと同じリージョンにあることを確認してください。

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

サポートチケットを開きます。サポートチケットの本文に、AWSアカウントでVPCエンドポイントを確立しているAWSユーザーまたはロールのIAMプリンシパルを含めます。IAMプリンシパルは、IAMロールプリンシパルまたはIAMユーザープリンシパルである必要があります。GitLab Dedicatedは、これらのIAMプリンシパルをアクセス制御に使用します。これらのIAMプリンシパルのみが、サービスへのエンドポイントを設定できます。
IAMプリンシパルが許可リストに登録されると、GitLabはEndpoint Serviceを作成し、サポートチケットでService Endpoint Nameを伝えます。サービス名は、サービスエンドポイントの作成時にAWSによって生成されます。
- GitLabは、プライベートDNS名のドメイン検証を処理するため、VPC内のテナントインスタンスドメイン名のDNS解決がプライベートリンクエンドポイントに解決されます。
- エンドポイントサービスは、2つのアベイラビリティーゾーンで利用できます。これらのアベイラビリティーゾーンは、オンボーディング中に選択したゾーン、または指定しなかった場合は、ランダムに選択された2つのゾーンです。
独自のAWSアカウントで、次の設定を使用して、VPCにEndpoint Interfaceを作成します:
- Service Endpoint Name: サポートチケットでGitLabから提供された名前を使用します。
- Private DNS names enabled: yes。
- Subnets: 一致するすべてのサブネットを選択します。
エンドポイントを作成したら、オンボーディング中に提供されたインスタンスのURLを使用して、トラフィックをパブリックインターネット経由で送信せずに、VPCからGitLab Dedicatedインスタンスに安全に接続します。

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

受信プライベートリンクを使用してGitLab Dedicatedインスタンスに接続すると、プライベートネットワークを介してDNSが自動的に解決されるのは、mainインスタンスのURLのみです。

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

前提要件:

GitLab Dedicatedインスタンスの受信プライベートリンクを設定しました。
AWSアカウントでRoute 53プライベートホストゾーンを作成する権限があります。

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

AWSコンソールで、gitlab-dedicated.comのプライベートホストゾーンを作成し、プライベートリンク接続を含むVPCに関連付けます。
プライベートホストゾーンを作成したら、次のDNSレコードを追加します（exampleをインスタンス名に置き換えます）:
1. GitLab DedicatedインスタンスのAレコードを作成します:
  - VPCエンドポイントにエイリアスとして解決するように、完全なインスタンスドメイン（たとえば、example.gitlab-dedicated.com）を設定します。
  - アベイラビリティーゾーン参照を含まないVPCエンドポイントを選択します。
2. KASとレジストリの両方のCNAMEレコードを作成して、GitLab Dedicatedインスタンスドメイン（example.gitlab-dedicated.com）に解決します:
  - 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アドレスの変更に対して堅牢です。

トラブルシューティング

エラー: `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）のアベイラビリティーゾーンID（AZ ID）が必要です。
Dedicatedへのオンボーディング中にAZを指定しなかった場合、GitLabは両方のAZ IDをランダムに選択します。AZ IDは、プライマリリージョンとセカンダリリージョンの両方のスイッチボードの概要ページに表示されます。
GitLab Dedicatedは、送信プライベートリンク接続の数を10に制限しています。

スイッチボードを使用した送信プライベートリンクの追加

前提要件:

GitLab Dedicatedで利用できるように、内部サービス用のエンドポイントサービスを作成します。
Dedicatedインスタンスがデプロイされているアベイラビリティーゾーン（AZ）で、エンドポイントサービスのネットワークロードバランサー（NLB）を設定します。次のいずれかの操作を行います:
- 設定されたAZを使用します。AZ IDは、スイッチボードの概要ページに表示されます。
- リージョンのすべてのAZでNLBを有効にします。
GitLab Dedicatedがエンドポイントサービスへの接続に使用するロールのARNを、Endpoint Serviceの[許可されたプリンシパル]リストに追加します。このARNは、送信プライベートリンクIAMプリンシパルの下のスイッチボードにあります。詳細については、権限の管理を参照してください。
（推奨）GitLab Dedicatedが1回の操作で接続できるように、Acceptance requiredをNoに設定します。可能に設定した場合は、開始後に手動で接続を承認する必要があります。
Acceptance requiredをYesに設定した場合、スイッチボードはリンクが承認されたタイミングを正確に判断できません。リンクを手動で承認すると、次回の定期メンテナンスまで、ステータスが保留中ではなく有効として表示されます。メンテナンス後、リンクステータスが更新され、接続済みとして表示されます。
エンドポイントサービスが作成されたら、サービス名と、プライベートDNSを有効にしたかどうかを書き留めます。

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

スイッチボードを使用した送信プライベートリンクの削除

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

サポートリクエストを使用した送信プライベートリンクの追加

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

次に、GitLabは、提供されたサービス名に基づいて、必要なエンドポイントインターフェイスを作成するようにテナントインスタンスを構成します。テナントインスタンスから行われた一致する送信接続は、PrivateLinkを介してVPCに転送されます。

トラブルシューティング

送信Private Linkの設定後に接続の確立で問題が発生した場合は、AWSインフラストラクチャのいくつかのものが問題の原因となっている可能性があります。確認すべき具体的な事項は、修正しようとしている予期しない動作によって異なります。確認すべき事項は次のとおりです:

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

Private Hosted Zone

Private Hosted Zone（PHZ）は、GitLab Dedicatedインスタンスのネットワークで解決されるカスタムDNSエイリアス（CNAME）を作成します。

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

複数のサービスに接続するためにリバースプロキシを実行する場合など、単一のエンドポイントを使用する複数のDNS名またはエイリアスを作成する。
パブリックDNSで検証できないプライベートドメインを使用する。

PHZは通常、リバースPrivateLinkで使用され、AWS生成のエンドポイント名の代わりに読み取り可能なドメイン名を作成します。たとえば、alpha.beta.tenant.gitlab-dedicated.comをvpce-0987654321fedcba0-k99y1abc.vpce-svc-0a123bcd4e5f678gh.eu-west-1.vpce.amazonaws.comの代わりに使用できます。

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

Private Hosted Zoneを変更すると、これらのレコードを使用するサービスが最大5分間中断される可能性があります。

PHZドメイン構造

GitLab Dedicatedインスタンスのドメインをエイリアスの一部として使用する場合は、メインドメインの前に2つのサブドメインを含める必要があります:

最初のサブドメインは、PHZの名前になります。
2番目のサブドメインは、エイリアスのレコードエントリになります。

例:

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

GitLab Dedicatedインスタンスドメインを使用しない場合でも、以下を指定する必要があります:

Private Hosted Zone（PHZ）名
形式phz-entry.phz-name.comのPHZエントリ

Dedicatedテナント内でドメインを作成するときにパブリックDNSドメインのシャドウイングを防ぐには、PHZエントリのパブリックドメインの下に少なくとも2つの追加のサブドメインレベルを使用します。たとえば、テナントがtenant.gitlab-dedicated.comでホストされている場合、PHZエントリは少なくともsubdomain1.subdomain2.tenant.gitlab-dedicated.comにする必要があります。または、customer.comを所有している場合は、少なくともsubdomain1.subdomain2.customer.comにする必要があります（subdomain2はパブリックドメインではありません）。

スイッチボードでPrivate Hosted Zoneを追加する

Private Hosted Zoneを追加するには、次の手順に従います:

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

サポートチケットでPrivate Hosted Zoneを追加する

スイッチボードを使用してPrivate Hosted Zoneを追加できない場合は、サポートチケットを開き、送信Private Linkのエンドポイントサービスに解決する必要があるDNS名のリストを提供できます。リストは必要に応じて更新できます。

IP許可リスト

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

スイッチボードを使用してIP許可リストを構成および管理するか、スイッチボードが利用できない場合はサポートチケットを送信します。

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

許可リストにIPアドレスを追加するには、次の手順に従います:

スイッチボードにサインインします。
ページの上部にある設定を選択します。
IP allowlist（IP許可リスト）を展開し、IP allowlist（IP許可リスト）を選択して、IP許可リストページに移動します。
IP許可リストを有効にするには、縦方向の省略記号（）を選択し、有効を選択します。
次のいずれかを実行します:
- 単一のIPアドレスを追加するには、次の手順に従います:
1. Add IP address（IPアドレスの追加）を選択します。
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許可リスト）を展開し、IP allowlist（IP許可リスト）を選択して、IP許可リストページに移動します。
次のいずれかを実行します:
- 単一のIPアドレスを削除するには、次の手順に従います:
1. 削除するIPアドレスの横にあるごみ箱アイコン（）を選択します。
2. Delete IP address（IPアドレスの削除）を選択します。
- 複数のIPアドレスを削除するには、次の手順に従います:
1. 削除するIPアドレスのチェックボックスを選択します。
2. 現在のページ上のすべてのIPアドレスを選択するには、ヘッダー行のチェックボックスを選択します。
3. IPアドレステーブルの上にある削除を選択します。
4. 削除を選択して確定します。
ページの上部で、変更をすぐに適用するか、次回のメンテナンス期間中に適用するかを選択します。

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

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

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

GitLabをOpenID Connectアイデンティティプロバイダーとして使用するには、OpenID Connect検証エンドポイントへのインターネットアクセスが必要です。

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

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

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

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

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

IP許可リストを維持しながらSCIMを有効にするには、次の手順に従います:

サポートチケットで、SCIMエンドポイントがインターネットに接続できるようにリクエストします。

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

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

Bring your own domain（BYOD）

DNSレコードの設定

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

カスタム認証局

スイッチボードを使用したカスタム証明書の追加

サポートリクエストを使用したカスタム証明書の追加

AWS PrivateLink接続

受信プライベートリンク

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

トラブルシューティング

エラー: Service name could not be verified

送信プライベートリンク

スイッチボードを使用した送信プライベートリンクの追加

スイッチボードを使用した送信プライベートリンクの削除

サポートリクエストを使用した送信プライベートリンクの追加

トラブルシューティング

Private Hosted Zone

PHZドメイン構造

スイッチボードでPrivate Hosted Zoneを追加する

サポートチケットでPrivate Hosted Zoneを追加する

IP許可リスト

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

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

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

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

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

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