作者簡介：

許穎維（中交興路 運維總監）

曾經就職於日 PV 超億次的 WAP 搜尋公司，後加入多次佔領 Facebook 日活躍 Top10 的遊戲公司（產品有開心水族箱、開心消消樂），負責搭建自動化運維平臺。

現在國內領先的商用車聯網公司擔任系統支援部負責人，同時負責併發百萬級別的實時線上車聯網平臺運維工作。

前言

本文內容大致分成四部分：

1. 選擇，我們初步選擇的時候會考慮哪些問題。
2. 需求分析，分析我們的主要需求是什麼，如何與服務進行緊密結合。
3. 如何實施，因為運維人員比較關注工具的落地過程，所以我也重點講講這塊，但是不會像很多文章一樣講詳細部署過程，我會著重分享部署過程中容易出錯的地方。
4. 演變歷程，以我在這家公司的經歷為例，從一個最簡單的需求發展到能夠滿足不同業務的需求，並最終滿足比較苛刻安全的一個過程。

1、選擇

整個故事要從一臺老舊的伺服器開始

那年，我們的叢集規模有400多臺伺服器，部分是很穩定地，大家慢慢就忽略掉它了。突然有一天監控系統上發現一臺邊緣很老的伺服器負載太高，影響了主站的穩定性。

我的第一反應就是讓業務運維登陸上去處理，結果過了5分鐘業務運維反饋說“密碼錯誤”。因為我們有業務運維和系統運維區分，所以我讓系統工程師去登入一下。

結果不幸的是，系統管理員反饋“這個伺服器比我們所有的工程師都早出現在這個公司，大家都不知道他的密碼”。這個時候就非常著急了，我們收到大量的使用者投訴。一個本來五分鐘就可以解決的問題，但是我們卻花了兩個小時。

最後我們開總結會的時候，大家都認定這個問題得必須重視了，業務的擴充套件非常快，我們不可能每一個伺服器都記錄一個帳號，我們需要有一套統一的身份認證。

2、最初的需求誕生了

當我們還在使用 SSH 跟 SCP 的時候，每個員工只需要一個密碼，不管是登陸生產環境還是測試環境。我更改密碼的時候也立即生效，而且我不想讓 SA 知道我的密碼，這就是我們最初的需求。

明確了需求之後，我們就開始考慮選擇什麼工具合適。有一種方案很簡單就是我們用一個配置管理工具把這個伺服器上面的 shadow/passwd 檔案管理起來。

但是這樣很被動，我所有的操作都依賴於它，我很多的操作生效期都會受到影響。還有另一個解決方案就是身份認證系統，我們知道這個是人人一直在用的  Kerberos，還有 OpenLDAP 也是一個比較熱門的，最後就是商業產品堡壘機。

而創業公司的我們認為成本是第一要素，毋庸置疑首選就是開源。究竟是選擇 kerberos 還是 OpenLDAP 呢？

我們請教了一個以前用過這方面的大拿，他推薦使用 OpenLDAP，因為使用起來很簡單，就是用賬戶密碼登陸。而 Kerberos 他可能會比較複雜一些，因為它有 Ticket 的認證過程。

所以我們就初步選擇 OpenLDAP 了。同時我們發現國外的大廠 Facebook 和 谷歌都要使用 OpenLDAP，這就給了我們很大的信心。

同時，我們與商業產品進行對比，主要是價格和功能上有大的差異。

• 價格方面： 一個機房我只要一臺伺服器，甚至是半臺就可以搭建 OpenLDAP 服務，大約成本不到2萬，而這個商業的堡壘機需要將近20萬的成本。
• 架構模式： 差不多，一個 CS 一個 BS。
• 授權模式： 就是我們在對使用者的許可權管理方式，商業會比較有優勢，這方面考慮的還是不錯。還有操作回放是商業比較好的一個特徵，因為他們支援這種審計功能，他們知道每一個使用者登陸上去都在做什麼。但是後面這個開源也有，我們是通過 script 命令，就是可以把一個使用者所有的操作包括回顯都可以記錄。這個還是挺不錯的。

最主要的就是價格，老闆說 OK 就可以了，畢竟老闆對錢都是非常敏感的。

3、如何實施 OpenLDAP

我介紹一下 OpenLDAP，它是輕量級目錄訪問協議，它特別適用於查詢多但寫入少的場景，可以做到毫秒級響應，但是如果是變更多的場景就不合適了。

然而它是怎麼工作的呢？我們需要在需要認證的伺服器上安裝一個 OpenLDAP 的客戶端，這個客戶端其實是系統級別就已經是綁定了，我們就從這個圖來看，我們是首先處於左下角。

使用者登陸的時候，先登陸第一臺跳板機，登陸上去的時候，其實訪問的是本地的 PAM 模組，他通過 nsswitch 模組訪問呼叫兩個檔案 passwd & shadow，但是裡面還有一個是可以支援多源的許可權訪問方式。

可以調動 OpenLDAP 的客戶端，把帳號和密碼傳送給 OpenLDAP 伺服器端（右下角的那臺伺服器），如果再 OpenLDAP 伺服器端匹配正確，就返回給所登陸的伺服器【OK】，這時我們就可以順利的登陸伺服器，這個是和使用正常登陸方式一模一樣的。

OpenLDAP 記哪些資訊，包括使用者ID使用者帳號，使用者密碼，包括許可權的定義。這裡涉及到提權的過程，因為我們每個人在有了 LDAP 賬號之後，登陸到伺服器上都是個人賬號，而大部分的時候我們是有切換到其他賬號需求的。

OpenLDAP 的提權管理做的比較強，它是 Sudoers schema 裡面去定義每一組的具體許可權，而每個人又對應到某個具體組內。這就能輕鬆做到我和這個組裡的人許可權一致，同時許可權的變更是全域性性的，所有伺服器生效。

回顧最初需求

我們回顧當時最初的需求，並不是要做精細化管理，即只需要所有的人登入到伺服器上，完成人員的賬號認證，研發人員、運維都是個人使用者，登陸上伺服器之後使用 sudo 切換到 root 的 賬號。

當時是用這種非常粗放的管理方式，當然我們資料庫不在這個管理範圍之內，因為這種OpenLDAP登陸資料庫太危險了，不建議使用它們來管理資料庫。

接下來是安裝過程，（在這裡就不細寫了我著重講客戶端的配置過程）

我使用 authconfig-tui 命令就可以進入到這個模式，這個配置很簡單，只要前面勾選五個選項，然後下一步把 URI 和 Base 配置完成就 OK 了。

但是運維關注的是，這些操作的背後究竟是做了什麼事情。如果我操作完還不生效就需要去檢視配置檔案。其中包括這麼幾個配置檔案：

1. /etc/ldap.conf

2. /etc/nsswitch.conf

3. /etc/sysconfig/authconfig

4. /etc/pam.d/system-auth

只要保證這些配置檔案按要求進行修改，不用使用互動式工具也可以完成配置過程。

完成配置之後我們就會經常收到其他同事的抱怨，誤操作刪除掉系統檔案，壓力好大。接下來我們就開始了許可權的精細化管理演變。

4、演變歷程

4.1 精細化管理

上面就是許可權的精細化管理的成員類別邏輯圖：

• 第一級為系統管理員；
• 第二級就是應用運維，他能夠做服務的變更；
• 第三級就是網路管理員，他能做執行一些命令操作，因為我們最擔心是網路管理員以“許可權不夠”為名，讓系統工程師幹活。因此我們就給他增加了一些許可權；
• 第四級就是 observer 這個角色，這個就是給研發用的，研發有需求看日誌但是不能有操作許可權的；
• 最後一個就是 Personal，這個就是個人，用於證明你就是你。

還有一個圖非常重要，就是要跟大家講一個普遍新手都會誤會的地方，大部分人認為在 OpenLDAP 管理內，首先就是組，然後下面的分支是人，再下面的分支是許可權。其實不是這樣的，如下圖：

其實人、組、許可權都是並列的，具體而言，在這個人屬性裡面包含了一個元素 UID，如果五個人對應同一個 UID，那這五個人就是一個組。

許可權分支內定義很多的許可權組，許可權組又有屬性和組對應，因此人跟組、許可權就對應起來了，所以大家看書的時候不要被誤導了，這個就是落地的基本形式。

4.2 分散式管理

接下來問題來了，我們是一個車聯網的公司，全國有將近十個機房，我們需要考慮這麼多個機房的部署和維護工作。

最簡單是我們所有的伺服器都到一個地方認證，看似很棒的一個方案，但其實你想，這是不行的。因為我們很多時候有登陸伺服器的緊急需求就是網路故障或者是普通服務故障。

如果是集中式管理，可能會導致網路有故障的時候伺服器認證也有問題。所以解決方案是分散式管理，分散式認證。

這個跟 MysqlCluster 叢集的管理方式是一樣的，有 Master 節點負責寫入，通過日誌推到各個機房的 Slave 上面，然後在本地進行 redo 到 Slave 上。

同時所有的使用者都是在本機房內的節點進行認證，所有的修改會被 rewrite 到 Master 節點上。下圖就是具體日誌，我們可以看看裡面的描述：

這個就是在幾點幾分的日誌，就是他把這個使用者的密碼改了。目前我們能做到七百臺伺服器同時併發登陸及更改密碼，基本上公司大部分的需求我們都可以滿足。

4.3 安全考慮

本以為完成全部的需求，這時候安全部門找到我們，質疑我們“你們這個東西安全嗎？你們目前的安全狀況確實是太糟糕了，所有使用者的登陸過程密碼我全部都看見了”……

這確實是太糟糕了，在我的經驗裡面，上線不到幾小時就發現從馬來西亞不斷的有嘗試暴力破解我們的伺服器的情況，一旦嘗試暴力破解成功所造成的影響是超過我們預期的。這樣，我們就開始了安全方面的需求改造。

非常慶幸的是 OpenLDAP 支援 TLS 的證書認證方式。這裡有一個建議，就是大家做證書的時候一定要使用泛域名證書。為什麼？

因為你可能涉及到每一個組機房都使用唯一的一個域名。你所有的機房都可以使用同一個證書，因為你不用管哪一個機房都可以使用泛域名證書。

同時我們還做了限制登入的方案，這個跟 OpenLDAP 沒有關係。只是我們使用 PAM 模組對登入失敗使用者進行限制而已。

只要單個使用者五次登陸失敗，鎖定600秒這個大家可以試一下。

4.4 服務解耦

安全部門也搞定了，最後一個問題就是服務解耦。為什麼會有這個需求呢，因為有一天運維反饋所有的伺服器登入特別慢，是因為在 Nginx 上面，起用了新功能，需要讀本地的檔案。

而我們知道每一次讀本地檔案的時候，就需要檢查這個使用者是不是有許可權，很不幸他把所有的許可權校驗過程都發給了 OpenLDAP 伺服器，我們當時的使用者是每秒鐘有七千個使用者訪問，我們的伺服器感覺快爆了。

我們看了一下這個 OpenLDAP 的官網，其實已經給我們解決相關的辦法，解決這個問題需要在客戶端的  /etc/ldap.conf 檔案裡面增加nss_initgroups_ignoreusers 引數，就是說這些使用者統統都不用去做認證，只需要去做本地的 Passwd 和  Shadow 裡面即可，這樣就解決完成解耦的問題。

4.5 對個人賬號基於伺服器的限制

後續又有專案組的領導說，我們現在伺服器比較多，但是我不想其他專案組看到我們的程式碼日誌等資訊，如何？

OpenLDAP 也是可以滿足這個需求的，他可以使用 pam_check_host_attr 這種引數來保證我可以做到每一個使用者只能登陸我們指定的伺服器，這裡我就不詳細說明，給大家點個方向。

4.6 內部需求：高效管理

我們到目前為止沒有發生大問題的時候，但是發現公司不斷的發展，人員的離職、入職及人員的變動經常需要我們進行賬號的刪除新增，這是我們內部管理的要求。

後來我們給自己開發了一個 web 管理系統，對新增刪除賬號轉變成更為簡單的操作。

這個就是把一個修改賬號的請求通過 web 頁面進行描述，將請求儲存到資料庫內，並在後端使用定時任務將其操作內容在 OpenLDAP 內進行生效，並返回給他結果的過程。最終體現在頁面上就是這樣。

4.7 整個系統的發展

回顧一下我們整個系統的發展階段：

• 第一個就是帳號密碼管理；
• 第二個就是方案架構的方面的調整；
• 第三個安全我們做了主機的限制，還要做了防暴力破解；
• 第四個就是高效管理，應對內部的管理需求；

原文來自微信公眾號：高效運維