堡壘跳板機實現——總體架構

背景介紹

最近，筆者接手公司的一項任務：建造服務器的堡壘跳板機。

關於跳板機的實現，其實簡單版本網上一大堆，甚至更有開源堡壘機Jumpserver可供選擇，方案不少。接下來會就個人實現方案，整理出幾篇文章來作概要描述。

覆蓋功能

正所謂兵馬未動，糧草先行，在設計以前，先整理出咱們一期中堡壘機要覆蓋的基本功能點：

• 服務器統一帳號權限管理，包括哪些用戶能夠對哪些服務器進行login，哪些用戶有sudo權限；

• 用戶行爲記錄，可在必要時回看審查；

• 用戶登陸校驗審查；

如今初期的目標是將全部的linux服務器經過堡壘機進行管理把控，未來擴展下，一樣能夠經過ssh協議對 交換機、路由器、甚至是 Windows進行管理（目前windows已經能夠實現經過ssh登陸，不過這種方式就沒有圖形界面了且只能經過powershell來進行管理）。

架構設計

基於以上幾點功能點，設計架構以下：

下面對這個架構圖作下說明：

總體分爲三層，整體來講，
第一層 校驗用戶是否有登陸堡壘機的權限；
第二層真正爲用戶分配權限，同時判斷通過第一層的用戶是否有對目標機器操做的權限；
第三層則是真正登陸/操做服務器的方式，在這裏我將服務器的auth+sudo權限經過ldap來進行分佈式動態管理，稍後會有專門的說明；

第一層：
登陸入口，凡有堡壘機使用權限的都可以由此入口處登陸成功。
涉及主要服務： user login shell。
服務主要功能：

• 讀取用戶信息，判斷是否有登陸權限；

• 調用動態Token服務，驗證用戶passwd；

• 調用動態token服務，實現二維碼掃碼快速登陸；

• 調用第二層中的受權服務api，獲取&判斷用戶的login權限；

• 記錄用戶操做日誌；

關聯服務：

• 動態Token服務，相似於google auth，每一個人的動態碼均不同，每分鐘update一次，以此作登陸堡壘機的校驗，固然若是想簡單，單獨分配一個靜態密碼也能夠；

第二層：
受權服務管理，獲取登陸用戶當前的權限ip列表，判斷用戶的操做是否符合預受權。
涉及主要服務：受權管理服務

服務主要功能：

• 設置用戶/team的 權限列表；

• 將權限數據下發至第三層的ldap集羣；

• 提供api獲取用戶的權限list；

關聯服務：

• CMDB，以cmdb中的服務樹爲基本單位作受權，同時在cmdb中判斷受權的服務器對象是否有效;

• OA，以oa中的用戶組爲基本單位作權限授予，同時基於oa來判斷用戶是否有效;

第三層：
登陸實體服務器&執行命令；
將全部目標服務器的ssh登陸體系對接ldap集羣，經過在ldap中設置用戶的publickey & sudo等信息，來統一控制用戶的登陸權限&sudo權限。

目標規模：
使用兩臺服務器作ldap主從集羣，全部實體服務器對接此集羣，從而統一進行auth驗證。

未完待續

總體的架構說明就簡單這樣，接下來對就每一層的具體實如今分別和你們分享。