GitLab 的 User 與權限控管
本文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本文內容已有部分過期，本次搬移至此後，有補註何處已經過期。
本文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本文內容已有部分過期，本次搬移至此後，有補註何處已經過期。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10216217）
在昨天的文章，我們快速瀏覽 GitLab 管理者才能使用的 Admin Area。今天就讓我們回歸 GitLab 的一般操作，先認識 GitLab 的 User、Group、Member、Member Permissions 這些與權限控管有關的內容。
使用者註冊
在談權限控管之前，先來搞定使用者註冊。GitLab 使用者註冊過程非常簡單，僅需填寫基本的 Name、Username及Email 即可，註冊之後 GitLab 會透過 Email 進行 Confirm 確認帳號是否有效。
再次提醒，如昨天文章提過的，如果你沒有特別去修改 Admin Area 內 General 的設定，那麼預設 GitLab 是任何人都可以「註冊帳號」的。
（預設是任何人都能註冊帳號。）
如果你不打算讓人自行註冊帳號，那記得去修改 Admin Area 的設定，並且透過 root 管理者自行逐一新增 User。（但 root 新增的 User 一樣需要透過 Email 進行 Confirm 確認帳號。）
【新增補充】現在透過 root 建立的 User 可以略過 Email Confirm 了。
（root 帳號可以直接新增 User。）
GitLab 也支援 LDAP，所以如果公司內有在使用 Active Directory / LDAP 管理 User，GitLab 管理者也可以透過修改 GitLab Configuration（/etc/gitlab/gitlab.rb） 讓 GitLab 與 AD 進行整合，詳細的步驟可參閱官方文件。
除了支援 LDAP，GitLab 亦支援 OmniAuth，也就是說你可以讓你自架的 GitLab 支援 Facebook、Google、Twitter、GitHub 或其他帳號 Sign in。
（貼心的多重 Sign in 方式。）
OmniAuth 的設定方式一樣需要修改 GitLab Configuration（/etc/gitlab/gitlab.rb），GitLab 針對不同的 OAuth2 OmniAuth Provider 皆有個別的教學文件，有興趣者可以參閱官方文件。（如果不打算自架 GitLab，而是使用 gitlab.com，官方在 gitlab.com 一樣有開放可使用某幾間雲端服務的帳號登入，這應該算是官方的一項便民措施。）
權限控管
接著來談一談 GitLab 的權限控管。
GitLab 的權限控管會由以下四個項目構成：
- User 的
Access Level。 - User 是否為特定 Project 或 Group 的
Member。 - User 在 Project 及 Group 是哪一種
Member Permissions。 - Project 及 Group 的
Visibility Level為何。
Access Level
User 的 Access Level 為 GitLab 第一層的權限控管，它分為三個等級，一般使用者（Reguler）、管理者（Admin）及外部使用者（External users）。
一般使用者只能存取（Access）自己所屬的 Group 與 Project；而管理者則能夠存取所有的 Group 及 Project，並且能操作 Admin Area；外部使用者則只能存取 Visibility Level 被設定為公開（public）的 Project，以及有被個別授權的內部（internal）及私有（private）專案。另外，一般使用者還能再區分為是否擁有權限創建 Group。
當然如果你使用的是 gitlab.com，你的 Access Level 都會是 Reguler。
Group
在說明 Member 與 Visibility Level 之前，先簡單介紹一下 Group。
User 可以創建 Group，而在 Group 之內，則可以包含多個 Project 及 Member。
Group 有三個重點：
- Group 包含哪些
Member - Group 包含哪些 Project
- Group 本身，以及 Group 旗下之 Project 被設置為何種
Visibility Level。
Group 可以幫助你一次搞定多個 User 與多個 Project 之間的關係，例如你可以建立一個 Group 叫做「私密專案」，並設定預設只有 Group Members 才能夠「看見」其中的 Project；或者是按照實際的團隊分組來建立 Group，例如團隊 A、團隊 B、團隊 C，讓各團隊的 Members 皆只能使用自己團隊的 Project。
Member 與 Visibility Level
如前述，Project 與 Group 都可以設定 Member 及 Visibility Level，而兩者對於權限的影響是彼此關聯的。
前面有提到 Visibility Level 有三種設定，分別是 public、internal 與 private，而它們產生的影響分別如下：
- public: 即所有人，包含沒有登入 GitLab 的任何人都能看見此 Project 或 Group。
- internal: 即所有的 User，都能看見此 Project 或 Group。
- private: 只有該 Project 或 Group 的 Member 才能看見它。
由上述內容，我們可以理解 Member 及 Visibility Level 即是 GitLab 第二層的權限控管，主要以是否已註冊為 GitLab User 及 User 隸屬於哪個 Project 或 Group 來控制權限。
Project 本身會受制於 Group 的 Visibility Level。如果 Group 設定為 private，則它旗下 Project 的 Visibility Level 也只能設定為 private；但如果 Group 是設定為 internal，則 Project 即可設定為 private 或 internal；同理如果 Group 為 public，則 Project 可以自由選擇是 public、internal 或 private。
最後，gitlab.com 因為本來就開放任何人都可以公開註冊為 User，這導致在使用 gitlab.com 時，如果將 Project 的 Visibility Level 設定為 internal 其實並沒有什麼實質的意義。因此官方已於 2019 年的七月關閉此功能，任何新的 Project、Group 都不能設定 Visibility Level 為 internal。但過去已經設為 internal 的 Project 可選擇繼續保持為 internal。
Member Permissions
最後一個影響權限控管的是 Member Permissions，這能夠用來設定 User 在 Project 到底能使用哪些功能和執行哪些動作，例如：User 是否能建立 branch、能否推送 merge request。
Member Permissions 目前只能套用既定的五種 Permissions，分別是 Guest、Reporter、Developer、Maintainer 與 Owner，這五種角色各自擁有權限與能執行的動作不同，並且也無法由管理者自由「勾選」設置更細部的權限。因為這五種角色詳細的權限差異有點多，就請各位自行查看官方文件了。
小結
今天我們快速的認識了 GitLab 的權限控管，綜合以上功能 GitLab 已經能滿足多種常見的使用情境，相信雖然工具是死的，但人是活的，大家一定能從中找出最適合你團隊的 GitLab 權限控管方式。最後，我們就舉兩個常見的使用情境為例，為今天的內容劃下句點。
情境一：單一小團隊
- 全團隊使用 gitlab.com，因此無需擁有（也無法擁有）
Access Level為 Admin 的最高權限帳號。 - 公司的產品皆放在團隊的 Private Group 之下。
- 公司的開源專案，則存放在團隊的 Public Group 之下。
- 團隊主管為所有 Group 的 Owner，可以管理所有的 Project。
- 團隊成員皆加入所有的 Group，是所有 Project 的 Member。
- 團隊內的開發者則根據資深程度，設定不同的
Member Permissions，資深能協助 Code Review 者為 Maintainer，有權限可以審核 merge request；而資淺者則為 Developer，只能將程式 git push 至未受保護的 branch。
情境二：多部門、團隊協作
- 由公司的維運部門架設 GitLab EE 供多個開發團隊使用。
- 各開發團隊擁有自己的 Private Group。
- 各開發團隊共用的元件、Library、Package，存放於所有開發團隊共用的 Internal Group 之下。
- 公司的開源專案，則存放於供所有開發團隊加入的 Public Group。
- 前述的各個 Group 之下，皆會建立第二層的 Subgroup 以分門別類。
- 團隊內的開發者依據資深程度，設定不同的
Member Permissions，資深者為 Maintainer，資淺者為 Developer。 - PM 與 QA 的
Member Permissions則設定為 Reporter，可以協助回報 Issue。 - 不同開發團隊的開發者，如果有興趣，可以申請成為其他團隊的 Guest 瀏覽 Project 內容。
- 客戶的驗收窗口、外包的開發者，則以外部帳號加入特定 Project 成為 Member，並依據需求設定
Member Permissions為 Reporter 或 Developer。
以上就是今天跟大家分享的內容，明天讓我們開始進入專案 Project 吧！