為Kubernetes中任意應用添加基于oauth2的認證保護 (上)

企業随着業務的發展，必然會部署各種各樣的IT系統。出于安全性的考慮，一些系統僅可企業内部使用，甚至僅開放給企業部分部門員工使用。

這些IT系統大緻可分為兩類，

1. 系統本身不支援任何認證機制，例如資訊或文檔類系統。需要增加認證保護，能夠限制非企業員工通路即可。系統運維通常的做法是，為站點設定 HTTP Basic認證 保護。由于 是通過預設的使用者、密碼認證，認證資訊比較容易洩露。即使定期更換密碼，但需要額外的機制通知使用者密碼的變更，使用者體驗也不好。
2. 系統自身支援認證，甚至支援多種認證機制。比如最常用的開源CI/CD工具， Jenkins 内置支援本地資料庫認證、通過 插件 支援多種第三方系統內建認證。如果大量的IT系統都有一套獨立的使用者管理，随着企業的員工的變更，使用者的增删等操作對系統管理者來說是不小的工作量。同時，也很容易由于人為疏忽，造成資産、資料的安全隐患。

假設企業自身已經有了一套OA系統包含員工、組織結構管理，例如，國内目前最為普及流行的

釘釘

或

企業微信

。我們完全可以提供一套基于

oauth 2.0協定

的認證方式，讓以上兩類IT系統使用企業已有的OA系統(

)來實作登入認證。做到這一點後，企業無論有多少IT系統都不再需要額外管理使用者的成本，并且也避免了資料安全隐患。

通過

釘釘開放平台

提供的API開放了許多釘釘内部的能力，例如，

身份驗證

、

通訊錄管理

等等。然而

釘釘的三方網站登入接口

并不是标準的

實作，我們需要通過一個

oauth2 proxy

代理工具實作将

釘釘的三方網站登入

相容

oauth2

協定。同理，使用

這個oauth2代理工具

，可以使用

Google Facebook

等三方網站作為統一認證方式。

有了基于

釘釘的oauth2代理

作為企業統一登入方式，對于上面兩大類系統的認證需求解決方案分别如下，

1. 部署在 Kubernetes 中無内置認證機制的Web應用，通過 nginx-ingress 的 外部OAUTH認證 實作基于oauth2的安全認證。
2. 可以通過 反向代理插件 實作使用oauth2認證登入。

在

下篇

中，我們将圖文詳解如何一步步實作為一個無認證的企業文檔Web應用添加基于

釘釘的統一認證

。