摘要：傳遞與雙向聯(lián)邦和具有與聯(lián)邦相同的，稱為跨領(lǐng)域信任。在中，彼此不完全信任的組織可能仍希望聯(lián)邦其信任域。為此，他們聯(lián)邦各自的信任域。這意味著檢查百事可樂不是被可口可樂的簽名。

作者：Daniel Feldman

聯(lián)邦信任域是SPIFFE和SPIRE最高需求和活躍開發(fā)的功能之一。在這篇博文中，我將概述我們當(dāng)前的計(jì)劃以及實(shí)施它的挑戰(zhàn)。

SPIFFE信任域中的證書共享一個(gè)信任根。 這是一個(gè)根信任捆綁包，由使用非標(biāo)準(zhǔn)化格式和協(xié)議在控制平面之間和內(nèi)部共享的多個(gè)證書組成。

然而，這還不夠好。許多組織都有多個(gè)信任根源：可能是因?yàn)樗麄兣c不同的管理員有不同的組織劃分，或者因?yàn)樗麄冇信紶栃枰獪贤ǖ莫?dú)立的臨時(shí)和生產(chǎn)環(huán)境。類似的用例是組織之間的SPIFFE互操作性，例如云供應(yīng)商與其客戶之間的互操作性。這兩種用例都需要一個(gè)定義明確、可互操作的方法，以便一個(gè)信任域中的工作負(fù)載對(duì)不同信任域中的工作負(fù)載進(jìn)行身份驗(yàn)證。這是聯(lián)邦。

要實(shí)現(xiàn)聯(lián)邦，我們必須在不同的SPIFFE服務(wù)器之間共享公鑰。這不是一次性操作；由于密鑰輪換，每個(gè)信任域的公鑰會(huì)定期更改。每個(gè)聯(lián)邦域必須定期下載其他域的公鑰，其頻率至少與密鑰輪換一樣快。

定期下載證書的數(shù)據(jù)格式尚未最終確定。我們目前的想法是讓SPIFFE的實(shí)現(xiàn)去使用JWKS格式，在一個(gè)眾所周知的URL上公開發(fā)布證書。然后，要啟動(dòng)聯(lián)邦關(guān)系，實(shí)現(xiàn)可以下載JWKS數(shù)據(jù)，并從中導(dǎo)入證書。

我們喜歡JWKS，因?yàn)樗且环N通用的、可擴(kuò)展的格式，用于共享可以容納JWT和X.509證書的密鑰信息。（出于安全原因，SPIFFE需要不同的JWT和X.509標(biāo)識(shí)的密鑰材料 - 它們不能只是以不同格式編碼的相同公鑰。）JWKS的靈活性允許單個(gè)聯(lián)邦A(yù)PI支持JWT和X.509 。

SPIFFE工作負(fù)載API提供用于讀取聯(lián)邦公鑰的端點(diǎn)。此API與用于讀取當(dāng)前信任域的證書的API不同，所以應(yīng)用程序可以區(qū)分本地和聯(lián)邦域的客戶端。

雖然它尚未正式標(biāo)準(zhǔn)化為SPIFFE的一部分，但是SPIRE已經(jīng)可以提供JWKS的實(shí)驗(yàn)性實(shí)施。

聯(lián)邦A(yù)PI存在引導(dǎo)問題：如果雙方都沒有共享信任根，則無法建立初始安全連接。其一種解決方案，是使用兩個(gè)SPIFFE服務(wù)器信任的證書頒發(fā)機(jī)構(gòu)的Web PKI。另一種解決方案，是使用手動(dòng)身份驗(yàn)證機(jī)制來消除對(duì)公共證書頒發(fā)機(jī)構(gòu)（CA）的需求。

SPIRE使用與節(jié)點(diǎn)和工作負(fù)載注冊(cè)類似的方式實(shí)現(xiàn)聯(lián)邦。隨著我們擴(kuò)展注冊(cè)API，可以通過該API操作聯(lián)邦，就像節(jié)點(diǎn)和工作負(fù)載注冊(cè)一樣。

每次SPIFFE實(shí)現(xiàn)，從同等的SPIFFE實(shí)現(xiàn)，導(dǎo)入新證書時(shí)，它都會(huì)使用上一個(gè)已知捆綁包對(duì)連接進(jìn)行身份驗(yàn)證。如果網(wǎng)絡(luò)中斷很長，并且兩個(gè)SPIFFE實(shí)現(xiàn)無法通信，超過完整的密鑰輪換周期，那么它們將無法繼續(xù)進(jìn)行通信，從而破壞了聯(lián)邦關(guān)系。

其一種解決方案，是將密鑰輪換間隔，設(shè)置為長于可能的最長網(wǎng)絡(luò)中斷長度（或者如果發(fā)生長中斷，則重新初始化聯(lián)邦）。這是設(shè)計(jì)權(quán)衡：如果密鑰輪換間隔較長，則受損密鑰也將在較長時(shí)間內(nèi)保持有效。

或者，如果Web PKI可用于SPIFFE服務(wù)器，則可用于保護(hù)聯(lián)邦連接。我們相信聯(lián)邦SPIFFE服務(wù)器之間的Web PKI，將是一種常見的設(shè)計(jì)模式，因?yàn)樗苊饬碎L網(wǎng)絡(luò)中斷導(dǎo)致密鑰輪換的問題。

Kerberos和Active Directory具有與聯(lián)邦相同的，稱為“跨領(lǐng)域信任”。在大多數(shù)情況下，跨領(lǐng)域信任是雙向的（雙方互相信任）和傳遞（如果A信任B，B信任C，然后A信托C）。

SPIFFE中的雙向聯(lián)邦通常（但并非總是如此）是可取的。對(duì)于公共API，API提供程序可能希望使用Web PKI來保護(hù)連接的服務(wù)器端，并使用SPIFFE來保護(hù)客戶端。因此，我們不會(huì)自動(dòng)配置雙向聯(lián)邦。

對(duì)于具有許多信任域的大型組織，傳遞聯(lián)邦可以簡化實(shí)現(xiàn)復(fù)雜性。但是，傳遞聯(lián)邦可能難以推斷SPIFFE實(shí)現(xiàn)的安全屬性。出于這個(gè)原因，我們現(xiàn)在沒有在SPIFFE中實(shí)現(xiàn)傳遞聯(lián)邦。

目前，用戶必須通過添加更多聯(lián)邦關(guān)系，來手動(dòng)配置傳遞和雙向聯(lián)邦。

在Web PKI中，每個(gè)人都信任相同的根證書頒發(fā)機(jī)構(gòu)。在SPIFFE中，彼此不完全信任的組織可能仍希望聯(lián)邦其信任域。應(yīng)用程序必須驗(yàn)證每個(gè)SVID是否由擁有該信任域的SPIFFE服務(wù)器頒發(fā)。

想象一個(gè)奇怪的世界，可口可樂和百事可樂必須交換數(shù)據(jù)。為此，他們聯(lián)邦各自的信任域?？煽诳蓸返腟PIFFE證書根，添加到百事可樂的信托商店，反之亦然。在證書驗(yàn)證的簡單實(shí)現(xiàn)中，可口可樂服務(wù)器可以欺騙性地冒充百事可樂網(wǎng)絡(luò)上的百事可樂服務(wù)器，因?yàn)榘偈驴蓸沸湃慰煽诳蓸返母C書！

這是問題所在：根證書沒有“范圍”。任何CA都可以為任何名稱簽署證書。如果所有CA都受信任，例如在單個(gè)公司內(nèi)，則可以。在具有多個(gè)CA的環(huán)境中，每個(gè)CA都應(yīng)該只允許簽署具有特定名稱的證書，不然這會(huì)導(dǎo)致安全漏洞。

防止這種情況的一種方法是使用X.509名稱約束擴(kuò)展。名稱約束擴(kuò)展允許將CA證書限制為為特定域名頒發(fā)證書。但是，在TLS庫中對(duì)名稱約束擴(kuò)展的支持是有限的，并且它不能解決未來SPIFFE身份格式（如JWT）的問題。由于這些原因，SPIFFE不包括名稱約束擴(kuò)展。

這意味著所有使用SVID的應(yīng)用程序都必須檢查SVID中的SPIFFE ID，是否與簽署證書的實(shí)際CA的信任域匹配。這意味著檢查百事可樂SVID不是被可口可樂的CA簽名。當(dāng)前廣泛使用的應(yīng)用程序（例如Web服務(wù)器和代理）不執(zhí)行此檢查。

聯(lián)邦對(duì)于SPIFFE的成功實(shí)施至關(guān)重要。但是，以安全和可用的方式實(shí)施它仍然存在挑戰(zhàn)。我們正在努力與社區(qū)一起努力應(yīng)對(duì)這些挑戰(zhàn)，如果您有遠(yuǎn)見，我們很樂意聽取您的意見！

要了解有關(guān)SPIFFE聯(lián)邦的更多信息：

查看新的Java SPIFFE Federation Demo，它演示了在Tomcat服務(wù)器環(huán)境中使用SPIRE在兩個(gè)域之間進(jìn)行聯(lián)邦。

加入SPIFFE Slack與專家討論SPIFFE。

加入SPIFFE SIG-SPEC雙月會(huì)議，設(shè)計(jì)SPIFFE聯(lián)邦會(huì)的未來。 （不久將有一個(gè)多帶帶的聯(lián)邦工作組。）