GitLab Dedicatedの設定
GitLab DedicatedはシングルテナントのSaaSソリューションで、GitLabによって完全に管理、ホスティングされています。詳細はサブスクリプションページをご覧ください。
このページの説明に従ってください：
- GitLab Dedicatedインスタンスのオンボーディングと初期設定。
- 利用可能な機能の有効化と設定の更新を含む、GitLab Dedicatedインスタンスの設定。
SaaS環境で制御されていないGitLabアプリケーションの機能は、管理パネルを使って設定することができます。
SaaS環境設定の例としては、gitlab.rb の設定やShell、Railsコンソール、PostgreSQLコンソールへのアクセスがあります。これらの環境設定はテナントが変更することはできません。GitLab専属エンジニアも、ガラスが割れるような状況を除いて、テナント環境に直接アクセスすることはできません。
オンボーディング
GitLab Dedicated環境の新規作成を依頼するには、以下の情報をアカウントチームに提供する必要があります：
- 想定されるユーザー数
- 希望するプライマリージョンデータを保存するAWSのプライマリーリージョン（サポートされていないリージョンのリストに注意してください）。
- 希望のセカンダリーリージョンデータを保存するセカンダリAWSリージョン。このリージョンは、災害時に GitLab Dedicated インスタンスを復旧するために使用されます。
- 希望のバックアップリージョン：データのプライマリバックアップが複製されるAWSリージョン。これはプライマリまたはセカンダリのリージョンと同じでも異なっていてもかまいません。
- 希望するインスタンスのサブドメイン：GitLab Dedicatedインスタンスのメインドメインは
gitlab-dedicated.comです。インスタンスにアクセスするサブドメイン名を選択します（例：customer_name.gitlab-dedicated.com）。 - 初期ストレージ：リポジトリの初期ストレージサイズ（GB）。
- PrivateLink のアベイラビリティゾーン ID：環境にPrivateLink接続（インバウンドまたはアウトバウンド）を後で追加する予定で、接続が特定のアベイラビリティゾーンで利用可能であることが必要な場合、オンボーディング中に最大2つのアベイラビリティゾーンIDを指定する必要があります。指定がない場合、GitLabは接続が利用可能な2つのアベイラビリティゾーンIDをランダムに選択します。
- 暗号化されたAWSサービスのKMSキー（その機能を使用している場合）。
メンテナンスウィンドウ
オンボーディングの際に、GitLabがすべてのテナントインスタンスに対して定期的なメンテナンスとアップグレードのオペレーションを実行するために使用する週1回4時間の時間枠の希望も指定する必要があります。
標準的な勤務時間外に実行される定期メンテナンスウィンドウを利用できます：
- APAC：水曜日午後1時～午後5時（UTC
- EU火曜日午前1時～午前5時（UTC
- AMERオプション1：火曜日午前7時～午前11時（UTC
- AMERオプション2：日曜日午後9時～月曜日午前1時（UTC
以下の注意事項をご確認ください：
- Dedicatedインスタンスは、メンテナンスウィンドウの全期間にわたってダウンすることはありません。コンピュートリソースがアップグレードされた後に再起動する間に、わずかなダウンタイム（数十秒程度）が発生することがあります。ダウンタイムが発生する場合は、通常、メンテナンス・ウィンドウの前半に発生します。この間、長時間接続が中断される可能性があります。これを軽減するために、クライアントは自動回復や再試行などの戦略を実装する必要があります。メンテナンスウィンドウの間に長いダウンタイムが発生することは稀であり、GitLabはより長いダウンタイムが予想される場合に通知を提供します。
- 予定されたメンテナンスウィンドウ中にパフォーマンスの低下やダウンタイムが発生した場合、システムSLAへの影響はカウントされません。
- 毎週予定されているメンテナンスウィンドウは、同じ週内の別のウィンドウに延期することができます。このオプションは、少なくとも1週間前に担当のカスタマーサクセスマネージャーと合意する必要があります。
- 毎週の定期メンテナンスウィンドウは、緊急メンテナンスとは異なります。
緊急メンテナンス
プラットフォームの停止、劣化、または緊急アクションを必要とするセキュリティイベントが発生した場合、緊急変更プロセスに従って緊急メンテナンスが実施されます。
緊急メンテナンスは、GitLabがDedicatedテナントインスタンスで緊急アクションを実行する必要がある場合に緊急に開始されます。お客様とのコミュニケーションは、メンテナンスを開始する前にベストエフォートベースで提供され、緊急アクションが実行された後に完全なコミュニケーションが行われます。
例えば、GitLabのS1の脆弱性にアドレスするために重要なセキュリティプロセスが開始された場合、GitLabを脆弱性のないバージョンにアップグレードするために緊急メンテナンスが実行され、それはスケジュールされたメンテナンスウィンドウの外で発生する可能性があります。緊急メンテナンスの延期は不可能です。なぜなら、同じプロセスを既存のすべてのDedicated顧客に適用する必要があり、Dedicatedテナントインスタンスの安全性と可用性を確保することが最大の関心事だからです。
設定の変更
GitLab Dedicatedインスタンスの設定を変更または更新するには、サポートチケットを開いてリクエストしてください。オンボーディング時に指定したオプション、または以下のオプション機能の設定変更をリクエストできます。
設定変更リクエストの処理にかかる時間は、GitLabハンドブックに記載されています。
暗号化されたデータ(BYOK)
GitLabのデータをAWS KMSキーで暗号化することができます。GitLab Dedicatedは、AWS-managed key material（AWS_KMSオリジンタイプ）の鍵のみをサポートしています。
KMSキーの作成と管理方法については、AWS KMSのドキュメントを参照してください。
GitLab Dedicatedでは、2つの方法でKMSキーを使うことができます：
- 一つのKMSキーで全てのサービスに対応
- サービスごとのKMSキー（バックアップ、EBS、RDS、S3）
- キーはサービスごとに一意である必要はありません。
- すべてのサービスは暗号化されていなければなりません。
- この機能を選択的に有効にすることはサポートされていません。
- キーはサービスごとに一意である必要はありません。
AWS KMSのキーが、オンボーディング時に指定したプライマリ、セカンダリ、バックアップリージョンにレプリケートされていることを確認してください。
AWSでKMSキーを作成
BYOKを有効にするには、オンボーディングチケットにこの機能を使用したい旨を記入してください。GitLabはBYOKを有効にするために必要なAWSアカウントIDを提供します。
AWSアカウントIDを受け取ったら、AWSコンソールを使ってKMSキーを作成します：
-
Configure keyで、以下を選択します：- キータイプ対称
- 鍵の使用法暗号化と復号化
-
Advanced options:- キーマテリアルの原産地KMS
- 地域性マルチリージョンキー
- キーエイリアス、説明、タグの値を入力します。
- キー管理者を選択します。
- オプション。キー管理者によるキーの削除を許可または禁止します。
- Define key usage permissions]ページの[Other AWS accounts]で、GitLab AWSアカウントを追加します。
最後のページでは、KMSキーポリシーを確認します。以下の例のように、アカウントIDとユーザー名が入力されているはずです：
{
"Version": "2012-10-17",
"Id": "byok-key-policy",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrators",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:user/<CUSTOMER-USER>"
]
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion",
"kms:ReplicateKey",
"kms:UpdatePrimaryRegion"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*"
}
]
}
AWS KMS キーがオンボーディング時に指定したプライマリ、セカンダリ、バックアップリージョンにレプリケートされていることを確認してください。キーを作成したら、GitLabに各キーの対応するARNを送信し、GitLabがDedicatedインスタンスに保存されたデータを暗号化できるようにします。
インバウンドプライベートリンク
AWS Private Linkは、AWS上のVPCにいるユーザーやアプリケーションが、公開インターネットを経由することなくGitLab Dedicatedエンドポイントにセキュアに接続することを可能にします。
Inbound Private Linkを有効にするには、以下の手順に従います：
- サポートチケットの本文に、AWS アカウントで VPC エンドポイントを確立している AWS 組織内の AWS ユーザーまたはロールの IAM Principal を記載します。GitLab DedicatedはこのIAM Principalをアクセス制御に使用します。このIAMプリンシパルは、サービスへのエンドポイントを設定できる唯一のIAMプリンシパルです。
- IAMプリンシパルが許可リストに登録された後、GitLabはエンドポイントサービスを作成し、サポートチケットで
Service Endpoint Name。サービス名はサービスエンドポイントの作成時にAWSによって生成されます。- GitLabは非公開DNS名のドメイン検証を処理し、VPC内のテナントインスタンスドメイン名のDNS解決がPrivateLinkエンドポイントに解決されるようにします。
- GitLabは最初のオンボーディングで指定したアベイラビリティゾーンでエンドポイントサービスを利用できるようにします。アベイラビリティゾーンを指定しなかった場合、GitLabはランダムにアベイラビリティゾーンIDを選択します。
- 自分のAWSアカウントで、以下の設定でVPCにEndpoint Interfaceを作成します：
- Service Endpoint Name: GitLabがサポートチケットで提供した名前を使用します。
- 非公開DNS名を有効にする: はい。
- サブネット：一致するサブネットをすべて選択します。
- エンドポイントを作成したら、オンボーディング中に提供されたインスタンスURLを使用して、公開インターネットを経由せずに、VPCからGitLab Dedicatedインスタンスにセキュアに接続します。
アウトバウンドプライベートリンク
アウトバウンドプライベートリンクは、GitLab専用インスタンスがAWS上のVPCで稼働しているサービスと安全に通信することを可能にします。このタイプの接続では、対象となるサービスがVPCで稼働している場所でWebhookを実行したり、プロジェクトやリポジトリをインポートしたりミラーリングしたり、その他GitLabの機能を使用して非公開サービスにアクセスしたりすることができます。
アウトバウンドプライベートリンクを有効にするには：
- サポートチケットで、GitLabはあなたのエンドポイントサービスに接続するIAMロールARNを提供します。このARNをあなた側のallowlistに追加することで、エンドポイントサービスへの接続を制限することができます。
- GitLab 専用の内部サービスを利用できるエンドポイントサービスを作成します。関連する
Service Endpoint Nameをサポートチケットに記入してください。 - Endpointサービスを作成する際、GitLabにサービスの検証済み非公開DNS名を提供する必要があります。オプションとして、GitLab Dedicatedが他のエイリアスを経由してサービスに到達することを望む場合、Private Hosted Zone(PHZ) エントリのリストを指定することができます。このオプションを使用すると、GitLabは検証されたプライベートDNS名にエイリアスされたDNS名を持つプライベートホステッドゾーンを設定します。この機能を有効にするには、サポートチケットでGitLabにPHZエントリーのリストを提供する必要があります。テナント環境でPHZが作成された後、提供されたレコードのDNS解決はPrivateLinkエンドポイントに正しく解決されます。
- その後、GitLabはテナントインスタンスを設定し、提供したサービス名に基づいて必要なエンドポイントインターフェースを作成します。テナントのGitLabインスタンスから発信されたコールは、PrivateLinkを経由してVPCに転送されます。
カスタム証明書
場合によっては、GitLab Dedicatedインスタンスが公開認証局(CA) を使って検証できない証明書を公開しているために、あなたが所有する内部サービスに到達できないことがあります。このような場合、カスタム証明書が必要になります。
GitLabがPrivateLinkを介してあなたのサービスと通信する際にカスタム証明書を追加するようリクエストするには、カスタム公開証明書ファイルをサポートチケットに添付してください。
逆PrivateLink接続の最大数
GitLab Dedicatedは逆PrivateLink接続数を10に制限しています。
IP許可リスト
GitLab Dedicatedでは、IP allowlistによってインスタンスにアクセスできるIPアドレスを制御することができます。
サポートチケットでGitLab DedicatedインスタンスにアクセスできるIPアドレスをカンマ区切りで指定します。設定が適用された後、許可リストにないIPがインスタンスにアクセスしようとすると、接続が拒否されます。
SAML
前提条件：
- GitLabに必要なデータを送信する前に、IDプロバイダーを設定する必要があります。
GitLab DedicatedインスタンスでSAMLを有効化するには：
- 必要な変更を行うには、サポートチケットにGitLabアプリケーションの希望するSAML設定ブロックを含めてください。インスタンスのSAMLを有効にするために、GitLabは最低限以下の情報を必要とします：
- IDP SSOターゲットURL
- 証明書フィンガープリントまたは証明書
- NameID 形式
- SSOログインボタンの説明
"saml": { "attribute_statements": { //optional }, "enabled": true, "groups_attribute": "", "admin_groups": [ // optional ], "idp_cert_fingerprint": "43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8", "idp_sso_target_url": "https://login.example.com/idp", "label": "IDP Name", "name_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent", "security": { // optional }, "auditor_groups": [ // optional ], "external_groups": [ // optional ], "required_groups": [ // optional ], } - GitLab がインスタンスに SAML 設定をデプロイした後、サポートチケットで通知されます。
- SAML 設定が成功したことを確認するには：
- インスタンスのログイン・ページに SSO ログイン・ボタンの説明が表示されていることを確認します。
- インスタンスのメタデータ URL (
https://INSTANCE-URL/users/auth/saml/metadata) にアクセスします。このページを使用して、ID プロバイダの設定の多くを簡略化し、設定を手動で検証することができます。
署名の要求
SAMLリクエストに署名する場合は、証明書を取得する必要があります。この証明書は自己署名することができ、任意のコモン・ネーム(CN) の所有権を公開認証局(CA)に証明する必要がないという利点があります。）SAML 要求署名を有効にすることを選択した場合、SAML を使用するには証明書署名が必要なため、以下の手動手 順を完了してから SAML を使用する必要があります。SAML リクエスト署名を有効にするには、SAMLサポートチケットにリクエスト署名を有効にしたい旨を記入してください。GitLabは、あなたが署名するための証明書署名リクエスト(CSR) 。あるいは、CSRを公開CAで署名することもできます。証明書に署名した後、GitLab は証明書とそれに関連する秘密鍵を SAML 設定のsecurity セクションに追加します。GitLabからIDプロバイダへの認証リクエストは、その後署名することができます。
SAML グループ
SAMLグループを使えば、SAMLグループメンバーシップに基づいてGitLabユーザーを設定することができます。
SAMLグループを有効にするには、サポートチケットで提供するSAML設定ブロックに必要な要素を追加します。
グループの同期
グループ同期を使うと、GitLabのマッピングされたグループにIDプロバイダのグループをまたいでユーザーを同期することができます。
グループ同期を有効にするには
アプリケーションログへのアクセス
GitLabのアプリケーションログはGitLabテナントアカウントのS3バケットに配信され、共有することができます。S3バケットに保存されたログは、1年間の保持ポリシーが完全に実施されるまで、無期限に保持されます。GitLabチームメンバーはこの極秘イシューでより詳細な情報を見ることができます：https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/483.
このバケットへの読み取り専用アクセスを得るには
- Customer Log Access」というタイトルでサポートチケットを開きます。チケットの本文に、S3 からログを取得している IAM Principal ARN（ユーザーまたはロール）のリストを記載します。
- GitLab は S3 バケットの名前を通知します。指名したユーザー/ロールは、S3バケット内の全てのオブジェクトをリストアップし、取得することができます。