正式なドキュメントは英語版であり、この日本語訳は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つが外部で共有されていない状態である必要があります。

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

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

制限付きアクセスをオンにすると、グループ階層外のグループを招待できないようにする設定が自動的にオンになります。この設定により、予期せずに新しい請求対象ユーザーが追加されて超過料金が発生してしまう事態を防ぐことができます。

必要に応じて、グループとそのサブグループのプロジェクト共有を個別に構成できます。

SAML、SCIM、およびLDAPによるプロビジョニングの動作

この機能の可用性は、機能フラグによって制御されます。詳細については、履歴を参照してください。

制限付きアクセスが有効になっていて、サブスクリプションのコード行が利用できない場合、SAML、SCIM、またはLDAPを介してプロビジョンされたユーザーには、設定されたアクセスレベルの代わりに最小アクセスロールが割り当てられます。この動作により、GitLab.comおよびGitLab Self-Managed Ultimateで、請求対象のコード行を消費せずに、同期を続行できます。

最小アクセスロールを持つユーザーは、認証してグループにアクセスできますが、制限された権限があります。コード行が利用可能になると、ユーザーは意図したアクセスレベルにプロモートできるようになります。請求対象ロールを持つ既存のユーザーは、この動作の影響を受けません。

コード行の使用状況を表示し、最小アクセスを持つユーザーを管理できます。

既知の問題

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

  • 請求対象ユーザーの数は、次の場合はまだ超過する可能性があります:
    • SAML、SCIM、またはLDAPを使用して新しいメンバーを追加し、サブスクリプションのシート数を超えた場合。最小アクセスのフォールバック機能が有効になっている場合、ユーザーはブロックされる代わりに最小アクセスを割り当てられます。
    • 管理者アクセス権を持つ複数のユーザーが、同時にメンバーを追加する場合。
    • 新しい請求対象ユーザーが招待の承認を遅らせている場合。ユーザーを招待した場合、招待されたユーザーが承認するまでは請求対象シートを消費しません。承認が遅れている間に、他のユーザーを招待して追加することができます。ただし、承認を遅らせていたユーザーが最終的に承認した時点で請求対象シートが消費されるため、すでにシートの上限に達している場合は超過が発生する可能性があります。
  • 現在のサブスクリプションよりも少ないユーザー数でGitLabセールスチームを通じてサブスクリプションを更新すると、超過料金が発生します。この料金を回避するには、更新が開始される前に追加のユーザーを削除してください。たとえば、20人のユーザーがいて、15人のユーザーに対してサブスクリプションを更新する場合、5人の追加ユーザーに対して超過料金が請求されます。

さらに、制限付きアクセスによって、標準の超過料金が発生しないフローがブロックされる場合があります:

  • 請求対象ロールに更新または追加されたサービスボットが誤ってブロックされる。
  • メールを介して既存の請求対象ユーザーを招待または更新すると、予期せずにブロックされる。

ユーザー制限

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

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

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

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

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

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

ユーザー制限を設定する

前提条件:

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

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

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

ユーザー制限を削除する

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

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

前提条件:

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

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

  1. 右上隅で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 新規登録の制限を展開します。
  4. User capから数値を削除します。
  5. 変更を保存を選択します。

ユーザー上限から制限付きアクセスへの変更

ユーザー上限から制限付きアクセスに変更すると、保留中のすべてのメンバー(承認待ちのメンバーと招待されたメンバーの両方)が自動的に削除されます。ユーザーがメンバーとして承認されるようにするには、制限付きアクセスを有効にする前に、保留中のメンバーを承認または削除する必要があります。

パスワードの複雑さの要件を変更する

デフォルトでは、ユーザーパスワードに設定されている要件は限定的です。最小文字数を増やしたり、特定の種類の文字を必須にしたりするなど、要件を変更できます。

パスワード要件を変更しても、既存ユーザーのパスワードには影響しません。変更後の複雑性要件が適用されるのは、次の場合のみです:

  • 新しいユーザーがアカウントを作成するとき。
  • 既存のユーザーがパスワードをリセットするとき。

パスワードの複雑さの要件を変更するには、次の手順に従います:

  1. 右上隅で、管理者を選択します。

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

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

  4. 複雑さの要件を変更します:

    設定説明
    パスワードの最小文字数必要な最小文字数を設定します。8文字以上128文字以下にする必要があります。
    数字が必要パスワードに少なくとも1つの数字(0-9)が含まれている必要があります。PremiumおよびUltimateのみです。
    大文字が必要パスワードに少なくとも1つの大文字(A-Z)が含まれている必要があります。PremiumおよびUltimateのみです。
    小文字が必要パスワードに少なくとも1つの小文字(a-z)が含まれている必要があります。PremiumおよびUltimateのみです。
    記号が必要パスワードに少なくとも1つの記号が含まれている必要があります。PremiumおよびUltimateのみです。
  5. 変更を保存を選択します。

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

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

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

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

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

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

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

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

メールドメイン許可リストまたは拒否リストを作成するには、次の手順に従います:

  1. 右上隅で、管理者を選択します。

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

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

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

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

    ファイルアップロードまたは手動で拒否リストを入力するオプションを備えたドメイン拒否リストの設定。

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

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

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

ロールのプロモートに対する管理者の承認を有効にする

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

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

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

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

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

前提条件:

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

ロールのプロモートに対する承認を有効にするには、次の手順に従います:

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