研發中：聯邦SPIFFE信任域

做者：Daniel Feldman

介紹

聯邦信任域是SPIFFE和SPIRE最高需求和活躍開發的功能之一。在這篇博文中，我將概述咱們當前的計劃以及實施它的挑戰。

什麼是聯邦？

SPIFFE信任域中的證書共享一個信任根。 這是一個根信任捆綁包，由使用非標準化格式和協議在控制平面之間和內部共享的多個證書組成。

然而，這還不夠好。許多組織都有多個信任根源：多是由於他們與不一樣的管理員有不一樣的組織劃分，或者由於他們有偶爾須要溝通的獨立的臨時和生產環境。相似的用例是組織之間的SPIFFE互操做性，例如雲供應商與其客戶之間的互操做性。這兩種用例都須要一個定義明確、可互操做的方法，以便一個信任域中的工做負載對不一樣信任域中的工做負載進行身份驗證。這是聯邦。

聯邦設計

要實現聯邦，咱們必須在不一樣的SPIFFE服務器之間共享公鑰。這不是一次性操做；因爲密鑰輪換，每一個信任域的公鑰會按期更改。每一個聯邦域必須按期下載其餘域的公鑰，其頻率至少與密鑰輪換同樣快。

按期下載證書的數據格式還沒有最終肯定。咱們目前的想法是讓SPIFFE的實現去使用JWKS格式，在一個衆所周知的URL上公開發布證書。而後，要啓動聯邦關係，實現能夠下載JWKS數據，並從中導入證書。

咱們喜歡JWKS，由於它是一種通用的、可擴展的格式，用於共享能夠容納JWT和X.509證書的密鑰信息。（出於安全緣由，SPIFFE須要不一樣的JWT和X.509標識的密鑰材料 - 它們不能只是以不一樣格式編碼的相同公鑰。）JWKS的靈活性容許單個聯邦API支持JWT和X.509 。

工做負載API

SPIFFE工做負載API提供用於讀取聯邦公鑰的端點。此API與用於讀取當前信任域的證書的API不一樣，因此應用程序能夠區分本地和聯邦域的客戶端。

SPIRE的實驗支持

雖然它還沒有正式標準化爲SPIFFE的一部分，可是SPIRE已經能夠提供JWKS的實驗性實施。

挑戰

外部SPIFFE服務器的初始身份驗證

聯邦API存在引導問題：若是雙方都沒有共享信任根，則沒法創建初始安全鏈接。其一種解決方案，是使用兩個SPIFFE服務器信任的證書頒發機構的Web PKI。另外一種解決方案，是使用手動身份驗證機制來消除對公共證書頒發機構（CA）的需求。

SPIRE使用與節點和工做負載註冊相似的方式實現聯邦。隨着咱們擴展註冊API，能夠經過該API操做聯邦，就像節點和工做負載註冊同樣。

網絡中斷容錯

每次SPIFFE實現，從同等的SPIFFE實現，導入新證書時，它都會使用上一個已知捆綁包對鏈接進行身份驗證。若是網絡中斷很長，而且兩個SPIFFE實現沒法通訊，超過完整的密鑰輪換週期，那麼它們將沒法繼續進行通訊，從而破壞了聯邦關係。

其一種解決方案，是將密鑰輪換間隔，設置爲長於可能的最長網絡中斷長度（或者若是發生長中斷，則從新初始化聯邦）。這是設計權衡：若是密鑰輪換間隔較長，則受損密鑰也將在較長時間內保持有效。

或者，若是Web PKI可用於SPIFFE服務器，則可用於保護聯邦鏈接。咱們相信聯邦SPIFFE服務器之間的Web PKI，將是一種常見的設計模式，由於它避免了長網絡中斷致使密鑰輪換的問題。

傳遞與雙向聯邦

Kerberos和Active Directory具備與聯邦相同的，稱爲「跨領域信任」。在大多數狀況下，跨領域信任是雙向的（雙方互相信任）和傳遞（若是A信任B，B信任C，而後A信託C）。

SPIFFE中的雙向聯邦一般（但並不是老是如此）是可取的。對於公共API，API提供程序可能但願使用Web PKI來保護鏈接的服務器端，並使用SPIFFE來保護客戶端。所以，咱們不會自動配置雙向聯邦。

對於具備許多信任域的大型組織，傳遞聯邦能夠簡化實現複雜性。可是，傳遞聯邦可能難以推斷SPIFFE實現的安全屬性。出於這個緣由，咱們如今沒有在SPIFFE中實現傳遞聯邦。

目前，用戶必須經過添加更多聯邦關係，來手動配置傳遞和雙向聯邦。

聯邦信任域SVID的範圍

在Web PKI中，每一個人都信任相同的根證書頒發機構。在SPIFFE中，彼此不徹底信任的組織可能仍但願聯邦其信任域。應用程序必須驗證每一個SVID是否由擁有該信任域的SPIFFE服務器頒發。

想象一個奇怪的世界，可口可樂和百事可樂必須交換數據。爲此，他們聯邦各自的信任域。可口可樂的SPIFFE證書根，添加到百事可樂的信託商店，反之亦然。在證書驗證的簡單實現中，可口可樂服務器能夠欺騙性地冒充百事可樂網絡上的百事可樂服務器，由於百事可樂信任可口可樂的根證書！

這是問題所在：根證書沒有「範圍」。任何CA均可覺得任何名稱簽署證書。若是全部CA都受信任，例如在單個公司內，則能夠。在具備多個CA的環境中，每一個CA都應該只容許簽署具備特定名稱的證書，否則這會致使安全漏洞。

防止這種狀況的一種方法是使用X.509名稱約束擴展。名稱約束擴展容許將CA證書限制爲爲特定域名頒發證書。可是，在TLS庫中對名稱約束擴展的支持是有限的，而且它不能解決將來SPIFFE身份格式（如JWT）的問題。因爲這些緣由，SPIFFE不包括名稱約束擴展。

這意味着全部使用SVID的應用程序都必須檢查SVID中的SPIFFE ID，是否與簽署證書的實際CA的信任域匹配。這意味着檢查百事可樂SVID不是被可口可樂的CA簽名。當前普遍使用的應用程序（例如Web服務器和代理）不執行此檢查。

結論

聯邦對於SPIFFE的成功實施相當重要。可是，以安全和可用的方式實施它仍然存在挑戰。咱們正在努力與社區一塊兒努力應對這些挑戰，若是您有遠見，咱們很樂意聽取您的意見！

要了解有關SPIFFE聯邦的更多信息：

• 查看新的Java SPIFFE Federation Demo，它演示了在Tomcat服務器環境中使用SPIRE在兩個域之間進行聯邦。
• 加入SPIFFE Slack與專家討論SPIFFE。
• 加入SPIFFE SIG-SPEC雙月會議，設計SPIFFE聯邦會的將來。 （不久將有一個單獨的聯邦工做組。）