實(shí)現(xiàn)一個(gè)微服務(wù)很難。部署一個(gè)微服務(wù)應(yīng)用程序復(fù)雜性也很高。保護(hù)微服務(wù)的安全就更難更復(fù)雜。從哪里開(kāi)始呢?腦海中首先出現(xiàn)的一些詞是身份驗(yàn)證和授權(quán)、防火墻、授信、會(huì)話(huà)、令牌。我們需要保護(hù)應(yīng)用程序的安全，也需要保護(hù)容器的安全。
保護(hù)應(yīng)用程序
一種方法是構(gòu)建一個(gè)單點(diǎn)登錄(SSO)網(wǎng)關(guān),像普通的網(wǎng)關(guān)一樣，它位于應(yīng)用程序的前端，但需要考慮到其與SSO服務(wù)器的握手，并執(zhí)行URL重定向操作。可以用http報(bào)文頭傳送授權(quán)和認(rèn)證信息給服務(wù)。但是除非使用https，否則這樣做是不安全的。但是我們知道https有證書(shū)，維護(hù)多個(gè)微服務(wù)的證書(shū)可能會(huì)成為問(wèn)題，尤其是需要補(bǔ)發(fā)或撤銷(xiāo)這些證書(shū)的時(shí)候，復(fù)雜性將進(jìn)一步增加，我們盡量避免這種情況。
另一種方法是用HMAC(基于哈希的消息代碼)。這個(gè)請(qǐng)求的主體帶有哈希私鑰，結(jié)果是隨著請(qǐng)求發(fā)送的。然后，服務(wù)器通過(guò)使用其私鑰和請(qǐng)求主體的副本重新創(chuàng)建哈希，并將其與接收到的哈希進(jìn)行比較。如果一切都匹配，那就意味著消息沒(méi)有被篡改，請(qǐng)求可以通過(guò)。這種模式由JWT(Json Web Tokens)實(shí)現(xiàn)。但是，事實(shí)上網(wǎng)絡(luò)偵聽(tīng)器仍然可以看到數(shù)據(jù)。
Twitter，Google等使用API密鑰。使用API密鑰，服務(wù)可以識(shí)別誰(shuí)在調(diào)用，并可以對(duì)其設(shè)置限制。密鑰是成對(duì)的(公鑰和私鑰)，它們必須集中管理。
假定一切都準(zhǔn)備就緒了，但是還是有一個(gè)問(wèn)題，如何確保用戶(hù)無(wú)法訪問(wèn)其他用戶(hù)的數(shù)據(jù)呢?那就需要做更多的限制，可以通過(guò)限定用戶(hù)只能訪問(wèn)他自己的數(shù)據(jù)來(lái)保護(hù)我們的服務(wù)，但是將導(dǎo)致在許多地方產(chǎn)生大量的樣板代碼。不幸的是，沒(méi)有更好的辦法。微服務(wù)意味著復(fù)雜性和一些重復(fù)預(yù)期會(huì)被減少。
還是沒(méi)有解決嗅探器(sniffer，也叫數(shù)據(jù)抓包軟件)的問(wèn)題。怎樣才能確保sniffer看不到數(shù)據(jù)呢。答案是加密。先加密，然后根據(jù)需要進(jìn)行解密。這就是微服務(wù)復(fù)雜系統(tǒng)的另一個(gè)組件：密鑰服務(wù)。
有很多庫(kù)可以用，好的選擇是使用成熟的庫(kù)，如OAuth或SAML。
服務(wù)可以有狀態(tài)參數(shù)。為網(wǎng)關(guān)中初始化的所有服務(wù)保持一個(gè)全局會(huì)話(huà)，并將其傳播到所有其它服務(wù)。會(huì)話(huà)可以從像KeyCloak這樣的中央認(rèn)證和授權(quán)服務(wù)器(SSO)獲得。
我們更希望服務(wù)沒(méi)有狀態(tài)參數(shù)。這意味著需要將狀態(tài)從服務(wù)器轉(zhuǎn)移到客戶(hù)端。Json的 Web令牌(JWT)非常符合這種需求。這是一種在雙方之間轉(zhuǎn)移聲明的安全方式。基本上它的一個(gè)json作為Json Web簽名(JWS)的主體或Json Web加密(JWE)的明文傳遞。聲明可以進(jìn)行數(shù)字簽名，并包含發(fā)行者，用戶(hù)的身份，到期時(shí)間，還可以包含自定義屬性。
客戶(hù)端應(yīng)用程序?qū)⑴c UAA (用戶(hù)認(rèn)證和授權(quán))服務(wù)器進(jìn)行交互。它為包含一個(gè)JWT令牌的重定向URL交換其證書(shū)。令牌將提交到 網(wǎng)關(guān) ，在UAA服務(wù)器進(jìn)行驗(yàn)證。如果一切正常，它會(huì)將該JWT令牌轉(zhuǎn)發(fā)到所請(qǐng)求的服務(wù)，將會(huì)解碼它并授予其對(duì)所請(qǐng)求資源的訪問(wèn)權(quán)限。
保護(hù)容器
現(xiàn)在已經(jīng)知道如何保護(hù)應(yīng)用程序了，是時(shí)候關(guān)注容器的安全了。Docker是一個(gè)廣泛使用的容器?？梢宰鲂┦裁磥?lái)保護(hù)它們呢?
答案是深度防御。這意味著需要防火墻;這意味著需要小心記錄在日志中的信息(被攻擊后，日志有助于快速恢復(fù)系統(tǒng));這意味著需要監(jiān)視集群的可疑行為(入侵檢測(cè)系統(tǒng)和入侵防御系統(tǒng));這意味著需要將服務(wù)分開(kāi)并將它們放在不同的位置(虛擬私有云)，并創(chuàng)建一組規(guī)則，確保它們?nèi)匀荒軌蛳嗷ネㄐ?這意味著保持操作系統(tǒng)更新(特別是安全更新)。
Aaron Grattafiori在Docker Con 2016年的演講中談到三個(gè)原則：
    小權(quán)限 原則，這意味著不以root身份運(yùn)行應(yīng)用程序
    小意外 原則
    小訪問(wèn) 原則，這意味著每個(gè)模塊只能訪問(wèn)與其相關(guān)的數(shù)據(jù)
假設(shè)已經(jīng)遵循了上述三原則，想到的下一個(gè)問(wèn)題是：使用的Docker圖像安全嗎?怎么知道它們沒(méi)有包含惡意代碼呢?幸運(yùn)的是，在Docker 1.8中引入了 Docker Content Trust ，與此同時(shí)，Docker圖像的發(fā)布者在將其推送到注冊(cè)表之前進(jìn)行了驗(yàn)證。
保護(hù)Docker安全的一個(gè)有用的工具是 Calico 。每個(gè)Docker網(wǎng)絡(luò)都有Calico配置文件，必須設(shè)置規(guī)則和策略以控制流量。更多相關(guān)內(nèi)容看 這里 。
現(xiàn)在你應(yīng)該有足夠的信息來(lái)啟動(dòng)你的微服務(wù)安全保護(hù)了。