《中交興路運維總監：中小企業如何優雅的管理多機房服務器賬號》要點：
本文介紹了中交興路運維總監：中小企業如何優雅的管理多機房服務器賬號，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

許穎維(中交興路 運維總監)

曾經就職于日 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 整個系統的發展

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

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

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4296.html