在昨天的文章，我們快速瀏覽 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。）

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 吧！

參考資料

• https://docs.gitlab.com/ce/administration/auth/how_to_configure_ldap_gitlab_ce/
• https://docs.gitlab.com/ce/integration/omniauth.html
• https://gitlab.com/gitlab-org/gitlab/issues/12388/designs
• https://gitlab.com/help/user/permissions