GitLabの制限付きアクセスが進化。シート超過を防ぎ、コストを予測可能に

GitLabの制限付きアクセス機能を使えば、インスタンス管理者、グループオーナー、課金管理者は、手作業でのチェックを減らしつつ、シートコストを予測しやすくなります。この機能は大幅に改善され、シート使用量に影響を与える一般的なワークフローに対して、より完成度の高いものになりました。この更新により、IDプロバイダーによるプロビジョニング、休止ユーザーの再有効化、サインインフローに関するギャップが解消され、実際の環境で制限付きアクセスをより安心して利用できるようになります。

この記事では、制限付きアクセスの機能内容、変更点、そして有効化する方法について説明します。

制限付きアクセスとは

制限付きアクセスは、GitLab.comおよびSelf-Managedで利用できるシート制御機能です。この機能を有効にし、ライセンス対象のシートがすべて使用されている状態になると、GitLabは新たな課金対象ユーザーの追加をブロックします。

そのため、更新前に想定外のシート増加を回避し、購入済みのシート数にシート使用量をより近づけて維持できます。制限付きアクセスは、今後発生する超過を防ぐことを目的としており、既存の超過を解消するものではありません。

プロジェクトやグループへのアクセスを必要としないユーザー、たとえばOpenID Connect（OIDC）プロバイダーとしてGitLabを利用して認証するユーザーには、非課金対象の最小アクセスロールを割り当てることができます。これらのユーザーは、有料シートを消費せずに認証を継続できます。

既存の課金対象メンバーは遡って影響を受けない

制限付きアクセスは将来に向けた機能です。すでにシート上限を超えているグループやインスタンスで有効にした場合でも、GitLabは既存の課金対象メンバーをダウングレードしたり、削除したり、ブロックしたりしません。既存のメンバーシップはそのまま維持されます。すでに超過が発生している場合、管理者は課金対象メンバーの削除や追加シートの購入により、使用量を購入済みの上限内に戻す必要があります。

シート使用量がサブスクリプションの上限内に戻れば、制限付きアクセスによってその上限を超える課金対象の増加を防止できます。

IDプロバイダーとの連携が向上

今回の機能完成に向けた作業の主要な部分は、ID主導のプロビジョニングにおける制限付きアクセスの動作の改善です。

制限付きアクセスが有効で、利用可能なシートがない場合、SAML、SCIM、LDAPを通じてプロビジョニングされたユーザーは、課金対象ロールに直接追加されなくなりました。代わりに、GitLabは非課金対象の最小アクセスロールを割り当てます。これにより、即時の課金対象超過を避けながら、同期を継続できます。

この動作は、自動プロビジョニングを利用しており、集中的なID管理を維持しながらコスト管理を強化したい組織にとって特に有用です。

GitLabをOIDCプロバイダーとして利用しており、一部のユーザーがプロジェクトやグループへのアクセスではなく認証のみを必要とする場合、トップレベルグループで最小アクセスを割り当てる方法は依然として有効なパターンです。これらのユーザーは課金対象シートを消費せず、最小アクセスのみのユーザーは、シートが利用できない場合でも再有効化できます。

休止ユーザーによる見えない超過が発生しなくなる

GitLabは、設定した期間活動がないユーザーを自動的に非アクティブ化し、シートを解放できます。以前は、こうしたユーザーがOIDCまたはシングルサインオン（SSO）を通じて再度サインインすると、制限付きアクセスを回避して課金対象ユーザーとして自動的に再有効化され、ライセンスの超過が発生することがありました。

現在では、制限付きアクセスが有効で利用可能なシートがない場合、再度サインインした休止ユーザーは承認待ちの状態に置かれます。グループおよびプロジェクトのメンバーシップは保持され、シートが空いた時点で管理者が承認できます。

警告、バナー、通知がより分かりやすく

制限付きアクセスは、日常的な運用もしやすくなっています。

最近の改善により、管理者がシート上限に達する前後で何が起こるかを理解できるよう、製品内にガイダンスが直接追加されました。シナリオに応じて、以下が含まれます。

• 制限付きアクセスが有効な状態でLDAP同期、SAMLグループリンク、SCIMプロビジョニングを設定する際のコンテキストに応じた警告
• シート上限に近づいている場合と、シート上限に達した場合とで異なる製品内表示
• 有料シートが利用できないためユーザーに最小アクセスが割り当てられた際の、グループオーナーまたはインスタンス管理者へのメール通知
• 最小アクセスへのフォールバックイベントに関する監査の可視化

目的は、新たな課金対象の追加をブロックすることだけではなく、その動作を理解し管理しやすくすることです。

GitLab Self-Managedの設定キャッシュ

GitLab Self-Managedでは、パフォーマンス上の理由から、アプリケーション設定はデフォルトで60秒間キャッシュされます。

そのため、制限付きアクセスとユーザーキャップを切り替えた場合、一部のUIの変化やシート制御の動作がすぐには反映されないことがあります。キャッシュは自動的に更新され、更新が完了すれば動作は一致します。必要に応じて、管理者はキャッシュの間隔を調整できます。

詳細はアプリケーション設定キャッシュのドキュメントを参照してください。

制限付きアクセスとユーザーキャップの違い

制限付きアクセスとユーザーキャップは関連していますが、それぞれ異なる課題を解決します。

ユーザーキャップは、シートの空き状況にかかわらず、新規ユーザーを管理者またはグループオーナーが確認する承認待ちフローに置きます。一方、制限付きアクセスはライセンス対象のシート数に直接紐づいており、シートが残っていない場合にのみ新たな課金対象の追加をブロックします。

つまり、ユーザーキャップは承認の制御であり、制限付きアクセスはシート上限の制御です。

また、両方を同時に有効にすることはできません。制限付きアクセスを有効にすると、ユーザーキャップは自動的に無効化されます。GitLab.comでは、ユーザーキャップから制限付きアクセスへ切り替えると、承認待ちのメンバーにも影響する可能性があるため、変更前にドキュメント化された動作を確認することをお勧めします。

利用開始方法

制限付きアクセスは、GitLab.comおよびSelf-Managedで利用できます。

• GitLab.comでは、グループオーナーが設定 > 一般 > 権限とグループ機能 > シート制御 > 制限付きアクセスで有効にできます。
• Self-Managedでは、管理者が管理者 > 設定 > 一般 > 新規ユーザーアカウントの制限 > シート制御 > 制限付きアクセスで有効にできます。
• GitLab.comでは、トップレベルグループが外部グループと共有されている場合、制限付きアクセスは利用できません。

シートの増加をより厳密に管理し、課金に関する予期せぬ事態を減らし、プロビジョニングと再有効化のための明確な運用モデルを求めている場合は、制限付きアクセスを検討する価値があります。

リソース

• 制限付きアクセスのドキュメント
• シートの管理ドキュメント
• アプリケーション設定キャッシュのドキュメント