株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

トップ > GitLab > GitとCI/CDに関する知識ゼロのSEが、ソフトウェア開発の委託においてGitLabでリポジトリを管理するケースを考える①

GitとCI/CDに関する知識ゼロのSEが、ソフトウェア開発の委託においてGitLabでリポジトリを管理するケースを考える①

GitLab

2022/05/20　GitLabのデモ動画を作りました！このブログの末尾にリンクを張ったのでよろしければご視聴ください。
2022/08/23　一部の図の背景が透過されていて見づらかったので、修正致しました。

 

皆様こんにちは。SEの小池と申します。

今回は技術的な話を交えつつ、ソフトウェア開発の委託においてGitLabでリポジトリ管理をするケースを考える回 (多分第一回) です。

本記事の対象の方

  • 開発の委託先に、自社内のオンプレミス版 GitLab のリポジトリを使ってもらうことを検討中の方。
  • 開発の委託先と自社で一緒のリポジトリを使いたいので、リポジトリ管理できる製品を選定中の方。
  • オンプレミス版GitLabにおける "外部ユーザー (External Users)" について情報収集をなさっている方。

今回のブログのポイント

今回のブログのポイントは以下の通りです。

 

今回のポイント
  • 委託先の開発メンバーは、特別な要件が無ければ外部ユーザー (External Users) にしましょう。
  • 委託先の開発メンバーの登録方法は主に以下3通りが考えられます。
    • GitLab管理者による手動登録する。
    • GitLabの登録リクエスト機能を用いて登録する。
    • 特定のグループやプロジェクトにメールアドレスを用いて直接招待する。
  • 具体的な運用フローから各ユーザー登録方法のメリットデメリットを把握しましょう。

このブログをお読みいただくにあたっての事前ご連絡事項

  • この記事の内容はGitLabのオンプレミス版 (CEおよびEE) が対象となります。
  • この記事は具体的なシナリオに対し、筆者が考え得る実装例を記載したものです。メーカーや弊社が提唱するベストプラクティスではありません。また、実際の導入事例でもありません。似たようなケースにおける情報収集としてご利用いただけますと幸いです。

今回考えるケース

この記事では以下のケースでGitLabをどのように設定・運用するかを考えます。

  • A社はリポジトリ管理等にオンプレミス版のGitLabを使っている。
  • A社はB社に開発を委託したい。
  • 開発委託に際し、リポジトリの管理はA社の既存GitLabを使ってもらう。
  • B社の開発メンバーにはGitLabを利用する上で必要な権限のみを付与する。
  • 上記を満たすために、A社はB社が開発に必要な設定をGitLabにする必要がある。

なお、実際に "委託" には受託や請負等様々な形態がありますが、ここでは "一緒に開発する" もしくは "一部の開発をお願いする" 程度にお考え下さい。

要件と実現方法を考える

A社はB社に開発を委託するにあたり、例えば以下のような点を検討する必要があります。

  • A社のGitLabにB社がアクセスできる環境の準備
  • B社の開発メンバーのユーザー登録方法の検討 ←このブログで書く範囲
  • B社に必要なリポジトリの洗い出しとロール (アクセス権) の検討
  • B社がリポジトリにアクセスする方法の検討 (https or SSL)
  • B社にリポジトリ以外に許容する機能の検討

こういった点について考慮すべき事項などを踏まえつつ、ちょっとだけ具体的に検討していきます。なお、1点目の "A社のGitLabにB社がアクセスできる環境の準備" はインフラ環境整備なので、ここでは割愛致します。

今回の記事では上の2点目の "B社の開発メンバーのユーザー登録方法の検討" について、先述したちょっとだけ具体的なケースにおいて実装方法を考えます。

3点目以降の項目？多分次回以降に書きます！多分！！！

B社の開発メンバーのユーザー登録方法の検討

まず登録方法を検討する前に大前提として、B社の開発メンバーは基本的には 外部ユーザー (External Users) として登録しましょう。

通常のユーザーと同じように登録しても問題はありませんが、後述する閲覧できるプロジェクトやグループを考えると、外部ユーザー (External Users) として登録したほうがよりセキュリティが強化されます。
この後、先に外部ユーザー (External Users) とは何かを説明し、そのあと、実際に考えられるB社の開発メンバー登録の方法の具体的例を挙げます。

外部ユーザー (External Users) とは何か？

外部ユーザーとは、特定の内部プロジェクト (Internal Project) または 特定のプライべートプロジェクト (Private Project) にのみアクセスできるようにする際に利用するオプションです。

外部ユーザー (External Users) について、GitLab Docsには以下のようにあります。

In cases where it is desired that a user has access only to some internal or private projects, there is the option of creating External Users. This feature may be useful when for example a contractor is working on a given project and should only have access to that project.

引用元: https://docs.gitlab.com/ee/user/permissions.html#external-users

GitLab Docsから抜粋した上記の通り、本機能は今回のような開発委託において委託先の会社のメンバーをいい感じに権限制限できる機能です。
具体的に、外部ユーザーはそれ以外の一般的なユーザーと比較して、以下のような機能制限があります。(なお、こちらは前述した引用元でもご確認いただけます。)

  • アクセス可能なプロジェクト
    以下のいずれかを満たしている必要があります。
    • そのプロジェクトで明示的にメンバーになっている。
    • そのプロジェクトの親グループで明示的にメンバーになっている。
    • パブリックプロジェクト。
  • アクセス可能なグループ 及び サブグループ
    以下のいずれかを満たしている必要があります。
    • そのグループで明示的にメンバーになっている。
    • そのグループの親グループで明示的にメンバーになっている。
    • パブリックグループ。
  • 内部グループ 及び 内部プロジェクトへのアクセス不可
    デフォルト状態では内部グループと内部プロジェクトへはアクセスできません。
    これらにアクセスするには、そのグループ自体、親グループ、もしくはそのプロジェクト自体のいずれかでメンバーになる必要があります。
  • パーソナルNameSpaceがありません
    外部ユーザーがプロジェクトを作る場合は必ずグループもしくはサブグループの傘下に作成する必要があります。
  • アクセス可能なスぺニット
    パブリックのスニペット もしくは アクセス可能なプロジェクトのスニペットにのみアクセスできます。

補足: 上で 「メンバーになっている」と表記している箇所は、厳密には「Guest以上のロールを付与されたメンバーになっている」です。Premium で利用可能なロール「Minimal Access」だと上記を満たすことができません。

以下は、外部ユーザー (External Users) のデフォルトの状態 (明示的にプロジェクトやグループのメンバーになっていない状態) のアクセス可能な範囲です。

上記で×になっているところでも、明示的にメンバーになる もしくは 親グループのメンバーになりさえすればアクセス可能になります。

以上が外部ユーザー (External Users) の概要です。

ユーザー登録方法の具体的な運用例

A社のGitLab環境にB社の開発メンバーを登録するする方法を検討しましょう。
オンプレ版GitLabのユーザー登録方法は基本的に以下のいずれかになります。

  • GitLab管理者による手動作成
  • GitLabのGUIのサインイン画面からのリクエスト
  • 特定のグループやプロジェクトにメールアドレスを用いて直接招待する
  • SAML等、統合を利用したユーザーの自動生成と承認

参考: https://docs.gitlab.com/ee/user/profile/account/create_accounts.html

A社の運用ルール および A社の現行のユーザー登録方法とフローを考慮しつつ、上記からB社の開発メンバー登録方法を選択します。
それぞれ具体的な運用フローを例として挙げ、メリット/デメリットを検討してみます。
なお、上記の4点目 "SAML等、統合を利用したユーザーの自動生成と承認" については、今回のケースで利用することは考えにくいため割愛致します。

GitLab管理者による手動作成の場合

【登録フロー (例)】

  1. A社GitLab管理者がB社のPJT責任者に、GitLabユーザー登録に必要な情報を連絡する。
  2. B社のPJT責任者が開発メンバーを取りまとめ、メールアドレスとユーザー名等の必要情報をA社に提供する。
  3. A社のGitLab管理者はB社からもらった情報をもとにユーザーを作成し、B社PJT責任者に完了の旨を連絡する。
  4. B社の開発メンバーは、A社のGitLabにサインインできることを確認する。

【メリット】

  • B社の開発メンバーだけを確実に過不足なく登録できる。
  • 開発メンバーの情報をB社PJT責任者が取りまとめることで、登録内容のレベル感が統一される。
  • APIを使うことである程度自動化も可能。

【デメリット】

  • 作成するユーザー数が多い場合は、単純にA社のGitLab管理者の負担が増える。
  • E-Mailアドレス等のユーザー情報はメール等でやり取りする必要がるため、全ての処理を自動化できず多少時間がかかる可能性がある。

参考: https://docs.gitlab.com/ee/user/profile/account/create_accounts.html#create-users-in-admin-area

GitLabのGUIのサインイン画面から登録リクエストをする場合

【登録フロー (例)】

  1. A社は自社のGitLabで以下を準備をする。
    1. サインイン画面からの新規ユーザー登録リクエストが可能になるように設定する。(*1)
    2. (任意) サインインが可能なドメイン指定をする。(*2)
    3. (任意) A社のドメイン以外は全て自動で外部ユーザー (External Users) になるように設定する。(*3)
  2. 上の準備が整ったGitLab環境に対し、B社の開発メンバーは各自でA社のGitLabのサインイン画面へアクセスし、そこからユーザー登録リクエストを送信する。
  3. A社のGitLab管理者はGitLabから送られてきたリクエスト承認通知を受け取る。B社のドメインからの承認依頼だった場合は、それを承認する。(前述した任意の2点目を実施していない場合は、承認する前に外部ユーザーに指定する。)
  4. B社の社員はGitLabから送られてきた承認済の連絡を受け取り、サインインできることを確認する。

【メリット】

  • A社のGitLab管理者は承認するだけでよく、タスクが少なくて済む。
    (前述した任意の2点目を実施している場合に限る。これを設定していない場合は、外部ユーザー指定と承認の2つが必要になる。)
  • GitLab側にある登録リクエストにおいて、メールアドレスを使ったフィルタ設定 (登録リクエストの利用許可設定、自動で特定のドメイン以外を全て外部ユーザーにする設定) をつかうことで、最低限のフィルタリングと設定漏れを簡単に自動化できる。

【デメリット】

  • 登録リクエスト時点でユーザー名などを任意指定できるため、登録リクエスト時の入力に内部的なルールを設けないと、B社のメンバーの登録内容にばらつきが出る。
  • B社のメールアドレスを持つ人であれば、だれでも登録リクエストを出せる。

参考: https://docs.gitlab.com/ee/user/profile/account/create_accounts.html#create-users-on-sign-in-page
関連機能:
*1: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#disable-new-sign-ups
(GitLab Docsには無効にする手順の記載しかないため、この逆を実施して下さい。)
*2: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#allowlist-email-domains
*3: https://docs.gitlab.com/ee/user/permissions.html#setting-new-users-to-external

特定のグループやプロジェクトにメールアドレスを用いて直接招待する (A社による承認必須の場合)

【登録フロー (例)】

  1. A社は自社のGitLabで以下を準備をする。
    1. B社に渡すグループ もしくは プロジェクトを作成する。
    2. B社のPJT責任者を外部ユーザーで登録する。
    3. B社に渡すグループ もしくは プロジェクトにB社のPJT責任者をOwner もしくは Maintainerでメンバー登録する。
    4. サインイン画面からの新規ユーザー登録リクエストが可能になるように設定する。(*1)
    5. (任意) サインインが可能なドメイン指定をする。(*2)
    6. (任意) A社のドメイン以外は全て自動で外部ユーザー (External Users) になるように設定する。(*3)
  2. B社のPJT責任者は、A社からもらったGitLabのグループ もしくは プロジェクトに開発メンバーを招待する。
  3. B社の開発メンバーはGitLabから届いた招待メールにあるURLからGitLabへアクセスし、ユーザー情報の登録画面で必要情報を入力する。
  4. A社のGitLab管理者はGitLabから承認依頼メールが届いたら、承認待ちのユーザー情報を確認し、承認する。(前述した任意の2点目を実施している場合に限る。これを設定していない場合は、外部ユーザー指定と承認の2つが必要になる。)
  5. B社の開発メンバーは承認完了メールを受領したら、サインインができるか確認する。

【メリット】

  • A社のGitLab管理者は承認するだけでよく、タスクが少なくて済む。
    (前述した任意の2点目を実施している場合に限る。これを設定していない場合は、外部ユーザー指定と承認の2つが必要になる。)
  • 「B社に渡したグループ もしくは プロジェクトにメンバーとして追加し、同時にロールを決める」という後続タスクを同時処理している。

【デメリット】

  • 登録リクエスト時点でユーザー名などを任意指定できるため、登録リクエスト時の入力に内部的なルールを設けないと、B社のメンバーの登録内容にばらつきが出る。
  • 各関係者が全員タスクを持っているため、処理に多少時間がかかる可能性がある。

関連機能:
*1: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#disable-new-sign-ups
(GitLab Docsには無効にする手順の記載しかないため、この逆を実施して下さい。)
*2: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#allowlist-email-domains
*3: https://docs.gitlab.com/ee/user/permissions.html#setting-new-users-to-external

特定のグループやプロジェクトにメールアドレスを用いて直接招待する (B社主体の場合)

【登録フロー (例)】

  1. A社は自社のGitLabで以下を準備をする。
    1. B社に渡すグループ もしくは プロジェクトを作成する。
    2. B社のPJT責任者を外部ユーザーで登録する。
    3. B社に渡すグループ もしくは プロジェクトにB社のPJT責任者をOwner もしくは Maintainerでメンバー登録する。
    4. サインイン画面からの新規ユーザー登録リクエストが可能になるように設定する。(*1)
    5. サインインが可能なドメイン指定をする。(*2)
    6. A社のドメイン以外は全て自動で外部ユーザー (External Users) になるように設定する。(*3)
    7. 新規ユーザー登録時にA社のGitLab管理者による承認を不要に設定する。(*4)
  2. B社のPJT責任者は、A社からもらったGitLabのグループ もしくは プロジェクトに開発メンバーを招待する。
  3. B社の開発メンバーはGitLabから届いた招待メールにあるURLからGitLabへアクセスし、ユーザー情報の登録画面で必要情報を入力すると、自動でユーザー登録が完了する。

【メリット】

  • A社のGitLab管理者は、事前準備以外のタスクがない。
  • B社が自社用のグループに自由に開発メンバーを招待できるため、開発メンバーの追加が容易。
  • 「B社に渡したグループ もしくは プロジェクトにメンバーとして追加し、同時にロールを決める」という後続タスクを同時処理している。

【デメリット】

  • あらかじめA社とB社で「B社が登録可能なメンバー数」を決めていない場合、A社が保有するGitLabのライセンスを超過する可能性がある。
  • 登録リクエスト時点でユーザー名などを任意指定できるため、登録リクエスト時の入力に内部的なルールを設けないと、B社のメンバーの登録内容にばらつきが出る。
  • この例は登録と承認を自動化しているため、B社のメンバーがユーザー登録画面でユーザー情報を間違えて入力した場合、修正はA社のGitLab管理者にしかできない。

関連機能:
*1: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#disable-new-sign-ups
(GitLab Docsには無効にする手順の記載しかないため、この逆を実施して下さい。)
*2: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#allowlist-email-domains
*3: https://docs.gitlab.com/ee/user/permissions.html#setting-new-users-to-external
*4: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#require-administrator-approval-for-new-sign-ups

 

各登録方法の具体的な運用例は以上です。

ユーザー登録はGitLab利用時にのみ発生するタスクなので、確実に必要なB社の開発メンバーのみを登録できるよう、GitLab側の機能 (外部ユーザー 等) と運用ルールをうまく組み合わせて運用方法をご検討ください。

最後に

今回の記事では、他社に開発を委託しつつリポジトリ管理は自社内のGitLabを使ってもらうケースにおいて、まずは委託先の開発メンバーをどのように登録するかを具体的に考えました。
今回のブログのポイントは以下の通りでしたが、いかがでしたでしょうか。

 

今回のポイント
  • 委託先の開発メンバーは、特別な要件が無ければ外部ユーザー (External Users) にしましょう。
  • 委託先の開発メンバーの登録方法は主に以下3通りが考えられます。
    • GitLab管理者による手動登録する。
    • GitLabの登録リクエスト機能を用いて登録する。
    • 特定のグループやプロジェクトにメールアドレスを用いて直接招待する。
  • 具体的な運用フローから各ユーザー登録方法のメリットデメリットを把握しましょう。

今回のブログでは上記のゴールが、このシナリオにおける "B社 (委託先) の開発メンバーの登録方法の検討" のポイントになっています。

特に外部ユーザー (External Users) は、外部委託時に利用することを想定している機能であるとGitLab Docsに明記されており、外部委託が多い日本のIT業界では利用できるケースが多いかと存じます。

この記事が、開発の委託先に自社のGitLabでリポジトリ管理してもらうことをご検討中の方の参考になれば幸いです。(どんだけニッチな需要…。)

GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品 お問い合わせ

今までのGitLabの検証ブログはこちらです。 GitLab カテゴリーの記事一覧 - ネットワールド らぼ

GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。 www.youtube.com