堡壘跳板機實現——整體架構
背景介紹
最近，筆者接手公司的一項任務：建造服務器的堡壘跳板機。
關于跳板機的實現，其實簡單版本網上一大堆，甚至更有開源堡壘機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驗證。
未完待續
整體的架構說明就簡單這樣，接下來對就每一層的具體實現在分別和大家分享。
