目次
GroupとProjectの関係
GitLabは以下のイメージのように、GroupとProjectで構成されます。
※Owner直下のGroupはTopGroupと呼びます
通常のメンバー追加
Group membersもしくはProject membaers 画面から、メンバーを招待することができます。
左側のように:
※ここで注意する必要なのは:
Groupへ招待した場合、そのメンバーがGroupにぶら下がっている全てのSubGroupとProjectに対して、同じ権限と有効期間が与えられます。
GitLabのSSO設定及びプロビジョニング
続いて、GitLabとAzure ADのSSO設定について説明します。
大きくは以下の3つのステップになります。
Azure AD側のエンタープライズ アプリケーションの作成
GitLabとのSSO設定はギャラリーに存在しないため、独自のアプリケーションを作成します。
エンタープライズ アプリケーションの設定
以下1~3の設定を完成すれば、指定されたユーザーが指定されたGitLab TopGroupへ追加されます。
1.ユーザーとグループの割り当て
Azure ADに存在するグループの追加、もしくは個別ユーザーの追加はできます。
2.シングルサインオンの設定
設定内容の詳細は GitLab公式サイト をご参考ください。
ここで注意してほしいのは1つありまして、GitLab側TopGroupのSAML SSO設定画面に「デフォルトメンバーシップロール」があります。ユーザーは指定されたTopGroupに参加するので、前述にも説明した通り、TopGroupにぶら下がっている全てのGroupとProjectにも同じ権限が与えられます。
設定画面のイメージは以下となります。
3.ユーザー アカウントのプロビジョニング
ユーザー情報をGitLabへ同期するための設定となります、詳細は 公式サイト をご参考ください。
プロビジョニングの実行
設定完了後、プロビジョニング開始ボタンを押せばすぐに同期が始まります。
同期完了後にもプロビジョニングが定期的に自動実行されるので、ユーザーの追加/削除があれば、自動的にGitLabへ反映されます。
同期後のGitLab TopGroupのメンバーを見てみると、追加したユーザーが指定されたロール(minimal access)で同期されていることがわかりました。
メンバーをMinimal AccessロールでTopGroupへ同期後、各Group/Projectへのメンバー招待作業が必要となります。
大規模案件、もしくはプロジェクト参画メンバーの変動は多く発生する場合、手運用は大変手間かかりますので、SAML Group Links機能をご紹介したいと思います。
やり方はとても簡単で、設定手順は以下となります。
例えば:
下記イメージのように、Azure ADとGitLabとそれぞれ3つのGroupがあります。
それぞれ1対1でSAML Group Linksを設定した後、AD-SG-3とGL-SG-1もリンクしてあげますと、プロビジョニングした後、user3がGL-SG-1とGL-SG-3と2つのGroupに参加させることが可能になります。
説明は以上になりますが、いかがでしたか?SAML Group Links 機能を活用することによって、複雑なメンバー設定は自動化可能になり、運用はとても楽になります、ぜひ試してみてください。
以上。