基于云原生/微服務(wù)的產(chǎn)品很復(fù)雜，為這些產(chǎn)品構(gòu)建訪問控制和管理權(quán)限也很復(fù)雜。而且每次拉取請求只會(huì)讓情況變得更糟。大多數(shù)開發(fā)人員最終都會(huì)為他們的產(chǎn)品多次構(gòu)建授權(quán)或訪問控制，他們被迫根據(jù)每個(gè)新客戶、產(chǎn)品或安全需求進(jìn)行重構(gòu)。

編輯搜圖

為了讓人們的工作和生活更輕松，需要了解構(gòu)建云原生權(quán)限帶來的獨(dú)特挑戰(zhàn)，并了解構(gòu)建云原生權(quán)限的五個(gè)最佳實(shí)踐，這些實(shí)踐可以為開發(fā)人員減少很多麻煩。

應(yīng)用程序和訪問權(quán)限已更改

開發(fā)人員在過去使用帶有授權(quán)或訪問控制的單一框架(如Django或Spring)來構(gòu)建授權(quán)，但當(dāng)創(chuàng)建云原生應(yīng)用程序時(shí)，這些不再適用。

這有幾個(gè)原因：

• 首先，應(yīng)用程序本身不再是單一的——它們基于微服務(wù)并且正在變得高度分散。當(dāng)開發(fā)人員需要合并部署在邊緣，并且通常也需要訪問控制的設(shè)備或?qū)嵗龝r(shí)，這一點(diǎn)也值得引起注意。

• 其次，云原生應(yīng)用程序往往需要集成第三方服務(wù)(例如計(jì)費(fèi)、身份驗(yàn)證、數(shù)據(jù)庫、分析等)，并且除了開發(fā)人員自己的應(yīng)用程序的微服務(wù)之外，還需要能夠控制對它們的訪問。

• 第三，更加動(dòng)態(tài)和分布式的應(yīng)用程序需要使用一堆不同的授權(quán)模型(例如RBAC、ReBAC、ABAC)，這些模型基于多個(gè)數(shù)據(jù)源和越來越復(fù)雜的規(guī)則。最后，安全、隱私和合規(guī)性需求也在上升(面對日益復(fù)雜的網(wǎng)絡(luò)威脅)并且變得非常復(fù)雜。開發(fā)人員發(fā)現(xiàn)自己不僅要管理誰應(yīng)該訪問數(shù)據(jù)，還要管理數(shù)據(jù)在不同服務(wù)之間的傳播方式。

授權(quán)的現(xiàn)實(shí)

所有這些新需求都要求在考慮授權(quán)時(shí)采用不同的思維方式：

• 授權(quán)不再是事后事項(xiàng)，必須提前計(jì)劃。

• 授權(quán)是一項(xiàng)持續(xù)的努力，而不是一次性解決的問題。它必須與產(chǎn)品一起不斷發(fā)展。

• 授權(quán)是客戶體驗(yàn)的關(guān)鍵，因?yàn)樗鼤?huì)影響用戶連接和邀請他人使用產(chǎn)品的方式。如果體驗(yàn)不好，他們不會(huì)喜歡。

• 授權(quán)連接到更大的身份和訪問管理空間。

構(gòu)建云原生權(quán)限的五個(gè)最佳實(shí)踐

為了處理所有這些更改，有一些最佳實(shí)踐可以幫助開發(fā)人員構(gòu)建云原生權(quán)限，并有時(shí)間實(shí)際開發(fā)功能，而不是在處理權(quán)限方面不堪重負(fù)。

1. 解耦策略和代碼

構(gòu)建云原生權(quán)限的最重要實(shí)踐之一是策略和代碼的解耦。將授權(quán)層的代碼與應(yīng)用程序代碼本身混合在一起可能會(huì)產(chǎn)生很大的問題。更重要的是，它造成了在不同微服務(wù)之間復(fù)制代碼時(shí)難以升級(jí)、添加功能和整體監(jiān)控代碼的情況。每一項(xiàng)更改都需要重構(gòu)大量代碼，這些代碼只會(huì)隨著這些微服務(wù)的發(fā)展而彼此偏離得更遠(yuǎn)。

這可以通過(在理想情況下)創(chuàng)建一個(gè)單獨(dú)的授權(quán)微服務(wù)將策略與代碼解耦來避免這種情況，其他服務(wù)將使用該微服務(wù)來滿足它們的授權(quán)需求。例如，開放策略管理或Spice DB等開源策略/權(quán)限引擎允許開發(fā)人員在單獨(dú)的服務(wù)中管理授權(quán)。

2. 事件驅(qū)動(dòng)

開發(fā)人員希望正在構(gòu)建的應(yīng)用程序是動(dòng)態(tài)的。應(yīng)用程序通常包括用戶邀請、角色分配或使用第三方數(shù)據(jù)源等功能——所有這些都應(yīng)該實(shí)時(shí)管理。如果沒有這種能力，做出授權(quán)決策的能力將顯著降低。

這要求開發(fā)人員將授權(quán)層設(shè)計(jì)為事件驅(qū)動(dòng)的。他們希望創(chuàng)建一個(gè)現(xiàn)實(shí)，每次發(fā)生影響授權(quán)的事件時(shí)，它都會(huì)立即通過系統(tǒng)傳遞，以確保授權(quán)層了解它，并與應(yīng)用程序和任何相關(guān)的第三方數(shù)據(jù)服務(wù)保持同步。

在理想情況下，為了實(shí)現(xiàn)這一點(diǎn)，開發(fā)人員將授權(quán)數(shù)據(jù)與應(yīng)用程序數(shù)據(jù)分離(因?yàn)椴⒎撬信c應(yīng)用程序相關(guān)的數(shù)據(jù)都與授權(quán)相關(guān)，反之亦然)，在授權(quán)層中創(chuàng)建一個(gè)精益模型，然后通過實(shí)時(shí)事件使其與應(yīng)用程序和其他源保持同步。

例如，開放策略管理層是一個(gè)開源項(xiàng)目，可以使開放策略管理成為事件驅(qū)動(dòng)的。這使開發(fā)人員可以響應(yīng)策略和數(shù)據(jù)更改，向其代理推送實(shí)時(shí)更新，并使開放策略達(dá)到實(shí)時(shí)應(yīng)用程序所需的速度。

3. 利益相關(guān)者的后臺(tái)集成

授權(quán)層是產(chǎn)品本身的一部分，在以產(chǎn)品為中心的企業(yè)中，有各種利益相關(guān)者需要能夠連接到訪問控制體驗(yàn)。與開發(fā)人員一起，這些包括DevOps、產(chǎn)品經(jīng)理、安全、合規(guī)、銷售、營銷等。在構(gòu)建授權(quán)層時(shí)，希望通過后臺(tái)系統(tǒng)為這些不同的利益相關(guān)者提供控制和接口。這要求從一開始就考慮不同利益相關(guān)者從訪問控制界面到產(chǎn)品的需求。應(yīng)該讓每個(gè)人都滿意。

4. 客戶接口

與考慮利益相關(guān)者要求的方式類似，開發(fā)人員還需要考慮最終用戶/客戶。授權(quán)不僅與管理產(chǎn)品有關(guān)，而且與產(chǎn)品的最終用戶有關(guān)。例如，如果用戶需要訪問他們自己的審計(jì)日志(幾乎每個(gè)B2B應(yīng)用程序用戶都需要)，他們應(yīng)該能夠輕松地看到在產(chǎn)品中所做的事情。提前認(rèn)識(shí)到這一需求需要構(gòu)建授權(quán)層，使其能夠鎖定滿足最終用戶需求的不同接口。

5. GitOps

因此創(chuàng)建了一個(gè)單獨(dú)的微服務(wù)來管理權(quán)限，并且能夠以事件驅(qū)動(dòng)的方式向它提供更新?，F(xiàn)在如何管理這些更改、應(yīng)用版本、應(yīng)用各種制衡，并確保微服務(wù)的代碼和數(shù)據(jù)符合需求和要求?其答案是GitOps。

使用GitOps可以讓開發(fā)人員為每個(gè)版本更改創(chuàng)建一個(gè)拉取請求。然后，當(dāng)開發(fā)人員更新產(chǎn)品及其訪問控制功能時(shí)，他們可以使用新代碼推動(dòng)提交，讓這些代碼通過必要的測試和檢查，并將它們應(yīng)用到授權(quán)層。

云原生權(quán)限的未來發(fā)展

隨著復(fù)雜性的增加以及客戶和安全需求的不斷涌現(xiàn)，以一種為未來做好準(zhǔn)備且不需要大量重構(gòu)或重寫的方式構(gòu)建產(chǎn)品的訪問控制至關(guān)重要。為授權(quán)創(chuàng)建單獨(dú)的微服務(wù)，將其設(shè)計(jì)為事件驅(qū)動(dòng)，為各種利益相關(guān)者和客戶提供控制和接口，并使用GitOps使開發(fā)人員能夠創(chuàng)建盡可能面向未來的產(chǎn)品，并防止他們不得不多次重建授權(quán)層，而無論需求如何。