后端容器運行時安全云原生【免費下載鏈接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI項目地址https://gitcode.com/gh_mirrors/sa/sandstorm點擊查看免費下載Blackrock 是 Sandstorm 項目為托管服務與企業(yè)級部署設計的集群管理技術(shù)它讓一整個數(shù)據(jù)中心內(nèi) 2 到約 2^16 臺同地協(xié)作的機器或虛擬機實例對外呈現(xiàn)為一個Sandstorm 實例用戶界面與單機版幾乎無差別。本文以 roadmap/blackrock/README.md 為骨架結(jié)合倉庫內(nèi)src/sandstorm/與shell/下的真實實現(xiàn)系統(tǒng)講解 Blackrock 的設計目標、七大機器角色、基于 Capn Proto 的自定義網(wǎng)絡協(xié)議與 SturdyRef 持久化能力模型并逐條標注哪些設計已實現(xiàn)、哪些仍停留在路線圖階段幫助讀者完整理解 Sandstorm 從單機走向橫向擴展集群的演進思路。Blackrock 在 Sandstorm 生態(tài)中的定位在 roadmap/README.md 中Blackrock 被明確定義為 the cluster management technology underlying managed hosting and our eventual enterprise product托管服務與企業(yè)級產(chǎn)品底層的集群管理技術(shù)。也就是說它是 Sandstorm 平臺三大技術(shù)方向之一與平臺核心功能Platform、自托管體驗Self-hosting并列。從運維視角看Sandstorm 默認架構(gòu)是單機部署docs/administering/hosting-provider.md 明確指出 Sandstorm runs on a single server, due to its architecture單機模式下提升用戶數(shù)的主要手段是縱向擴容內(nèi)存RAM is the primary bottleneck。而當托管商需要服務成千上萬用戶時就需要橫向擴展方案——Sandstorm.io 團隊運營的 oasis.sandstorm.io 正是使用代號 Blackrock 的這套 scale-out 軟件棧。該文檔同時提醒Blackrock 遠不如標準 Sandstorm 開箱即用far less turn-key托管商若采用它通常需要與 Sandstorm 開發(fā)者緊密協(xié)作并自行編寫額外代碼更好的路徑是先跑單機需要時再遷移到 Blackrock。Blackrock 的設計目標Goals完整列舉如下將 2 到約 2^16 臺同地協(xié)作的機器或 VM 實例視為一個Sandstorm 實例用戶界面與單機 Sandstorm 基本一致強制實施按用戶或許還按應用的存儲空間與內(nèi)存配額支持機器動態(tài)加入或移出集群機器角色由集群自動分配并隨需更新任何一臺機器宕機都不造成用戶中斷或數(shù)據(jù)丟失在機器之間遷移 grains沙箱化應用實例以平衡負載、優(yōu)化資源共享例如共享應用二進制文件通過避免可疑應用與高價值目標同機部署、監(jiān)控主機可疑行為、定期清空并重啟單臺機器緩解沙箱逃逸風險在可用時利用廉價的對象存儲。同時文檔明確劃定了非目標不支持地理位置分散的機器組成單實例——Blackrock 針對的是同一數(shù)據(jù)中心、同一 LAN 內(nèi)的機器跨集群移動應用應使用 Sandstorm 常規(guī)的聯(lián)邦federation能力。機器角色體系同一鏡像、多角色分配Blackrock 集群中的所有機器都啟動同一份只讀操作系統(tǒng)鏡像鏡像內(nèi)包含全部 Blackrock 平臺軟件機器啟動后由集群主控master為其分配一個或多個角色。這種統(tǒng)一鏡像 動態(tài)角色的設計直接支撐了機器動態(tài)加入/移出、角色自動調(diào)整的目標——沒有角色固化在鏡像里一切以運行時分配為準。整個角色體系分為八類Master主控、Storage存儲、Workers工作機、Coordinators協(xié)調(diào)器TODO、Shells又名 Front-ends前端、Mongo數(shù)據(jù)庫、Gateways網(wǎng)關(guān)、Log sink日志匯聚TODO。Master集群的角色分配與拓撲中樞每個集群有且僅有一臺 master。其職責包括為所有其他機器分配角色監(jiān)控全集群資源使用情況動態(tài)決策資源分配去向當機器規(guī)格異構(gòu)時依據(jù)硬件特性分配合適角色——例如內(nèi)存巨大的機器應做 worker磁盤巨大的機器應做 storage負責向所有其他機器通報應該與哪些對端通信的拓撲信息——例如新增一臺存儲節(jié)點后master 會更新所有可能用到存儲的機器使它們把新節(jié)點加入各自的負載均衡池。關(guān)鍵可靠性設計是master 不在任何單次請求的服務關(guān)鍵路徑上。若 master 宕機集群其余部分可以按照最近一次分配的角色繼續(xù)運行等待 master 恢復。這與單臺機器死亡不造成用戶中斷的目標直接呼應。Storage對象存儲之上的能力化加密代理存儲節(jié)點對外提供所有持久化存儲的接口。文檔特別強調(diào)術(shù)語區(qū)分存儲節(jié)點storage node通常并不直接操作磁盤而是充當某個傳統(tǒng)對象存儲系統(tǒng)如 S3的代理真正的物理存儲應稱為disks磁盤。引入這層代理而非讓其他機器直連磁盤目的有三實現(xiàn)基于 Capn Proto 持久化層的能力化capability-based對象圖存儲接口——存儲的不是扁平文件而是相互引用、可沿對象圖遍歷的能力對象實現(xiàn)逐對象加密每個對象擁有獨立加密密鑰這些密鑰本身作為訪問對象所需的 SturdyRef 的一部分保存。由于 SturdyRef 通常又存儲在其它已加密的對象中因此不沿對象圖從用戶持有的某個基礎能力出發(fā)就無法訪問任何對象。理論上這些基礎能力甚至可以用用戶的 GPG 密鑰加密保存實現(xiàn)完美加密存儲保護訪問磁盤所需的憑據(jù)如 S3 憑據(jù)使磁盤端無需被信任即可保證隱私。文檔給出的候選后端disk 層包括Amazon S3、Google Cloud Storage、Tahoe-LAFS以及一種利用本地集群所有磁盤的分布式文件系統(tǒng)。文檔還保留了項目自注的 TODO截至文檔記錄時當前存儲實現(xiàn)仍是單機寫本地磁盤依賴底層磁盤實現(xiàn)提供完整性、可靠性與備份Oasis 托管在 Google Compute Engine利用其持久磁盤與快照能力單機存儲層之所以能扛住大量負載是因為其工作基本只是讀寫塊。但存儲層應該被重寫以支持更好的可擴展性并在可用時利用廉價對象存儲。Workers運行 grain 的可疑機器與 nbd 塊設備worker 機器按照協(xié)調(diào)器coordinator見下文的指令運行 grains。由于存在沙箱逃逸的可能worker 機器應始終被懷疑對待整個 Blackrock 集群使用 Capn Proto 能力安全模型保證一臺被攻破的 worker 無法訪問除恰好運行在它上面的 grains 之外的任何東西worker 應定期輪換出勤、清空wipe防止惡意進程長期駐留worker 還應接受統(tǒng)計意義上的可疑活動監(jiān)控一旦發(fā)現(xiàn)立即移出輪換。worker 的關(guān)鍵存儲機制是每個 grain 的存儲通過nbdNetwork Block Device驅(qū)動掛載自一個用戶態(tài)實現(xiàn)的塊設備該用戶態(tài)守護進程把塊同步回存儲層。這套設計帶來兩個直接收益數(shù)據(jù)量大的 grain例如音樂庫可以從冷狀態(tài)快速啟動——按需on-demand拉取塊即可長期存儲可以保持接近最新狀態(tài)從而讓 worker 機器故障不至于造成過多數(shù)據(jù)丟失。與此同時內(nèi)核在塊設備之上實現(xiàn)了久經(jīng)考驗的緩存層頁面一旦緩存就能把運行時開銷降到最低。文檔還留下一個 TODO(feature)可以探索優(yōu)化初始加載時間的啟發(fā)式策略例如跟蹤啟動時常加載的塊并提前開始讀取并且 nbd 實現(xiàn)了 trim 命令可以用來跟蹤文件系統(tǒng)實際使用的塊、避免存儲無用數(shù)據(jù)。CoordinatorsTODO(feature)尚未實現(xiàn)的調(diào)度層截至文檔記錄2017 年 2 月協(xié)調(diào)器尚未實現(xiàn)——Currently frontends simply round-robin to workers當前前端只是對 worker 做輪詢。文檔中的協(xié)調(diào)器設計如下協(xié)調(diào)器告訴 worker 做什么要啟動新 grain 或啟動一個當前未運行的 grain必須先聯(lián)系協(xié)調(diào)器由它挑選合適的 worker 委派任務每個協(xié)調(diào)器維護一組 worker這些集合可以重疊也可以不重疊——可以是兩個協(xié)調(diào)器各監(jiān)控全部 worker也可以各監(jiān)控一半啟動 grain 的請求可交給任意協(xié)調(diào)器調(diào)用方應在它們之間做負載均衡協(xié)調(diào)器監(jiān)控其 worker 上的資源使用并在需要時下達 grain 遷移指令它應當考慮每個應用的典型資源占用以及該應用的可疑程度——可疑應用應與安全關(guān)鍵型應用隔離以緩解沙箱逃逸的影響。文檔評價該模塊有大量算法與啟發(fā)式策略的開發(fā)空間屬于路線圖中留白最多的領域。Shells又名 Front-endsMeteor 前端Shell 機器運行 Sandstorm shell UI——一個 Meteor 應用。代碼中這些機器被稱為 frontends前端文檔認為這個叫法其實并不準確an arguably incorrect name。在倉庫中shell/目錄正是這套 Meteor 應用其服務端入口位于 shell/server/main.ts客戶端入口在 shell/client/main.ts而 Blackrock 多副本場景下的能力路由基礎設施可見于 shell/imports/server/frontend-ref.js 與 shell/imports/server/core.js。后者實現(xiàn)了FrontendRefRegistry前端能力引用注冊表并圍繞frontendRef字段把前端提供的 Capn Proto 能力保存為可恢復的持久引用——例如 core.js 通過globalFrontendRefRegistry.restore(db, saveTemplate, token.frontendRef)恢復能力這正是多 shell 副本場景下路由能力所依賴的機制。另外 shell/imports/server/accounts/saml/saml-server.js 中還有一條注釋提醒某些狀態(tài)可能需要在 Blackrock 下改用 Mongo collection 才能在多前端場景工作。Mongo當前依賴與長期替換計劃由于 Sandstorm shell 當前依賴 Mongo 作為數(shù)據(jù)庫Blackrock 集群需要專門的 Mongo 機器運行該數(shù)據(jù)庫其中一臺為主master、其余為從slave。文檔列出兩項 TODOTODO(feature)數(shù)據(jù)庫也應同步回對象存儲TODO(project)長期來看應當用自有存儲接口替換 Mongo。這條依賴在倉庫中同樣可證shell/imports/server/core.js 有一段注釋專門處理 Fix Mongo converting Buffers to Uint8Arrays說明 shell 與 Mongo 的數(shù)據(jù)交互是實打?qū)嵉漠斍皩崿F(xiàn)細節(jié)。Gateways連接公網(wǎng)與集群內(nèi)部的橋網(wǎng)關(guān)gateway負責橋接公網(wǎng)或 Sandstorm 集群之外的更廣企業(yè)網(wǎng)絡工作拆分為幾塊接收入站 HTTP 請求、終結(jié) SSL、轉(zhuǎn)發(fā)給 shell 或直接轉(zhuǎn)發(fā)給 grains——這是已實現(xiàn)的核心職責TODO(feature)實現(xiàn)一套 Capn Proto 接口用于對外建立/接受 TCP 連接以及參與 UDP 流量這類連接將被禁止連到集群內(nèi)其他機器能力可交給設備驅(qū)動從而在不授予任何內(nèi)網(wǎng)訪問權(quán)限的情況下授予其外部網(wǎng)絡訪問TODO(feature)把 Capn Proto 本身代理到外部世界——內(nèi)部網(wǎng)絡與公網(wǎng)使用不同參數(shù)化的 Capn Proto 協(xié)議因此能力跨越邊界時必須被主動代理這同時也讓系統(tǒng)有機會把外部能力與內(nèi)部能力分開追蹤并向外部隱藏內(nèi)部 SturdyRef 表示作為額外一層安全。倉庫中網(wǎng)關(guān)的實現(xiàn)證據(jù)非常充分src/sandstorm/gateway.c 中的GatewayService是直接處理 HTTP 等流量的 C 代碼而路由決策通過 src/sandstorm/backend.capnp 定義的GatewayRouter接口回到 Sandstorm 業(yè)務邏輯Node.js 進程網(wǎng)關(guān)先連接 backend 獲得作為引導能力的GatewayRouter再通過openUiSession根據(jù) sandstorm-sid cookie 換取 WebSession、openApiSession根據(jù) Authorization 頭中的 token 換取 ApiSession等方法完成會話路由。backend.capnp中還明確注釋了 Blackrock 場景in Blackrock, where multiple instances of the shell might be running, all GatewayRouters are equivalent, regardless of which shell replica在 Blackrock 中即使運行多個 shell 副本所有 GatewayRouter 也都等價無論連到哪個副本——這是網(wǎng)關(guān)層與多副本 shell 解耦的直接依據(jù)。此外 src/sandstorm/config.c 中有一條配置日志 Gateway is no longer experimental. Disabling EXPERIMENTAL_GATEWAY is ...說明網(wǎng)關(guān)模塊已經(jīng)走出實驗階段。Log sinkTODO(feature)尚未實現(xiàn)的日志匯聚所有其他機器應向日志匯聚節(jié)點log sink匯聚日志以供分析。截至文檔記錄該功能尚未實現(xiàn)——Currently logs are collected and written to disk on the master machine當前日志由 master 機器收集并寫到本地磁盤。網(wǎng)絡與 Capn Proto 設計面向 LAN 的自定義協(xié)議Blackrock 集群使用一套為特定用例定制參數(shù)化的 Capn Proto RPC 協(xié)議。文檔先給出實現(xiàn)現(xiàn)狀注記截至 2017 年 2 月Capn Proto 仍運行在 TCP 之上且由于 3-party handoff三方交接尚未實現(xiàn)所有通信實際上都經(jīng) master 機器代理轉(zhuǎn)發(fā)——這顯然會在規(guī)模增長時成為瓶頸但當時運行平穩(wěn)。傳輸層TransportUDP 優(yōu)于 TCP 的理由Blackrock 假設內(nèi)部通信是近乎全連通的網(wǎng)狀fully-connected mesh——幾乎每臺機器都會向其他每臺機器偶發(fā)發(fā)消息。既然假定在同一 LAN 內(nèi)可以為此優(yōu)化使用UDP 而非 TCP丟包在 LAN 中很罕見UDP 可以避免每次想跟一臺尚未建立連接的機器通信都要做 TCP 握手該模型對臨時網(wǎng)絡抖動更魯棒對 Capn Proto 軟件來說斷連相當有破壞性因為所有未持久化的能力都會丟失而基于 UDP 可以輕松設計等待網(wǎng)絡恢復一段時間的策略。加密Cryptovat ID 與免握手的密鑰交換每個 vat能力網(wǎng)絡中的對等體/機器由唯一的vat ID標識。vat ID 實際上就是該 vat 自己生成的ed25519 公鑰——對應的私鑰絕不應離開生成它的機器且每當整機被清空時應一并丟棄。vat 可以通過對 challenge 簽名來證明自己擁有某個 vat ID。在多數(shù)情況下Blackrock 實例的內(nèi)部網(wǎng)絡可能不需要分組加密因為高端網(wǎng)絡硬件通常可被信任為只把包投遞給正確目的地。但如果需要加密最直接的方式是curve25519 密鑰交換兩個 vat 僅憑彼此知道對方的 vat ID以及各自的私鑰就能協(xié)商出共享秘密從而無需任何握手即可開始互發(fā)流量——這與 UDP 傳輸?shù)脑O計天然契合。持久能力SturdyRefs能力網(wǎng)絡的持久化基石在 Blackrock 網(wǎng)絡內(nèi)SturdyRef持久能力引用分為有限幾種類型Storage refs直接指向存儲中的對象由存儲節(jié)點恢復restoreGrain refs指向特定 grain 內(nèi)托管的 capability由協(xié)調(diào)器恢復External refs指向公網(wǎng)上的 capability由網(wǎng)關(guān)恢復Ephemeral refs指向某個特定 vat 上托管的 capability只能由該 vat 恢復這類 cap 天生短命因為 vat 本身短命頻繁輪換但它們能挺過重啟與進程崩潰比 live refs 更穩(wěn)固。每個 SturdyRef 都被密封sealed到請求創(chuàng)建它的 vat 所屬的trust zone信任區(qū)域并且只能由同一 trust zone 恢復——這防止了跨信任邊界泄漏的比特bits被利用。每個 vat 自身是一個 trust zone此外還有四個特殊區(qū)域storage、gateways、coordinators、shells。這四個分組內(nèi)的 vat 都能保存 SturdyRef使組內(nèi)任意其他成員之后可以恢復它們。SturdyRef 在倉庫源碼中有大量印證。在 src/sandstorm/supervisor.capnp 中注釋了 In the Sandstorm internal realm, the type of SturdyRefs themselves is simplyData并多處描述save()與restore()語義src/sandstorm/supervisor.c 中實現(xiàn)了把 token 設為 SturdyRef如setSturdyRef(args.getToken())、按SystemPersistent語義保存/恢復能力含sealFor信任區(qū)域邏輯等關(guān)鍵路徑src/sandstorm/sandstorm-http-bridge.c 中也能看到應用側(cè)尚未落盤、需要保存一個 SturdyRef的注釋。在 src/sandstorm/grain.capnp 中則詳細對比了授權(quán)碼authorization code與 SturdyRef 的區(qū)別并解釋為何避免讓應用直接拿到新鑄造的 SturdyRef——因為 SturdyRef 泄漏更危險攻擊者可能拿它發(fā)起偽造的 powerbox 請求。這些注釋共同表明SturdyRef 不是簡單的對象 ID而是密碼學安全、按信任區(qū)域密封的持久能力憑證這正是 Blackrock 對象圖存儲與 worker 不可信假設的安全基石。從路線圖到現(xiàn)狀實現(xiàn)狀態(tài)總覽原文檔以 TODO 標注的形式記錄了各模塊的實現(xiàn)進度。下表匯總各角色/功能的文檔標注狀態(tài)與倉庫中的佐證位置方便讀者對照模塊文檔標注狀態(tài)倉庫佐證Master已設計每集群單臺不在請求關(guān)鍵路徑見本文第 3 節(jié)Storage已實現(xiàn)為單機本地磁盤重寫為對象存儲代理屬 TODOsrc/sandstorm/backend.capnp配額/存儲接口Workers已實現(xiàn)nbd 塊設備 用戶態(tài)同步守護進程src/sandstorm/沙箱與橋接代碼Coordinators未實現(xiàn)前端輪詢 worker無對應實現(xiàn)Shells/Front-ends已實現(xiàn)Meteor 應用shell/client/main.ts、shell/imports/server/frontend-ref.jsMongo已實現(xiàn)一主多從替換為自有存儲屬 TODO(project)shell/imports/server/core.jsGatewaysHTTP/SSL 終結(jié)已實現(xiàn)TCP/UDP 接口與 Capn Proto 外部代理屬 TODO(feature)src/sandstorm/gateway.c、src/sandstorm/backend.capnpLog sink未實現(xiàn)日志暫寫 master 磁盤無對應實現(xiàn)傳輸層未實現(xiàn)當前 Capn Proto 走 TCP經(jīng) master 代理無 UDP 實現(xiàn)加密設計完成ed25519 vat ID curve25519 協(xié)商文檔為唯一來源SturdyRefs已實現(xiàn)save/restore、trust zone 密封src/sandstorm/supervisor.c、src/sandstorm/supervisor.capnp、src/sandstorm/grain.capnp需要強調(diào)的是roadmap/blackrock/README.md本身是技術(shù)路線圖文檔而非實現(xiàn)說明其中 Coordinators、Log sink、UDP 傳輸、外部 TCP/UDP 能力、Capn Proto 外部代理等條目均明確標注為 TODO讀者不應將之當作當前可用功能。而 Storage 的對象存儲代理 逐對象加密、SturdyRef 的 trust zone 模型等則在src/sandstorm/的 Capn Proto 模式與 C 實現(xiàn)中留下了可追溯的設計證據(jù)是理解 Sandstorm 能力安全模型從單機延伸到集群的關(guān)鍵。延伸閱讀roadmap/blackrock/README.md本文核心來源——Blackrock 完整路線圖原文roadmap/README.mdSandstorm 整體技術(shù)路線圖說明 Blackrock 與 Platform、Self-hosting 的關(guān)系及 TODO 分類約定project / feature / roadmapdocs/administering/hosting-provider.md托管商視角的 Blackrock 定位與部署建議單機起步、需要時遷移src/sandstorm/backend.capnpGatewayRouter接口定義及 Blackrock 多 shell 副本等價性注釋src/sandstorm/supervisor.capnp 與 src/sandstorm/grain.capnpSturdyRef 語義與授權(quán)碼/持久能力對比的權(quán)威注釋shell/imports/server/core.js 與 shell/imports/server/frontend-ref.js前端能力引用注冊表與 Mongo 依賴的實際代碼。贊分享后端容器運行時安全云原生【免費下載鏈接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI項目地址https://gitcode.com/gh_mirrors/sa/sandstorm點擊查看免費下載相關(guān)推薦Sandstorm 技術(shù)路線圖全景解讀平臺功能、Blackrock 集群與自托管生態(tài)Sandstorm 技術(shù)路線圖全景解讀平臺功能、Blackrock 集群與自托管生態(tài) Sandstorm 是一個可自托管的 Web 生產(chǎn)力套件本質(zhì)上是安全后端容器運行時安全云原生Sandstorm 平臺功能路線圖全解賬戶、應用、谷物與能力安全架構(gòu)Sandstorm 平臺功能路線圖全解賬戶、應用、谷物與能力安全架構(gòu) 本文以 Sandstorm 官方技術(shù)路線圖 roadmap/platform/READM后端容器運行時安全云原生Sandstorm 平臺級跨 Grain 全文搜索從安全索引架構(gòu)到 Lucene/Lucy 實現(xiàn)路線Sandstorm 平臺級跨 Grain 全文搜索從安全索引架構(gòu)到 Lucene/Lucy 實現(xiàn)路線 Sandstorm 是一個以安全隔離為核心的自托管 We后端容器運行時安全云原生上一篇Open edX Platform MFE 配置端點治理ADR 0035 確立 /api/frontend_site_config/v1/ 為規(guī)范端點下一篇企業(yè)法務智能化的架構(gòu)革新從模型選型到能力沉淀的范式重構(gòu)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考