iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 4
1

在昨天的文章,我們快速瀏覽 GitLab 管理者才能使用的 Admin Area。今天就讓我們回歸 GitLab 的一般操作,先認識 GitLab 的 User、Group、Member、Member Permissions 這些與權限控管有關的內容。

使用者註冊

在談權限控管之前,先來搞定使用者註冊。GitLab 使用者註冊過程非常簡單,僅需填寫基本的 NameUsernameEmail 即可,註冊之後 GitLab 會透過 Email 進行 Confirm 確認帳號是否有效。

再次提醒,如昨天文章提過的,如果你沒有特別去修改 Admin Area 內 General 的設定,那麼預設 GitLab 是任何人都可以「註冊帳號」的。

https://ithelp.ithome.com.tw/upload/images/20190917/20120986F2qQRLAH2L.jpg
(預設是任何人都能註冊帳號。)

如果你不打算讓人自行註冊帳號,那記得去修改 Admin Area 的設定,並且透過 root 管理者自行逐一新增 User。(但 root 新增的 User 一樣需要透過 Email 進行 Confirm 確認帳號。)

https://ithelp.ithome.com.tw/upload/images/20190917/201209864Ql8vFuBdx.jpg
(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。

https://ithelp.ithome.com.tw/upload/images/20190917/201209867bGmFji6xz.jpg
(貼心的多重 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

在說明 MemberVisibility 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 都可以設定 MemberVisibility Level,而兩者對於權限的影響是彼此關聯的。

前面有提到 Visibility Level 有三種設定,分別是 public、internal 與 private,而它們產生的影響分別如下:

  • public: 即所有人,包含沒有登入 GitLab 的任何人都能看見此 Project 或 Group。
  • internal: 即所有的 User,都能看見此 Project 或 Group。
  • private: 只有該 Project 或 Group 的 Member 才能看見它。

由上述內容,我們可以理解 MemberVisibility 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 吧!

參考資料


上一篇
Admin Area—維運 GitLab Server 的管理者後台
下一篇
GitLab: 從建立 Group 和 Project 開始
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言