摘要：微服務(wù)能夠?yàn)閼?yīng)用程序設(shè)計(jì)提供一種更具針對性范圍性與模塊性的實(shí)現(xiàn)方案。安全微服務(wù)部署模式可謂多種多樣但其中使用最為廣泛的當(dāng)數(shù)每主機(jī)服務(wù)模式。在微服務(wù)環(huán)境下，安全性往往成為最大的挑戰(zhàn)。不同微服務(wù)之間可通過多種方式建立受信關(guān)系。

每個人都在討論微服務(wù)，每個人也都希望能夠?qū)崿F(xiàn)微服務(wù)架構(gòu)，而微服務(wù)安全也日漸成為大家關(guān)注的重要問題。今天小數(shù)與大家分享的文章，就從應(yīng)用層面深入探討了應(yīng)對微服務(wù)安全挑戰(zhàn)的方案，為微服務(wù)安全提供了新的思路。

面向服務(wù)架構(gòu)（簡稱SOA）引入了一類設(shè)計(jì)規(guī)范，其核心思路在于采用高度解耦式服務(wù)部署，其中各項(xiàng)服務(wù)可通過一套標(biāo)準(zhǔn)信息格式經(jīng)由網(wǎng)絡(luò)實(shí)現(xiàn)彼此通信。這套方案與具體技術(shù)無關(guān)，即不考慮各項(xiàng)服務(wù)具體是如何實(shí)現(xiàn)的。每項(xiàng)服務(wù)都擁有一個明確定義，用于發(fā)布服務(wù)描述或者服務(wù)接口。在實(shí)踐當(dāng)中，這類信息格式通過SOAP實(shí)現(xiàn)標(biāo)準(zhǔn)化——即由W3C于2000年初推出的一項(xiàng)標(biāo)準(zhǔn)——同時(shí)亦基于XML——其中服務(wù)描述由WSDL（另一項(xiàng)W3C標(biāo)準(zhǔn)）進(jìn)行標(biāo)準(zhǔn)化，而服務(wù)發(fā)現(xiàn)標(biāo)準(zhǔn)由UDDI（同樣為W3C標(biāo)準(zhǔn)）實(shí)現(xiàn)。這一切正是基于SOAP的Web服務(wù)的實(shí)現(xiàn)基礎(chǔ)，甚至使得Web服務(wù)在一定程度上成了SOA的代名詞。不過這種實(shí)現(xiàn)方式在架構(gòu)模式層面也有著自己的缺陷。SOA的基本原則正被時(shí)代所逐步淘汰，如今由OASIS提供的WS-*堆棧（包括WS-Security， WS-Policy， WS-Security Policy，WS-Trust, WS-Federation, WS-Secure Conversation, WS-Reliable Messaging, WS-Atomic Transactions, WS-BPEL等等）令SOA的復(fù)雜性不斷提高，這也直接導(dǎo)致很多普通開發(fā)者發(fā)現(xiàn)自己很難對其加以駕馭。

多年之后，如今我們得以再次開啟這段通往SOA基本原則的旅途——但這一次它有了新的名號，即微服務(wù)。微服務(wù)能夠?yàn)閼?yīng)用程序設(shè)計(jì)提供一種更具針對性、范圍性與模塊性的實(shí)現(xiàn)方案。

微服務(wù)可謂當(dāng)下一大熱門詞匯之一，與之并駕齊驅(qū)的則包括物聯(lián)網(wǎng)、容器化與區(qū)塊鏈?！拔⒎?wù)”一詞最初于2011年5月亮相于威尼斯軟件架構(gòu)師研討會。這個詞匯用于解釋一類常見的架構(gòu)類型。

大家已經(jīng)意識到微服務(wù)并不僅僅是做對了的SOA，它也不只是一種架構(gòu)模式——而是一種圍繞架構(gòu)模式展開的全新文化。其由主要目標(biāo)作為驅(qū)動力，旨在實(shí)現(xiàn)快速部署與快速生產(chǎn)。

在保護(hù)微服務(wù)安全時(shí)，需要從以下幾個角度入手：

保護(hù)開發(fā)生命周期與測試自動化機(jī)制：微服務(wù)背后的核心驅(qū)動力在于提升投付生產(chǎn)的速度。我們需要向服務(wù)當(dāng)中引入變更，加以測試而后立即將成果部署至生產(chǎn)環(huán)境。為了確保在代碼層面中不存在安全漏洞，我們需要制定規(guī)劃以進(jìn)行靜態(tài)代碼分析與動態(tài)測試——更重要的是，這些測試應(yīng)當(dāng)成為持續(xù)交付流程的組成部分。任何安全漏洞都需要在早期開發(fā)周期內(nèi)被發(fā)現(xiàn)，另外反饋周期也必須盡可能得到縮短。

DevOps安全：微服務(wù)部署模式可謂多種多樣——但其中使用最為廣泛的當(dāng)數(shù)每主機(jī)服務(wù)模式。其中的主機(jī)指定的并不一定是物理設(shè)備——也很可能屬于容器（Docker）。我們需要對容器層面的安全進(jìn)行關(guān)注。我們該如何確保各容器之間得到有效隔離，又該在容器與主機(jī)操作系統(tǒng)之間采取怎樣的隔離水平？

應(yīng)用級別安全：我們該如何驗(yàn)證用戶身份并對其微服務(wù)訪問操作進(jìn)行控制，又要怎樣保障不同微服務(wù)之間的通信安全？

在今天的文章中，我們將提供一整套安全模式，旨在解決應(yīng)用層級所面臨的各類微服務(wù)安全保護(hù)挑戰(zhàn)。

在整體型應(yīng)用程序中，所有服務(wù)都被部署在同一應(yīng)用服務(wù)器當(dāng)中，而該應(yīng)用服務(wù)器本身則提供會話管理功能。其中不同服務(wù)間的接口為本地調(diào)用，且全部服務(wù)皆可共享用戶的邏輯狀態(tài)。每項(xiàng)服務(wù)（或者組件）不需要對用戶進(jìn)行驗(yàn)證。驗(yàn)證工作集中由攔截器處理，其攔截所有服務(wù)調(diào)用并審查其是否可以放行。驗(yàn)證完成之后，其會在不同平臺上的不同服務(wù)（或者組件）間發(fā)送用戶登錄憑證。以下示意圖解釋了整體應(yīng)用程序中各不同組件間的交互方式。

在Java EE環(huán)境下，攔截器可以由servlet過濾器充當(dāng)。該servlet過濾器會攔截全部來自其已注冊上下文的請求，并強(qiáng)制進(jìn)行驗(yàn)證。該服務(wù)調(diào)用要么攜帶有效的憑證，要么擁有能夠映射至某個用戶的會話令牌。一旦servlet過濾器找到該用戶，則會創(chuàng)建登錄上下文，并將其傳遞給下游組件。每個下游組件都能夠從該登錄上下文內(nèi)識別出用戶以完成授權(quán)。

在微服務(wù)環(huán)境下，安全性往往成為最大的挑戰(zhàn)。在微服務(wù)架構(gòu)當(dāng)中，各服務(wù)分布及部署在分布式設(shè)置當(dāng)中的多套容器之內(nèi)。各服務(wù)接口不再存在于本地，而是通過HTTP進(jìn)行遠(yuǎn)程接入。以下示意圖顯示了不同微服務(wù)之間的交互方式。

這里的挑戰(zhàn)在于，我們要如何驗(yàn)證用戶并在不同微服務(wù)之間以對稱方式完成登錄上下文傳遞，隨后還要想辦法讓微服務(wù)完成對用戶的授權(quán)。

在今天的文章中，我們將探討兩套方案，旨在保護(hù)服務(wù)到服務(wù)通信。其一基于JWT，其二則基于TLS相互驗(yàn)證。

JWT（即JSON Web令牌）負(fù)責(zé)定義一套容器，旨在完成各方之間的數(shù)據(jù)傳輸。其可用于：

在各方之間傳播其中一方的身份。

在各方之間傳播用戶權(quán)利。

通過非安全通道在各方之間安全實(shí)現(xiàn)數(shù)據(jù)傳輸。

根據(jù)JWT受信指標(biāo)判斷用戶身份。

已簽名JWT被稱為JWS（即JSON Web簽名），而加密JWT則被稱為JWE（即JSON Web加密）。事實(shí)上，JWT并不會以自身原始方式存在——其要么作為JWS，要么作為JWE，它像是一種抽象類——JWS與JWE為其具體實(shí)現(xiàn)方式。

來自某一微服務(wù)并將被傳遞至另一微服務(wù)的用戶上下文可伴隨JWS一同傳遞。由于JWS由上游微服務(wù)的某一已知密鑰進(jìn)行簽名，因此JWS會同時(shí)包含有最終用戶身份（在JWT中聲明）以及上游微服務(wù)身份（通過簽名實(shí)現(xiàn)）。為了接收J(rèn)WS，下游微服務(wù)首先需要根據(jù)JWS本身中的嵌入公鑰對JWS的簽名進(jìn)行驗(yàn)證。這還不夠，我們還需要檢查該密鑰是否受信。不同微服務(wù)之間可通過多種方式建立受信關(guān)系。其一為由服務(wù)為各服務(wù)配置受信證書。很明顯，這種方式在規(guī)?；⒎?wù)部署環(huán)境中并不可行。因此我建議大家建立一套專有證書中心（簡稱CA），同時(shí)可以為不同微服務(wù)組設(shè)置中介證書中心?，F(xiàn)在，相較于互相信任及各自分配不同的證書，下游微服務(wù)將只需要信任根證書授權(quán)或者中介機(jī)制即可。這能夠顯著降低證書配置所帶來的管理負(fù)擔(dān)。

每項(xiàng)微服務(wù)都需要承擔(dān)JWT驗(yàn)證成本，其中還包含用于驗(yàn)證令牌簽名的加密操作。微服務(wù)層級中的JWT會進(jìn)行緩存，而非每次進(jìn)行數(shù)據(jù)提取，這就降低了重復(fù)令牌驗(yàn)證造成的性能影響。緩存過期時(shí)間必須與JWT的到期時(shí)間相匹配。正是由于利用這種機(jī)制，因此如果JWT的過期時(shí)間設(shè)定得太短，則會給緩存性能造成嚴(yán)重影響。

JWT在其聲明集中包含一項(xiàng)參數(shù)，名為sub，其代表擁有該JWT的主體或者用戶。JWT本身也可以包含各類用戶屬性，例如first_name、last_name、email等等。如果任何微服務(wù)需要在其操作過程中識別此用戶，則需要查看對應(yīng)的屬性。Sub屬性的值對于給定發(fā)行者而言是惟一的。如果大家擁有一項(xiàng)微服務(wù)，其能夠從多個發(fā)行者處接收令牌，那么該用戶的惟一性應(yīng)被認(rèn)定為該發(fā)行者與sub屬性的結(jié)合體。

而aud參數(shù)同樣存在于JWT聲明集內(nèi)，負(fù)責(zé)指定令牌的目標(biāo)受眾。其可以是單個接收者或者是一組接收者。在執(zhí)行任何驗(yàn)證檢查之前，該令牌接收者都必須首先查看是否發(fā)布了特定JWT供其使用，如果沒有則立即拒絕。令牌發(fā)送方需要在發(fā)出令牌之前，確定該令牌實(shí)際接收者的身份，同時(shí)aud參數(shù)值必須屬于令牌發(fā)送方與接收方間預(yù)先約定的值。在微服務(wù)環(huán)境中，我們可以利用正規(guī)表達(dá)式來驗(yàn)證令牌受眾。舉例來說，令牌中的aud值可以為*.facilelogin.com，意味著facilelogin.com域名下的每個接收方（例如foo.facilelogin.com,bar.facilelogin.com等）都能夠擁有自己的aud值。

在TLS相互驗(yàn)證與JWT方法當(dāng)中，每項(xiàng)微服務(wù)都需要擁有自己的證書。這兩種方法的區(qū)別在于，JWT驗(yàn)證機(jī)制中JWS可同時(shí)攜帶最終用戶身份以及上游服務(wù)身份。而TLS相互驗(yàn)證則只在應(yīng)用層傳輸最終用戶身份。

在以上提到的兩種方案當(dāng)中，證書吊銷都是項(xiàng)棘手的任務(wù)。證書吊銷盡管難以實(shí)現(xiàn)，但仍然存在多種選項(xiàng)供我們選擇：

CRL (證書吊銷列表 / RFC 2459)

OCSP (在線證書狀態(tài)協(xié)議 / RFC 2560)

OCSP Stapling (RFC 6066)

OCSP Stapling Required (尚處于草案階段)

CRL的使用頻率并不高?？蛻舳嗽诎l(fā)起TLS握手時(shí)，必須從對應(yīng)的證書頒發(fā)中心處獲取一份長長的吊銷證書列表，而后檢查服務(wù)器證書是否被列入該列表。相較于每一次進(jìn)行列表獲取，客戶端可以在本地對CRL進(jìn)行緩存。在此之后，大家還需要考慮如何避免以陳舊數(shù)據(jù)為基礎(chǔ)做出判斷的問題。當(dāng)TLS相互驗(yàn)證機(jī)制被使用時(shí)，服務(wù)器也需要針對客戶端進(jìn)行同樣的證書驗(yàn)證。最終，人們發(fā)現(xiàn)CRL的實(shí)際效果其實(shí)并不理想，因此新的解決方案也應(yīng)運(yùn)而生——這就是OCSP。

在OCSP當(dāng)中，一切元素的實(shí)際效果都要比CRL好上那么一點(diǎn)。TLS客戶端能夠檢查特定證書的狀態(tài)，且無需從證書中心處下載完整的吊銷證書列表。換句話來說，當(dāng)客戶端每次與新的下游微服務(wù)進(jìn)行通信時(shí)，其都必須同對應(yīng)的OCSP響應(yīng)方溝通以驗(yàn)證當(dāng)前服務(wù)器（或者服務(wù)）的證書狀態(tài)——而服務(wù)器則必須面向客戶端證書執(zhí)行同樣的操作。如此一來，OCSP響應(yīng)方同樣面臨著巨大的流量壓力?；谕瑯拥目紤]，客戶端仍然可以對OCSP決策進(jìn)行緩存，但這無疑繼續(xù)帶來同樣的、基于陳舊數(shù)據(jù)進(jìn)行決策的可能性。

而OCSP stapling的出現(xiàn)令客戶端不再需要每次同下游微服務(wù)進(jìn)行通信時(shí)，都與OCSP響應(yīng)方“打招呼”。該下游微服務(wù)將從對應(yīng)的OCSP響應(yīng)方處獲取OCSP響應(yīng)，以及staple，或者將響應(yīng)附加到證書本身當(dāng)中。由于OCSP響應(yīng)得到了對應(yīng)證書中心的簽名，因此該客戶端能夠驗(yàn)證通過其簽名并接收此響應(yīng)。這種方法令事情有了轉(zhuǎn)機(jī)，事實(shí)上如今是由服務(wù)而非客戶端與OCSP響應(yīng)方進(jìn)行通信。不過在TLS相互驗(yàn)證模式下，OCSP stapling相較于原始OCSP無法帶來任何額外優(yōu)勢。

由于OCPS必須配合stapling，該服務(wù)（即下游服務(wù)）需要向客戶端（即上游服務(wù)）提供保證，證明OCSP響應(yīng)被附加到了該服務(wù)在TLS握手時(shí)接收到的證書中。如果OCSP響應(yīng)未被附加至該證書中，那么結(jié)果并非出現(xiàn)軟錯誤，而是客戶端必須立即拒絕該連接。

從最終用戶的角度來看，臨時(shí)證書的效果與目前的常規(guī)證書并無區(qū)別，只不過暫時(shí)證書的過期時(shí)間非常之短。TLS客戶端并不需要針對臨時(shí)證書進(jìn)行CRL或者OCSP驗(yàn)證，而是堅(jiān)持設(shè)定好的過期時(shí)間，并對證書本身進(jìn)行時(shí)間戳加蓋。

臨時(shí)證書帶來的最大挑戰(zhàn)在于其部署與維護(hù)工作。自動則正是解決這些難題的靈丹妙藥。Netflix公司建議使用分層方案以構(gòu)建臨時(shí)證書部署機(jī)制。大家可以在TPM（即受信平臺模塊）或者SGX（軟件保護(hù)擴(kuò)展）當(dāng)中獲得系統(tǒng)身份或者長期證書，從而顯著提升安全性。在此之后，再使用這些憑證作為臨時(shí)證書。最后，在微服務(wù)中使用臨時(shí)證書——這些證書亦可由其它微服務(wù)使用。每項(xiàng)微服務(wù)都能夠利用自身長期證書對臨時(shí)證書進(jìn)行定期刷新。當(dāng)然，僅僅擁有臨時(shí)證書還不夠——托管該服務(wù)（或者TLS終止器）的主機(jī)應(yīng)當(dāng)支持對服務(wù)器證書的動態(tài)更新。目前存在大量能夠運(yùn)行服務(wù)器證書動態(tài)重載的TLS終止器，但其中大多數(shù)可能會導(dǎo)致短暫的服務(wù)停機(jī)。

微服務(wù)集與外部世界的連通一般經(jīng)由API網(wǎng)關(guān)模式實(shí)現(xiàn)。利用API網(wǎng)關(guān)模式，需要進(jìn)行聲明的微服務(wù)能夠在該網(wǎng)關(guān)內(nèi)獲得對應(yīng)的API。當(dāng)然，并不是所有微服務(wù)都需要立足于API網(wǎng)關(guān)實(shí)現(xiàn)聲明。

最終用戶對微服務(wù)的訪問（通過API實(shí)現(xiàn)）應(yīng)當(dāng)在邊界或者API網(wǎng)關(guān)處進(jìn)行驗(yàn)證。目前最為常見的API安全保護(hù)模式為OAuth 2.0。

OAuth 2.0是一套作為訪問代表的框架。它允許某方對另一方進(jìn)行某種操作。OAuth 2.0引入了一系列g(shù)rant types。其中之一用于解釋協(xié)議，客戶端可利用此協(xié)議獲取資源擁有方的許可，從而代表擁有方進(jìn)行資源訪問。另外，還有部分grant types可解釋用于獲取令牌的協(xié)議，且整個操作完全等同于由資源擁有方執(zhí)行——換言之，該客戶在這種情況下即相當(dāng)于資源擁有方。以下示意圖解釋了OAuth 2.0協(xié)議的宏觀實(shí)現(xiàn)流程。其中描述了OAuth客戶端、資源擁有方、驗(yàn)證服務(wù)器以及資源服務(wù)器之間的交互方式。

要想通過API網(wǎng)關(guān)訪問某項(xiàng)微服務(wù)，請求發(fā)起方必須首先獲得有效的OAuth令牌。系統(tǒng)能夠以自身角色訪問微服務(wù)，也可以作為其他用戶實(shí)現(xiàn)訪問。對于后一種情況，假設(shè)用戶登錄至某Web應(yīng)用，那么此后該Web應(yīng)用即可以所登錄用戶的身份進(jìn)行微服務(wù)訪問。

下面來看端到端通信的具體實(shí)現(xiàn)方式，如上圖所顯示：

用戶通過Identity Provider登錄至Web應(yīng)用/移動應(yīng)用，而Web應(yīng)用/移動應(yīng)用則通過OpenID Connect（也可以是SAML 2.0）信任該P(yáng)rovider。

該Web應(yīng)用獲取一條OAuth 2.0 access_token與一條id_token。其中id_token將驗(yàn)證訪問該Web應(yīng)用的最終用戶。如果使用SAML 2.0，則該Web應(yīng)用需要與其信任的OAuth驗(yàn)證服務(wù)器的token端點(diǎn)進(jìn)行通信，同時(shí)將SAML令牌交換為一條OAuth acess_token，隨后交換OAuth 2.0的SAML 2.0 grant type。

該Web應(yīng)用會作為最終用戶調(diào)用一個API——并隨同API請求發(fā)送access_token。

API網(wǎng)關(guān)會攔截來自該Web應(yīng)用的請求，提取access_token，與令牌交換端點(diǎn)（或者STS）進(jìn)行通信，并由后者驗(yàn)證該acess_token，而后向該API網(wǎng)關(guān)提供JWT（由其簽名）。此JWT還攜帶有用戶上下文。在STS對acess_token進(jìn)行驗(yàn)證時(shí)，其還將通過introspection API與對應(yīng)的OAuth授權(quán)服務(wù)器進(jìn)行通信。

API網(wǎng)關(guān)向下游微服務(wù)將同時(shí)發(fā)出請求與JWT。

每項(xiàng)微服務(wù)都會驗(yàn)證其接收到的JWT，而后作為下游服務(wù)調(diào)用，其能夠創(chuàng)建新的自簽名JWT并將其與該請求一同發(fā)送。在其它方案中，亦會用到嵌套JWT——即由新的JWT攜帶上一JWT。

在上述流程當(dāng)中，來自外部客戶端的API請求將經(jīng)由該API網(wǎng)關(guān)。當(dāng)某項(xiàng)微服務(wù)與其它微服務(wù)通信時(shí)，其將不再需要經(jīng)過該網(wǎng)關(guān)。另外，從特定微服務(wù)的角度來看，無論大家是從外部客戶端還是其它微服務(wù)處獲取請求，獲得的都是JWT——也就是說，這是一種對稱安全模式。

授權(quán)屬于一項(xiàng)業(yè)務(wù)功能。每項(xiàng)微服務(wù)可以決定使用何種標(biāo)準(zhǔn)以允許各項(xiàng)訪問操作。從簡單的授權(quán)角度來講，我們可以檢查特定用戶是否向特定資源執(zhí)行了特定操作。將操作與資源加以結(jié)合，也就構(gòu)成了權(quán)限。授權(quán)檢查會評估特定用戶是否具備訪問特定資源的最低必要權(quán)限集合。該資源能夠定義誰可以進(jìn)行訪問，可在訪問中具體執(zhí)行哪些操作。為特定資源聲明必要權(quán)限可通過多種方式實(shí)現(xiàn)。

XACML已經(jīng)成為細(xì)粒度訪問控制領(lǐng)域的客觀標(biāo)準(zhǔn)。其引入的方式能夠代表訪問某種資源所需要的權(quán)限集，且具體方法采用基于XML的特定域語言（簡稱DSL）編寫而成。

上圖所示為XACML組件架構(gòu)。首先，策略管理員需要通過PAP（即策略管理點(diǎn)）定義XACML策略，而這些策略將被保存在策略存儲內(nèi)。要檢查特定實(shí)體是否擁有訪問某種資源的權(quán)限，PEP（即策略執(zhí)行點(diǎn)）需要攔截該訪問請求、創(chuàng)建一條XACML請求并將其發(fā)送至XACML PDP（即策略決策點(diǎn)）。該XACML請求能夠攜帶任何有助于在PDP上執(zhí)行決策流程的屬性。舉例來說，其能夠包含拒絕標(biāo)識符、資源標(biāo)識符以及特定對象將對目標(biāo)資源執(zhí)行的操作。需要進(jìn)行用戶授權(quán)的微服務(wù)則需要與該P(yáng)DP通信并從JWT中提取相關(guān)屬性，從而建立XACML請求。PIP（即策略信息點(diǎn)）會在PDP發(fā)現(xiàn)XACML請求中不存在策略評估所要求的特定屬性時(shí)介入。在此之后，PDP會與PIP通信以找到缺失的對應(yīng)屬性。PIP能夠接入相關(guān)數(shù)據(jù)存儲，找到該屬性而后將其返回至PDP。

遠(yuǎn)程PDP模式存在幾大弊端，其可能與微服務(wù)的基本原則發(fā)生沖突：

性能成本：每一次被要求執(zhí)行訪問控制檢查時(shí)，對應(yīng)微服務(wù)都需要通過線纜與PDP進(jìn)行通信。當(dāng)該決策被緩存在客戶端時(shí)，此類傳輸成本與策略評估成本將得到有效降低。不過在使用緩存機(jī)制時(shí)，我們亦有可能根據(jù)陳舊數(shù)據(jù)進(jìn)行安全決策。

策略信息點(diǎn)（簡稱PIP）的所有權(quán)：每項(xiàng)微服務(wù)都應(yīng)當(dāng)擁有自己的PIP，其了解要從哪里引入實(shí)現(xiàn)訪問控制所必需的數(shù)據(jù)。在以上方案中，我們建立起的一套“整體式”PDP，其中包含全部PIP——對應(yīng)全部微服務(wù)。

如上圖所示，嵌入式PDP將遵循一類事件模式，其中每項(xiàng)微服務(wù)都會訂閱其感興趣的主題以從PAP處獲取合適的訪問控制策略，而后更新其內(nèi)嵌PDP。大家可以通過微服務(wù)組或者全局多租戶模型獲取PAP。當(dāng)出現(xiàn)新策略或者策略存在更新時(shí)，該P(yáng)AP會向?qū)?yīng)的主題發(fā)布事件。

這套方案不會違反微服務(wù)中的“服務(wù)器不變”原則?！胺?wù)器不變”意味著當(dāng)大家在持續(xù)交付流程結(jié)尾處，直接利用加載自庫的配置構(gòu)建服務(wù)器或者容器時(shí)，整個創(chuàng)建流程應(yīng)該能夠基于同樣的配置進(jìn)行不斷重復(fù)。因此，我們不希望任何用戶登入服務(wù)器并對配置做出變更。在內(nèi)嵌PDP模式下，盡管服務(wù)器會加載對應(yīng)的策略，但其仍同時(shí)處于運(yùn)行當(dāng)中。這意味著當(dāng)我們啟動新容器時(shí)，其仍然立足于同樣的策略集。

在結(jié)束本篇文章之前，我們還有另一個重要的問題需要回答，即API網(wǎng)關(guān)在授權(quán)上下文中到底扮演著怎樣的角色。我們可以設(shè)置全局可訪問的訪問控制策略——其可用于最終用戶，并由網(wǎng)關(guān)進(jìn)行強(qiáng)制執(zhí)行——但無法設(shè)置服務(wù)層級的策略。因?yàn)轭櫭剂x，服務(wù)層策略必須在服務(wù)層上執(zhí)行。