正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

サインアップの制限

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

サインアップに対して、次の制限を適用できます:

  • 新規サインアップを無効にします。
  • 新規サインアップに管理者の承認を必須にします。
  • ユーザーメールの確認を要求します。
  • 特定のメールドメインを使用したサインアップを許可または拒否します。

新規サインアップを無効にします

デフォルトでは、GitLabドメインにアクセスするすべてのユーザーがアカウントにサインアップできます。公開されているGitLabインスタンスを運用しているお客様は、一般ユーザーがアカウントにサインアップすることを想定していない場合は、新規サインアップを無効にすることを強くお勧めします。GitLab Dedicatedの場合、インスタンスのプロビジョニング時に、新しいサインアップはデフォルトで無効になっています。

サインアップを無効にするには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. サインアップは有効ですチェックボックスをオフにして、変更を保存を選択します。

次のコマンドを実行して、Railsコンソールで新しいサインアップを無効にすることもできます:

::Gitlab::CurrentSettings.update!(signup_enabled: false)

新規サインアップに管理者の承認を必須にします

この設定は、新しいGitLabインスタンスではデフォルトで有効になっています。この設定が有効になっている場合、GitLabドメインにアクセスし、登録フォームを使用して新しいアカウントにサインアップするユーザーは、アカウントの使用を開始する前に、管理者による明示的な承認を受ける必要があります。サインアップが有効になっている場合にのみ適用されます。

新規サインアップに管理者の承認を必須にするには、次のようにします:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. 新しいサインアップには管理者の承認が必要チェックボックスを選択し、変更を保存を選択します。

管理者がこの設定を無効にすると、承認待ち状態のユーザーはバックグラウンドジョブで自動的に承認されます。

この設定は、LDAPまたはOmniAuthユーザーには適用されません。OmniAuthまたはLDAPを使用してサインアップする新しいユーザーの承認を適用するには、OmniAuth設定またはLDAP設定で、block_auto_created_userstrueにリセットします。ユーザー上限を使用して、新しいユーザーの承認を適用することもできます。

メールアドレスの確認

サインアップ中に確認メールを送信し、ユーザーがサインインする前にメールアドレスを確認することを要求できます。

新しいサインアップに使用されるメールアドレスの確認を適用するには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. メールの確認設定確認設定]で、ハードを選択します。

次の設定を使用できます:

  • ハード - サインアップ中に確認メールを送信します。新しいユーザーは、サインインする前にメールアドレスを確認する必要があります。
  • ソフト - サインアップ中に確認メールを送信します。新しいユーザーはすぐにサインインできますが、3日以内にメールを確認する必要があります。3日後、ユーザーはメールを確認するまでサインインできません。
  • オフ - 新しいユーザーは、メールアドレスを確認しなくてもサインアップできます。

制限付きアクセスをオンにする

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed

制限付きアクセスを使用すると、超過料金を防げます。超過料金は、サブスクリプションのライセンスが付与された請求対象ユーザー数を超えた場合に発生し、次回の四半期ごとの調整で支払う必要があります。

制限付きアクセスをオンにすると、インスタンスでは、サブスクリプションに残りのライセンスされたシートがない場合、新しい請求対象ユーザーを追加できません。

前提要件:

  • 管理者である必要があります。

制限付きアクセスをオンにするには、次の手順に従います:

  1. 左側のサイドバーで、設定 > 一般を選択します。
  2. 新規登録の制限を展開します。
  3. シートの管理で、制限されたアクセスを選択します。

既知のイシュー

制限付きアクセスをオンにすると、次の既知のイシューが発生し、超過が発生する可能性があります:

  • 請求対象ユーザー数が超過する可能性はまだあります:
    • SAML、SCIM、またはLDAPを使用して新しいメンバーを追加し、サブスクリプションのシート数を超えた場合。
    • 管理者アクセス権を持つ複数のユーザーが、同時にメンバーを追加する。
    • 新しい請求対象ユーザーが招待の承諾を遅らせている場合。
  • 現在のサブスクリプションよりも少ないユーザー数でGitLabセールスチームを通じてサブスクリプションを更新すると、超過料金が発生します。この料金を回避するには、更新が開始される前に追加のユーザーを削除してください。たとえば、20人のユーザーがいて、15人のユーザーに対してサブスクリプションを更新する場合、5人の追加ユーザーに対して超過料金が請求されます。

ユーザー上限

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

ユーザー上限は、管理者による承認なしにサブスクリプションにサインアップまたは追加できる請求対象ユーザーの最大数です。ユーザー上限に達すると、サインアップまたは追加されたユーザーは、管理者による承認を受ける必要があります。ユーザーがアカウントを使用できるのは、管理者によって承認された後のみです。

管理者がユーザー上限を引き上げるか削除すると、承認待ちのユーザーは自動的に承認されます。

[個々のグループのユーザー上限を設定]することもできます。

インスタンスがLDAPまたはOmniAuthを使用している場合、新しいサインアップに対する管理者の承認が有効または無効になっていると、Railsの設定の変更により、ダウンタイムが発生する可能性があります。ユーザー上限を設定して、新しいユーザーの承認を適用できます。

ユーザー上限を設定する

ユーザー上限を設定して、管理者の承認なしでサインアップできるユーザー数を制限します。

請求対象ユーザーの数は1日に1回更新されます。ユーザー上限は、上限を超えた後に遡ってのみ適用される場合があります。上限が現在の請求対象ユーザー数よりも低い値(1など)に設定されている場合、上限はすぐに有効になります。

前提要件:

  • 管理者である必要があります。

ユーザー上限を設定するには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. User cap(ユーザー上限)フィールドに数値を入力するか、無制限にする場合は空白のままにします。
  5. 変更を保存を選択します。

ユーザー上限を削除する

管理者の承認なしにサインアップできる新しいユーザーの数が制限されないように、ユーザー上限を削除します。

ユーザー上限を削除すると、承認待ちのユーザーは自動的に承認されます。

前提要件:

  • 管理者である必要があります。

ユーザーキャパシティを削除するには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. User cap(ユーザー上限)から数値を削除します。
  5. 変更を保存を選択します。

パスワードの最小文字数制限

GitLab UIを使用して、ユーザーがパスワードに含める必要のある最小文字数を変更できます。

パスワードの複雑さの要件

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

デフォルトでは、ユーザーパスワードの唯一の要件は[パスワードの最小文字数(#minimum-password-length-limit)です。追加の複雑さの要件を追加できます。パスワードの複雑さの要件の変更は、新しいパスワードに適用されます:

  • サインアップする新しいユーザーの場合。
  • パスワードをリセットする既存のユーザーの場合。

既存のパスワードは影響を受けません。パスワードの複雑さの要件を変更するには、次のようにします:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. パスワードの最小文字数で、追加のパスワードの複雑さの要件を選択します。数値、大文字、小文字、および記号を要求できます。
  5. 変更を保存を選択します。

特定のメールドメインを使用したサインアップの許可または拒否

ユーザーのサインアップに使用できるメールドメインの包括的または排他的なリストを指定できます。

これらの制限は、外部ユーザーからのサインアップ中にのみ適用されます。管理者は、許可されていないドメインを使用して、管理者パネルからユーザーを追加できます。ユーザーは、サインアップ後にメールアドレスを許可されていないドメインに変更することもできます。

許可リストメールドメイン

特定のドメインリストに一致するメールアドレスを使用してサインアップする場合にのみ、ユーザーを制限できます。

拒否リストメールドメイン

特定のドメインのメールアドレスを使用する場合、ユーザーがサインアップするのをブロックできます。これにより、悪意のあるユーザーが使い捨てのメールアドレスでスパムアカウントを作成するリスクを軽減できます。

メールドメイン許可リストまたは拒否リストを作成する

メールドメイン許可リストまたは拒否リストを作成するには:

  1. 左側のサイドバーの下部で、管理者を選択します。

  2. 設定 > 一般を選択します。

  3. 新規登録の制限を展開します。

  4. 許可リストの場合、リストを手動で入力する必要があります。拒否リストの場合、リストを手動で入力するか、リストエントリを含む.txtファイルをアップロードできます。

    許可リストと拒否リストはどちらもワイルドカードを受け入れます。たとえば、*.company.comを使用してすべてのcompany.comサブドメインを受け入れるか、*.ioを使用して.ioで終わるすべてのドメインをブロックできます。ドメインは、空白、セミコロン、カンマ、または改行で区切る必要があります。

    ファイルをアップロードするか、拒否リストを手動で入力するオプションを含むドメイン拒否リスト設定。

LDAPユーザーフィルターを設定する

LDAPサーバー上のLDAPユーザーのサブセットに対して、GitLabアクセスを制限できます。

詳細については、LDAPユーザーフィルターの設定に関するドキュメントを参照してください。

ロールプロモーションの管理者承認を有効にする

  • プラン: Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

既存のユーザーがプロジェクトまたはグループ内で請求対象ロールにプロモートされるのを防ぐには、ロールプロモーションに対する管理者承認を有効にします。次に、[管理者の承認を保留しています]のプロモーションリクエストを承認または拒否できます。

  • 管理者がグループまたはプロジェクトにユーザーを追加する場合:

    • 新しいユーザーロールが請求対象の場合、そのユーザーに対する他のすべてのメンバーシップリクエストが自動的に承認されます。
    • 新しいユーザーロールが請求対象でない場合、そのユーザーに対する他のリクエストは、管理者の承認まで保留のままになります。
  • 管理者でないユーザーがグループまたはプロジェクトにユーザーを追加する場合:

    • ユーザーがどのグループまたはプロジェクトにも請求対象ロールを持っておらず、請求対象ロールに追加またはプロモートされた場合、そのリクエストは[管理者の承認まで保留になります]。
    • ユーザーが既に請求対象ロールを持っている場合、管理者の承認は必要ありません。

前提要件:

  • 管理者である必要があります。

ロールプロモーションの承認を有効にするには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. シートの管理セクションで、ロールの昇格を承認するを選択します。