（Per-key KMS Authorization）：IAM 策略、內(nèi)置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解)
RustFS 每密鑰 KMS 授權(quán)Per-key KMS AuthorizationIAM 策略、內(nèi)置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本篇技術(shù)指南以 RustFS 操作文檔 docs/operations/kms-per-key-authorization.md 為主體結(jié)合 crates/policy 與 rustfs/src/admin/route_policy.rs 源碼系統(tǒng)講解 RustFS 如何基于身份策略identity policy對 KMS 密鑰做細粒度授權(quán)包括 KMS 資源 ARN 語法、內(nèi)置 KMS 角色模板、管理端點與 SSE-KMS 數(shù)據(jù)路徑兩層強制執(zhí)行以及從全集群共享密鑰權(quán)限平滑遷移到每密鑰授權(quán)的落地步驟。讀者讀完后可以獨立編寫限定到指定密鑰的 IAM 策略、正確組合內(nèi)置 KMS 角色并安全地開啟RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY數(shù)據(jù)面強制。RustFS 的 KMS 授權(quán)建立在身份策略之上一條 Statement 可以聲明它作用于哪些密鑰因此kms:DisableKey這樣的授權(quán)不再隱含集群內(nèi)所有密鑰一次 SSE-KMS 請求也會被拿實際解析到的密鑰來校驗。本文覆蓋資源語法、內(nèi)置角色模板、兩層強制執(zhí)行平面管理端點 SSE-KMS 數(shù)據(jù)路徑以及遷移路徑。關(guān)于各后端主密鑰master key材料存放位置參見 KMS 后端安全屬性管理 API 的完整端點矩陣見 KMS 管理 API 契約。KMS 資源語法KMS 資源使用與 S3 資源相同的空賬戶empty-accountARN 形式即arn:aws:kms:::之后直接跟資源段。下表為基本匹配規(guī)則模式匹配范圍arn:aws:kms:::key/key_id精確匹配該密鑰arn:aws:kms:::key/app-*匹配所有以app-開頭的 key idarn:aws:kms:::*匹配所有密鑰arn:aws:kms:::alias/name預留在別名解析alias resolution落地前不匹配任何請求以上語法并非文檔層面的約定而是 crates/policy/src/policy/resource.rs 中Resource::KMS_PREFIX、KMS_KEY_SEGMENT與KMS_ALIAS_SEGMENT三個常量定義的硬性規(guī)則請求側(cè) KMS 資源串總是key/key_id形式與這些模式逐一對齊alias/段雖可解析、可校驗但請求總是按key/key_id求值因此在別名解析功能落地前arn:aws:kms:::alias/*永遠不會匹配任何請求源碼注釋與測試kms alias never matches key均印證了這一點。該模塊對 KMS 資源還做了嚴格的格式校驗Validator for Resource裸*合法key/之后的 id 不能為空、不能包含/或\各 KMS 后端會拒絕含分隔符的密鑰名alias/之后的名稱不能為空、不能包含\但允許嵌套如alias/aws/s3。帶 region 與 account 的標準 AWS 形式如arn:aws:kms:us-east-1:123456789012:key/mykey會被拒絕——RustFS 使用空賬戶形式與 S3 資源保持一致。寫策略之前需要知道的規(guī)則一條 Statement 若混用kms:動作與s3:動作會被拒絕。KMS 授權(quán)必須放在獨立 Statement 中。一條 Statement 若攜帶 KMS 資源卻配非 KMS 動作會被拒絕。KMS Statement不寫資源時匹配所有密鑰——這是遺留形式且保持有效因此已有策略的效果不會改變。KMS Statement 的資源寫成 S3 ARN 時屬于早于 KMS 資源支持的舊策略。它仍可加載但 S3 模式從未真正約束過密鑰訪問求值時會忽略這些資源、把 Statement 當作未限定范圍unscoped處理并打印告警日志。建議用真正的 KMS 資源重寫這些策略。PutBucketPolicy會拒絕任何攜帶kms:動作或 KMS 資源的 Statement——KMS 授權(quán)只屬于身份identity不屬于桶策略。在此檢查之前已存儲的桶策略仍可加載求值時跳過其純 KMS Statement 并告警。與其他所有場景一致Deny優(yōu)先對arn:aws:kms:::key/payroll-*的Deny會覆蓋對arn:aws:kms:::*的Allow。參與匹配的 key id 是請求中直接指名的那個在別名解析之前。資源匹配采用通配符算法實現(xiàn)*、?等模式與 S3 資源共用同一套匹配邏輯路徑遍歷類輸入如key/mykey/../otherkey會被 clean 后拒絕匹配。完整的正反例可見 resource.rs 中的test_resource_is_match與test_kms_resource_parse測試。內(nèi)置 KMS 角色模板RustFS 在readwrite、readonly、writeonly、diagnostics與consoleAdmin之外還隨附三套 KMS 預置策略定義于 crates/policy/src/policy/policy.rs策略授予動作面向?qū)ο驥MSKeyAdministratorkms:DescribeKey、kms:ListKeys、kms:EnableKey、kms:DisableKey、kms:RotateKey、kms:DeleteKey負責密鑰生命周期治理的團隊KMSKeyUserkms:GenerateDataKey、kms:Decrypt、kms:DescribeKey讀寫 SSE-KMS 對象的工作負載KMSAuditorkms:DescribeKey、kms:ListKeys只需可見性、無需其他能力的審計人員這三套模板體現(xiàn)了職責分離separation of dutiesKMSKeyAdministrator可以禁用或刪除密鑰但永遠無法用它加解密KMSKeyUser可以使用密鑰但永遠無法改變其狀態(tài)。該約束由 policy.rs 中的模板測試逐一斷言例如KMSKeyAdministrator不允許kms:GenerateDataKey/kms:DecryptKMSKeyUser不允許kms:EnableKey/kms:DisableKey/kms:RotateKey/kms:DeleteKey。三個模板都不授予kms:Configure、kms:ServiceControl、kms:ClearCache、kms:Backup或kms:Restore。這些動作作用于 KMS 服務(wù)本身或一次性波及所有密鑰的材料屬于集群管理權(quán)限而非密鑰管理權(quán)限因此仍歸consoleAdmin所有。密鑰創(chuàng)建目前與kms:Configure共享后端配置動作所以創(chuàng)建密鑰同樣是consoleAdmin操作——這一點與 KMS 管理 API 契約 中POST /kms/keys映射到kms:Configure的端點矩陣一致。模板本身不帶任何 S3 或 admin 授權(quán)因此需要與數(shù)據(jù)面策略組合使用。策略映射policy mapping接受逗號分隔列表例如將KMSKeyUser與readwrite一并掛到某個用戶PUT /rustfs/admin/v3/set-user-or-group-policy?policyNamereadwrite,KMSKeyUseruserOrGroupapp-writerisGroupfalse三個模板默認也是未限定范圍的arn:aws:kms:::*與其他預置策略行為一致。要實現(xiàn)最小權(quán)限應(yīng)復制一份并按工作負載收窄例如{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [s3:*], Resource: [arn:aws:s3:::reports, arn:aws:s3:::reports/*] }, { Effect: Allow, Action: [kms:GenerateDataKey, kms:Decrypt, kms:DescribeKey], Resource: [arn:aws:kms:::key/reports-*] } ] }注意這里的 KMS 與 S3 授權(quán)被拆成了兩條獨立 Statement——這正是前述KMS 動作不得與 S3 動作混用規(guī)則的實際體現(xiàn)。KMS 動作全集含kms:Rekey批量重封裝等定義在 crates/policy/src/policy/action.rs 的KmsAction枚舉中kms:*通配同樣可用。兩層強制執(zhí)行平面RustFS 的每密鑰授權(quán)在兩個平面上生效管理端點和 SSE-KMS 數(shù)據(jù)路徑。前者始終開啟、無需遷移后者默認關(guān)閉、需要顯式開啟并先做準備。管理端點Admin endpoints所有指名密鑰的/rustfs/admin/v3/kms/...端點都針對該密鑰做授權(quán)。密鑰標識取自請求體中的key_id缺失時回退到keyId查詢參數(shù)。不指名密鑰的端點例如GET /rustfs/admin/v3/kms/keys則與從前一樣匹配策略中的任意 KMS 資源。哪些路由是 per-key即按它指名的密鑰授權(quán)、哪些是集群級匹配任意 KMS 資源在 rustfs/src/admin/route_policy.rs 中逐一登記GET /kms/keys/{key_id}、DELETE /kms/keys/delete、POST /kms/keys/{enable|disable|rotate|cancel-deletion|update-description|tag|untag}、POST /kms/generate-data-key等屬于 per-key而kms:Configureconfigure/reconfigure/keys 創(chuàng)建、kms:ServiceControlstart/stop/reload/status、kms:ClearCache、kms:Backup、kms:Restore、kms:Rekey均為集群級動作與 KMS 管理 API 契約 的端點矩陣一一對應(yīng)。該映射由route_registration_test等測試斷言保護。這一平面始終開啟無需遷移從未提及 KMS 資源的策略依然匹配所有密鑰行為不變。SSE-KMS 數(shù)據(jù)路徑在數(shù)據(jù)路徑上一次 SSE-KMS 寫入額外要求調(diào)用方具備kms:GenerateDataKey一次 SSE-KMS 讀取額外要求kms:Decrypt兩者都以發(fā)起請求的身份、針對請求實際解析到的密鑰求值。這堵住了混淆代理人confused deputy缺口此前服務(wù)器以自身權(quán)限代表任意持有s3:PutObject的調(diào)用方調(diào)用 KMS調(diào)用方本人卻不需要任何 KMS 授權(quán)。實現(xiàn)層面開關(guān)定義于 crates/config/src/constants/app.rs環(huán)境變量RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY默認值DEFAULT_KMS_ENFORCE_SSE_KEY_POLICY false求值與告警邏輯位于 rustfs/src/storage/sse.rs。范圍與豁免細節(jié)如下僅限 SSE-KMS。SSE-S3 的數(shù)據(jù)密鑰由服務(wù)器持有的密鑰包裹、調(diào)用方從不指名SSE-C 則根本不觸達 KMS。兩者都豁免與 AWS 行為一致。校驗的是實際解析到的密鑰而非請求頭。桶默認加密規(guī)則指名的 KMS 密鑰與顯式x-amz-server-side-encryption-aws-kms-key-id請求頭走完全相同的授權(quán)路徑。匿名請求一律拒絕。匿名調(diào)用方?jīng)]有身份策略、自然沒有任何kms授權(quán)因此開啟強制后對 SSE-KMS 對象的每次匿名讀寫都會以AccessDenied失敗——即使桶策略已將該桶設(shè)為公開與 AWS 一致同時堵住了在公開桶上丟棄憑證的繞過路徑。因此對外提供 SSE-KMS 對象的公開桶與強制模式不兼容——公開內(nèi)容要么不加密要么改用 SSE-S3。在強制關(guān)閉默認時匿名訪問 SSE-KMS 對象僅由桶策略管轄。服務(wù)器在每個進程首次發(fā)生匿名拒絕時告警一次逐請求的拒絕會出現(xiàn)在審計條目中kmsOutcomefailure、kmsErrorClassaccess_denied、空 requester identity并記錄在 debug 級別。內(nèi)部工作流豁免。復制replication、生命周期轉(zhuǎn)換lifecycle transitions、修復healing與掃描器scanner都以系統(tǒng)主體system principal身份運行不受影響。授權(quán)先于密鑰狀態(tài)檢查。一次拒絕無法被用來探測密鑰是否存在、是否被禁用或處于待刪除狀態(tài)——響應(yīng)一律是AccessDenied。分片上傳在創(chuàng)建時授權(quán)。會話數(shù)據(jù)密鑰session data key在創(chuàng)建時生成并授權(quán)后續(xù) Part 上傳與 Complete 復用該信封envelope不會針對目標密鑰重復授權(quán)。Copy 在兩端都校驗。源對象密鑰要求kms:Decrypt目標密鑰要求kms:GenerateDataKeyUploadPartCopy對源讀取的授權(quán)方式相同。遷移到每密鑰授權(quán)數(shù)據(jù)路徑強制默認關(guān)閉因為它會改變當前成功請求的結(jié)果現(xiàn)在僅持有s3:PutObject的身份也能用任意密鑰加密。不先準備策略就開啟會導致正常工作的負載直接報AccessDenied。RUSTFS_KMS_ENFORCE_SSE_KEY_POLICYtrue服務(wù)器會在啟動時記錄一次當前配置的模式在強制關(guān)閉狀態(tài)下啟動會給出告警。強制保持 opt-in目前沒有反轉(zhuǎn)默認值的路線圖。推薦遷移順序保持強制關(guān)閉。盤點哪些身份在讀寫 SSE-KMS 對象、各自使用哪些密鑰——S3 審計條目上的 KMS 字段sseType、kmsKeyId、kmsOutcome會報告每次請求實際使用的密鑰。為這些身份掛載KMSKeyUser或按其收窄的副本。強制關(guān)閉時這是無操作no-op因此可以提前鋪開。在單節(jié)點上開啟強制確認工作負載仍然成功。集群范圍鋪開。如果在第 3 步之后某個工作負載在 SSE-KMS 對象上開始報AccessDenied說明該身份在審計條目指名的密鑰上缺少kms:GenerateDataKey寫或kms:Decrypt讀。相關(guān)資源本文主體 docs/operations/kms-per-key-authorization.md資源語法與校驗實現(xiàn) crates/policy/src/policy/resource.rs動作全集KmsAction crates/policy/src/policy/action.rs內(nèi)置 KMS 角色模板與測試 crates/policy/src/policy/policy.rs管理路由到動作/風險的映射 rustfs/src/admin/route_policy.rs強制開關(guān)默認值與讀取 crates/config/src/constants/app.rsSSE-KMS 數(shù)據(jù)路徑強制實現(xiàn) rustfs/src/storage/sse.rs管理 API 端點矩陣與密鑰分頁契約 docs/operations/kms-admin-contract.mdKMS 后端安全屬性主密鑰輪換/保留/銷毀順序 docs/operations/kms-backend-security.md批量重封裝Rekey契約 docs/architecture/kms-bulk-rekey-contract.md【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 RustFS 每密鑰 KMS 授權(quán)（Per-key KMS Authorization）：IAM 策略、內(nèi)置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解
RustFS 每密鑰 KMS 授權(quán)Per-key KMS AuthorizationIAM 策略、內(nèi)置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本篇技術(shù)指南以 RustFS 操作文檔 docs/operations/kms-per-key-authorization.md 為主體結(jié)合 crates/policy 與 rustfs/src/admin/route_policy.rs 源碼系統(tǒng)講解 RustFS 如何基于身份策略identity policy對 KMS 密鑰做細粒度授權(quán)包括 KMS 資源 ARN 語法、內(nèi)置 KMS 角色模板、管理端點與 SSE-KMS 數(shù)據(jù)路徑兩層強制執(zhí)行以及從全集群共享密鑰權(quán)限平滑遷移到每密鑰授權(quán)的落地步驟。讀者讀完后可以獨立編寫限定到指定密鑰的 IAM 策略、正確組合內(nèi)置 KMS 角色并安全地開啟RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY數(shù)據(jù)面強制。RustFS 的 KMS 授權(quán)建立在身份策略之上一條 Statement 可以聲明它作用于哪些密鑰因此kms:DisableKey這樣的授權(quán)不再隱含集群內(nèi)所有密鑰一次 SSE-KMS 請求也會被拿實際解析到的密鑰來校驗。本文覆蓋資源語法、內(nèi)置角色模板、兩層強制執(zhí)行平面管理端點 SSE-KMS 數(shù)據(jù)路徑以及遷移路徑。關(guān)于各后端主密鑰master key材料存放位置參見 KMS 后端安全屬性管理 API 的完整端點矩陣見 KMS 管理 API 契約。KMS 資源語法KMS 資源使用與 S3 資源相同的空賬戶empty-accountARN 形式即arn:aws:kms:::之后直接跟資源段。下表為基本匹配規(guī)則模式匹配范圍arn:aws:kms:::key/key_id精確匹配該密鑰arn:aws:kms:::key/app-*匹配所有以app-開頭的 key idarn:aws:kms:::*匹配所有密鑰arn:aws:kms:::alias/name預留在別名解析alias resolution落地前不匹配任何請求以上語法并非文檔層面的約定而是 crates/policy/src/policy/resource.rs 中Resource::KMS_PREFIX、KMS_KEY_SEGMENT與KMS_ALIAS_SEGMENT三個常量定義的硬性規(guī)則請求側(cè) KMS 資源串總是key/key_id形式與這些模式逐一對齊alias/段雖可解析、可校驗但請求總是按key/key_id求值因此在別名解析功能落地前arn:aws:kms:::alias/*永遠不會匹配任何請求源碼注釋與測試kms alias never matches key均印證了這一點。該模塊對 KMS 資源還做了嚴格的格式校驗Validator for Resource裸*合法key/之后的 id 不能為空、不能包含/或\各 KMS 后端會拒絕含分隔符的密鑰名alias/之后的名稱不能為空、不能包含\但允許嵌套如alias/aws/s3。帶 region 與 account 的標準 AWS 形式如arn:aws:kms:us-east-1:123456789012:key/mykey會被拒絕——RustFS 使用空賬戶形式與 S3 資源保持一致。寫策略之前需要知道的規(guī)則一條 Statement 若混用kms:動作與s3:動作會被拒絕。KMS 授權(quán)必須放在獨立 Statement 中。一條 Statement 若攜帶 KMS 資源卻配非 KMS 動作會被拒絕。KMS Statement不寫資源時匹配所有密鑰——這是遺留形式且保持有效因此已有策略的效果不會改變。KMS Statement 的資源寫成 S3 ARN 時屬于早于 KMS 資源支持的舊策略。它仍可加載但 S3 模式從未真正約束過密鑰訪問求值時會忽略這些資源、把 Statement 當作未限定范圍unscoped處理并打印告警日志。建議用真正的 KMS 資源重寫這些策略。PutBucketPolicy會拒絕任何攜帶kms:動作或 KMS 資源的 Statement——KMS 授權(quán)只屬于身份identity不屬于桶策略。在此檢查之前已存儲的桶策略仍可加載求值時跳過其純 KMS Statement 并告警。與其他所有場景一致Deny優(yōu)先對arn:aws:kms:::key/payroll-*的Deny會覆蓋對arn:aws:kms:::*的Allow。參與匹配的 key id 是請求中直接指名的那個在別名解析之前。資源匹配采用通配符算法實現(xiàn)*、?等模式與 S3 資源共用同一套匹配邏輯路徑遍歷類輸入如key/mykey/../otherkey會被 clean 后拒絕匹配。完整的正反例可見 resource.rs 中的test_resource_is_match與test_kms_resource_parse測試。內(nèi)置 KMS 角色模板RustFS 在readwrite、readonly、writeonly、diagnostics與consoleAdmin之外還隨附三套 KMS 預置策略定義于 crates/policy/src/policy/policy.rs策略授予動作面向?qū)ο驥MSKeyAdministratorkms:DescribeKey、kms:ListKeys、kms:EnableKey、kms:DisableKey、kms:RotateKey、kms:DeleteKey負責密鑰生命周期治理的團隊KMSKeyUserkms:GenerateDataKey、kms:Decrypt、kms:DescribeKey讀寫 SSE-KMS 對象的工作負載KMSAuditorkms:DescribeKey、kms:ListKeys只需可見性、無需其他能力的審計人員這三套模板體現(xiàn)了職責分離separation of dutiesKMSKeyAdministrator可以禁用或刪除密鑰但永遠無法用它加解密KMSKeyUser可以使用密鑰但永遠無法改變其狀態(tài)。該約束由 policy.rs 中的模板測試逐一斷言例如KMSKeyAdministrator不允許kms:GenerateDataKey/kms:DecryptKMSKeyUser不允許kms:EnableKey/kms:DisableKey/kms:RotateKey/kms:DeleteKey。三個模板都不授予kms:Configure、kms:ServiceControl、kms:ClearCache、kms:Backup或kms:Restore。這些動作作用于 KMS 服務(wù)本身或一次性波及所有密鑰的材料屬于集群管理權(quán)限而非密鑰管理權(quán)限因此仍歸consoleAdmin所有。密鑰創(chuàng)建目前與kms:Configure共享后端配置動作所以創(chuàng)建密鑰同樣是consoleAdmin操作——這一點與 KMS 管理 API 契約 中POST /kms/keys映射到kms:Configure的端點矩陣一致。模板本身不帶任何 S3 或 admin 授權(quán)因此需要與數(shù)據(jù)面策略組合使用。策略映射policy mapping接受逗號分隔列表例如將KMSKeyUser與readwrite一并掛到某個用戶PUT /rustfs/admin/v3/set-user-or-group-policy?policyNamereadwrite,KMSKeyUseruserOrGroupapp-writerisGroupfalse三個模板默認也是未限定范圍的arn:aws:kms:::*與其他預置策略行為一致。要實現(xiàn)最小權(quán)限應(yīng)復制一份并按工作負載收窄例如{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [s3:*], Resource: [arn:aws:s3:::reports, arn:aws:s3:::reports/*] }, { Effect: Allow, Action: [kms:GenerateDataKey, kms:Decrypt, kms:DescribeKey], Resource: [arn:aws:kms:::key/reports-*] } ] }注意這里的 KMS 與 S3 授權(quán)被拆成了兩條獨立 Statement——這正是前述KMS 動作不得與 S3 動作混用規(guī)則的實際體現(xiàn)。KMS 動作全集含kms:Rekey批量重封裝等定義在 crates/policy/src/policy/action.rs 的KmsAction枚舉中kms:*通配同樣可用。兩層強制執(zhí)行平面RustFS 的每密鑰授權(quán)在兩個平面上生效管理端點和 SSE-KMS 數(shù)據(jù)路徑。前者始終開啟、無需遷移后者默認關(guān)閉、需要顯式開啟并先做準備。管理端點Admin endpoints所有指名密鑰的/rustfs/admin/v3/kms/...端點都針對該密鑰做授權(quán)。密鑰標識取自請求體中的key_id缺失時回退到keyId查詢參數(shù)。不指名密鑰的端點例如GET /rustfs/admin/v3/kms/keys則與從前一樣匹配策略中的任意 KMS 資源。哪些路由是 per-key即按它指名的密鑰授權(quán)、哪些是集群級匹配任意 KMS 資源在 rustfs/src/admin/route_policy.rs 中逐一登記GET /kms/keys/{key_id}、DELETE /kms/keys/delete、POST /kms/keys/{enable|disable|rotate|cancel-deletion|update-description|tag|untag}、POST /kms/generate-data-key等屬于 per-key而kms:Configureconfigure/reconfigure/keys 創(chuàng)建、kms:ServiceControlstart/stop/reload/status、kms:ClearCache、kms:Backup、kms:Restore、kms:Rekey均為集群級動作與 KMS 管理 API 契約 的端點矩陣一一對應(yīng)。該映射由route_registration_test等測試斷言保護。這一平面始終開啟無需遷移從未提及 KMS 資源的策略依然匹配所有密鑰行為不變。SSE-KMS 數(shù)據(jù)路徑在數(shù)據(jù)路徑上一次 SSE-KMS 寫入額外要求調(diào)用方具備kms:GenerateDataKey一次 SSE-KMS 讀取額外要求kms:Decrypt兩者都以發(fā)起請求的身份、針對請求實際解析到的密鑰求值。這堵住了混淆代理人confused deputy缺口此前服務(wù)器以自身權(quán)限代表任意持有s3:PutObject的調(diào)用方調(diào)用 KMS調(diào)用方本人卻不需要任何 KMS 授權(quán)。實現(xiàn)層面開關(guān)定義于 crates/config/src/constants/app.rs環(huán)境變量RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY默認值DEFAULT_KMS_ENFORCE_SSE_KEY_POLICY false求值與告警邏輯位于 rustfs/src/storage/sse.rs。范圍與豁免細節(jié)如下僅限 SSE-KMS。SSE-S3 的數(shù)據(jù)密鑰由服務(wù)器持有的密鑰包裹、調(diào)用方從不指名SSE-C 則根本不觸達 KMS。兩者都豁免與 AWS 行為一致。校驗的是實際解析到的密鑰而非請求頭。桶默認加密規(guī)則指名的 KMS 密鑰與顯式x-amz-server-side-encryption-aws-kms-key-id請求頭走完全相同的授權(quán)路徑。匿名請求一律拒絕。匿名調(diào)用方?jīng)]有身份策略、自然沒有任何kms授權(quán)因此開啟強制后對 SSE-KMS 對象的每次匿名讀寫都會以AccessDenied失敗——即使桶策略已將該桶設(shè)為公開與 AWS 一致同時堵住了在公開桶上丟棄憑證的繞過路徑。因此對外提供 SSE-KMS 對象的公開桶與強制模式不兼容——公開內(nèi)容要么不加密要么改用 SSE-S3。在強制關(guān)閉默認時匿名訪問 SSE-KMS 對象僅由桶策略管轄。服務(wù)器在每個進程首次發(fā)生匿名拒絕時告警一次逐請求的拒絕會出現(xiàn)在審計條目中kmsOutcomefailure、kmsErrorClassaccess_denied、空 requester identity并記錄在 debug 級別。內(nèi)部工作流豁免。復制replication、生命周期轉(zhuǎn)換lifecycle transitions、修復healing與掃描器scanner都以系統(tǒng)主體system principal身份運行不受影響。授權(quán)先于密鑰狀態(tài)檢查。一次拒絕無法被用來探測密鑰是否存在、是否被禁用或處于待刪除狀態(tài)——響應(yīng)一律是AccessDenied。分片上傳在創(chuàng)建時授權(quán)。會話數(shù)據(jù)密鑰session data key在創(chuàng)建時生成并授權(quán)后續(xù) Part 上傳與 Complete 復用該信封envelope不會針對目標密鑰重復授權(quán)。Copy 在兩端都校驗。源對象密鑰要求kms:Decrypt目標密鑰要求kms:GenerateDataKeyUploadPartCopy對源讀取的授權(quán)方式相同。遷移到每密鑰授權(quán)數(shù)據(jù)路徑強制默認關(guān)閉因為它會改變當前成功請求的結(jié)果現(xiàn)在僅持有s3:PutObject的身份也能用任意密鑰加密。不先準備策略就開啟會導致正常工作的負載直接報AccessDenied。RUSTFS_KMS_ENFORCE_SSE_KEY_POLICYtrue服務(wù)器會在啟動時記錄一次當前配置的模式在強制關(guān)閉狀態(tài)下啟動會給出告警。強制保持 opt-in目前沒有反轉(zhuǎn)默認值的路線圖。推薦遷移順序保持強制關(guān)閉。盤點哪些身份在讀寫 SSE-KMS 對象、各自使用哪些密鑰——S3 審計條目上的 KMS 字段sseType、kmsKeyId、kmsOutcome會報告每次請求實際使用的密鑰。為這些身份掛載KMSKeyUser或按其收窄的副本。強制關(guān)閉時這是無操作no-op因此可以提前鋪開。在單節(jié)點上開啟強制確認工作負載仍然成功。集群范圍鋪開。如果在第 3 步之后某個工作負載在 SSE-KMS 對象上開始報AccessDenied說明該身份在審計條目指名的密鑰上缺少kms:GenerateDataKey寫或kms:Decrypt讀。相關(guān)資源本文主體 docs/operations/kms-per-key-authorization.md資源語法與校驗實現(xiàn) crates/policy/src/policy/resource.rs動作全集KmsAction crates/policy/src/policy/action.rs內(nèi)置 KMS 角色模板與測試 crates/policy/src/policy/policy.rs管理路由到動作/風險的映射 rustfs/src/admin/route_policy.rs強制開關(guān)默認值與讀取 crates/config/src/constants/app.rsSSE-KMS 數(shù)據(jù)路徑強制實現(xiàn) rustfs/src/storage/sse.rs管理 API 端點矩陣與密鑰分頁契約 docs/operations/kms-admin-contract.mdKMS 后端安全屬性主密鑰輪換/保留/銷毀順序 docs/operations/kms-backend-security.md批量重封裝Rekey契約 docs/architecture/kms-bulk-rekey-contract.md【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考