置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解)
RustFS 每密鑰 KMS 授權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本篇技術指南以 RustFS 操作文檔 docs/operations/kms-per-key-authorization.md 為主體結合 crates/policy 與 rustfs/src/admin/route_policy.rs 源碼系統(tǒng)講解 RustFS 如何基于身份策略identity policy對 KMS 密鑰做細粒度授權包括 KMS 資源 ARN 語法、內(nèi)置 KMS 角色模板、管理端點與 SSE-KMS 數(shù)據(jù)路徑兩層強制執(zhí)行以及從全集群共享密鑰權限平滑遷移到每密鑰授權的落地步驟。讀者讀完后可以獨立編寫限定到指定密鑰的 IAM 策略、正確組合內(nèi)置 KMS 角色并安全地開啟RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY數(shù)據(jù)面強制。RustFS 的 KMS 授權建立在身份策略之上一條 Statement 可以聲明它作用于哪些密鑰因此kms:DisableKey這樣的授權不再隱含集群內(nèi)所有密鑰一次 SSE-KMS 請求也會被拿實際解析到的密鑰來校驗。本文覆蓋資源語法、內(nèi)置角色模板、兩層強制執(zhí)行平面管理端點 SSE-KMS 數(shù)據(jù)路徑以及遷移路徑。關于各后端主密鑰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ī)則請求側 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 授權必須放在獨立 Statement 中。一條 Statement 若攜帶 KMS 資源卻配非 KMS 動作會被拒絕。KMS Statement不寫資源時匹配所有密鑰——這是遺留形式且保持有效因此已有策略的效果不會改變。KMS Statement 的資源寫成 S3 ARN 時屬于早于 KMS 資源支持的舊策略。它仍可加載但 S3 模式從未真正約束過密鑰訪問求值時會忽略這些資源、把 Statement 當作未限定范圍unscoped處理并打印告警日志。建議用真正的 KMS 資源重寫這些策略。PutBucketPolicy會拒絕任何攜帶kms:動作或 KMS 資源的 Statement——KMS 授權只屬于身份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策略授予動作面向對象KMSKeyAdministratorkms: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 服務本身或一次性波及所有密鑰的材料屬于集群管理權限而非密鑰管理權限因此仍歸consoleAdmin所有。密鑰創(chuàng)建目前與kms:Configure共享后端配置動作所以創(chuàng)建密鑰同樣是consoleAdmin操作——這一點與 KMS 管理 API 契約 中POST /kms/keys映射到kms:Configure的端點矩陣一致。模板本身不帶任何 S3 或 admin 授權因此需要與數(shù)據(jù)面策略組合使用。策略映射policy mapping接受逗號分隔列表例如將KMSKeyUser與readwrite一并掛到某個用戶PUT /rustfs/admin/v3/set-user-or-group-policy?policyNamereadwrite,KMSKeyUseruserOrGroupapp-writerisGroupfalse三個模板默認也是未限定范圍的arn:aws:kms:::*與其他預置策略行為一致。要實現(xiàn)最小權限應復制一份并按工作負載收窄例如{ 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 授權被拆成了兩條獨立 Statement——這正是前述KMS 動作不得與 S3 動作混用規(guī)則的實際體現(xiàn)。KMS 動作全集含kms:Rekey批量重封裝等定義在 crates/policy/src/policy/action.rs 的KmsAction枚舉中kms:*通配同樣可用。兩層強制執(zhí)行平面RustFS 的每密鑰授權在兩個平面上生效管理端點和 SSE-KMS 數(shù)據(jù)路徑。前者始終開啟、無需遷移后者默認關閉、需要顯式開啟并先做準備。管理端點Admin endpoints所有指名密鑰的/rustfs/admin/v3/kms/...端點都針對該密鑰做授權。密鑰標識取自請求體中的key_id缺失時回退到keyId查詢參數(shù)。不指名密鑰的端點例如GET /rustfs/admin/v3/kms/keys則與從前一樣匹配策略中的任意 KMS 資源。哪些路由是 per-key即按它指名的密鑰授權、哪些是集群級匹配任意 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 契約 的端點矩陣一一對應。該映射由route_registration_test等測試斷言保護。這一平面始終開啟無需遷移從未提及 KMS 資源的策略依然匹配所有密鑰行為不變。SSE-KMS 數(shù)據(jù)路徑在數(shù)據(jù)路徑上一次 SSE-KMS 寫入額外要求調(diào)用方具備kms:GenerateDataKey一次 SSE-KMS 讀取額外要求kms:Decrypt兩者都以發(fā)起請求的身份、針對請求實際解析到的密鑰求值。這堵住了混淆代理人confused deputy缺口此前服務器以自身權限代表任意持有s3:PutObject的調(diào)用方調(diào)用 KMS調(diào)用方本人卻不需要任何 KMS 授權。實現(xià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ù)密鑰由服務器持有的密鑰包裹、調(diào)用方從不指名SSE-C 則根本不觸達 KMS。兩者都豁免與 AWS 行為一致。校驗的是實際解析到的密鑰而非請求頭。桶默認加密規(guī)則指名的 KMS 密鑰與顯式x-amz-server-side-encryption-aws-kms-key-id請求頭走完全相同的授權路徑。匿名請求一律拒絕。匿名調(diào)用方?jīng)]有身份策略、自然沒有任何kms授權因此開啟強制后對 SSE-KMS 對象的每次匿名讀寫都會以AccessDenied失敗——即使桶策略已將該桶設為公開與 AWS 一致同時堵住了在公開桶上丟棄憑證的繞過路徑。因此對外提供 SSE-KMS 對象的公開桶與強制模式不兼容——公開內(nèi)容要么不加密要么改用 SSE-S3。在強制關閉默認時匿名訪問 SSE-KMS 對象僅由桶策略管轄。服務器在每個進程首次發(fā)生匿名拒絕時告警一次逐請求的拒絕會出現(xiàn)在審計條目中kmsOutcomefailure、kmsErrorClassaccess_denied、空 requester identity并記錄在 debug 級別。內(nèi)部工作流豁免。復制replication、生命周期轉換lifecycle transitions、修復healing與掃描器scanner都以系統(tǒng)主體system principal身份運行不受影響。授權先于密鑰狀態(tài)檢查。一次拒絕無法被用來探測密鑰是否存在、是否被禁用或處于待刪除狀態(tài)——響應一律是AccessDenied。分片上傳在創(chuàng)建時授權。會話數(shù)據(jù)密鑰session data key在創(chuàng)建時生成并授權后續(xù) Part 上傳與 Complete 復用該信封envelope不會針對目標密鑰重復授權。Copy 在兩端都校驗。源對象密鑰要求kms:Decrypt目標密鑰要求kms:GenerateDataKeyUploadPartCopy對源讀取的授權方式相同。遷移到每密鑰授權數(shù)據(jù)路徑強制默認關閉因為它會改變當前成功請求的結果現(xiàn)在僅持有s3:PutObject的身份也能用任意密鑰加密。不先準備策略就開啟會導致正常工作的負載直接報AccessDenied。RUSTFS_KMS_ENFORCE_SSE_KEY_POLICYtrue服務器會在啟動時記錄一次當前配置的模式在強制關閉狀態(tài)下啟動會給出告警。強制保持 opt-in目前沒有反轉默認值的路線圖。推薦遷移順序保持強制關閉。盤點哪些身份在讀寫 SSE-KMS 對象、各自使用哪些密鑰——S3 審計條目上的 KMS 字段sseType、kmsKeyId、kmsOutcome會報告每次請求實際使用的密鑰。為這些身份掛載KMSKeyUser或按其收窄的副本。強制關閉時這是無操作no-op因此可以提前鋪開。在單節(jié)點上開啟強制確認工作負載仍然成功。集群范圍鋪開。如果在第 3 步之后某個工作負載在 SSE-KMS 對象上開始報AccessDenied說明該身份在審計條目指名的密鑰上缺少kms:GenerateDataKey寫或kms:Decrypt讀。相關資源本文主體 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強制開關默認值與讀取 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 授權（Per-key KMS Authorization）：IAM 策略、內(nèi)置角色模板與 SSE-KMS 數(shù)據(jù)面強制詳解
RustFS 每密鑰 KMS 授權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本篇技術指南以 RustFS 操作文檔 docs/operations/kms-per-key-authorization.md 為主體結合 crates/policy 與 rustfs/src/admin/route_policy.rs 源碼系統(tǒng)講解 RustFS 如何基于身份策略identity policy對 KMS 密鑰做細粒度授權包括 KMS 資源 ARN 語法、內(nèi)置 KMS 角色模板、管理端點與 SSE-KMS 數(shù)據(jù)路徑兩層強制執(zhí)行以及從全集群共享密鑰權限平滑遷移到每密鑰授權的落地步驟。讀者讀完后可以獨立編寫限定到指定密鑰的 IAM 策略、正確組合內(nèi)置 KMS 角色并安全地開啟RUSTFS_KMS_ENFORCE_SSE_KEY_POLICY數(shù)據(jù)面強制。RustFS 的 KMS 授權建立在身份策略之上一條 Statement 可以聲明它作用于哪些密鑰因此kms:DisableKey這樣的授權不再隱含集群內(nèi)所有密鑰一次 SSE-KMS 請求也會被拿實際解析到的密鑰來校驗。本文覆蓋資源語法、內(nèi)置角色模板、兩層強制執(zhí)行平面管理端點 SSE-KMS 數(shù)據(jù)路徑以及遷移路徑。關于各后端主密鑰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ī)則請求側 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 授權必須放在獨立 Statement 中。一條 Statement 若攜帶 KMS 資源卻配非 KMS 動作會被拒絕。KMS Statement不寫資源時匹配所有密鑰——這是遺留形式且保持有效因此已有策略的效果不會改變。KMS Statement 的資源寫成 S3 ARN 時屬于早于 KMS 資源支持的舊策略。它仍可加載但 S3 模式從未真正約束過密鑰訪問求值時會忽略這些資源、把 Statement 當作未限定范圍unscoped處理并打印告警日志。建議用真正的 KMS 資源重寫這些策略。PutBucketPolicy會拒絕任何攜帶kms:動作或 KMS 資源的 Statement——KMS 授權只屬于身份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策略授予動作面向對象KMSKeyAdministratorkms: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 服務本身或一次性波及所有密鑰的材料屬于集群管理權限而非密鑰管理權限因此仍歸consoleAdmin所有。密鑰創(chuàng)建目前與kms:Configure共享后端配置動作所以創(chuàng)建密鑰同樣是consoleAdmin操作——這一點與 KMS 管理 API 契約 中POST /kms/keys映射到kms:Configure的端點矩陣一致。模板本身不帶任何 S3 或 admin 授權因此需要與數(shù)據(jù)面策略組合使用。策略映射policy mapping接受逗號分隔列表例如將KMSKeyUser與readwrite一并掛到某個用戶PUT /rustfs/admin/v3/set-user-or-group-policy?policyNamereadwrite,KMSKeyUseruserOrGroupapp-writerisGroupfalse三個模板默認也是未限定范圍的arn:aws:kms:::*與其他預置策略行為一致。要實現(xiàn)最小權限應復制一份并按工作負載收窄例如{ 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 授權被拆成了兩條獨立 Statement——這正是前述KMS 動作不得與 S3 動作混用規(guī)則的實際體現(xiàn)。KMS 動作全集含kms:Rekey批量重封裝等定義在 crates/policy/src/policy/action.rs 的KmsAction枚舉中kms:*通配同樣可用。兩層強制執(zhí)行平面RustFS 的每密鑰授權在兩個平面上生效管理端點和 SSE-KMS 數(shù)據(jù)路徑。前者始終開啟、無需遷移后者默認關閉、需要顯式開啟并先做準備。管理端點Admin endpoints所有指名密鑰的/rustfs/admin/v3/kms/...端點都針對該密鑰做授權。密鑰標識取自請求體中的key_id缺失時回退到keyId查詢參數(shù)。不指名密鑰的端點例如GET /rustfs/admin/v3/kms/keys則與從前一樣匹配策略中的任意 KMS 資源。哪些路由是 per-key即按它指名的密鑰授權、哪些是集群級匹配任意 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 契約 的端點矩陣一一對應。該映射由route_registration_test等測試斷言保護。這一平面始終開啟無需遷移從未提及 KMS 資源的策略依然匹配所有密鑰行為不變。SSE-KMS 數(shù)據(jù)路徑在數(shù)據(jù)路徑上一次 SSE-KMS 寫入額外要求調(diào)用方具備kms:GenerateDataKey一次 SSE-KMS 讀取額外要求kms:Decrypt兩者都以發(fā)起請求的身份、針對請求實際解析到的密鑰求值。這堵住了混淆代理人confused deputy缺口此前服務器以自身權限代表任意持有s3:PutObject的調(diào)用方調(diào)用 KMS調(diào)用方本人卻不需要任何 KMS 授權。實現(xià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ù)密鑰由服務器持有的密鑰包裹、調(diào)用方從不指名SSE-C 則根本不觸達 KMS。兩者都豁免與 AWS 行為一致。校驗的是實際解析到的密鑰而非請求頭。桶默認加密規(guī)則指名的 KMS 密鑰與顯式x-amz-server-side-encryption-aws-kms-key-id請求頭走完全相同的授權路徑。匿名請求一律拒絕。匿名調(diào)用方?jīng)]有身份策略、自然沒有任何kms授權因此開啟強制后對 SSE-KMS 對象的每次匿名讀寫都會以AccessDenied失敗——即使桶策略已將該桶設為公開與 AWS 一致同時堵住了在公開桶上丟棄憑證的繞過路徑。因此對外提供 SSE-KMS 對象的公開桶與強制模式不兼容——公開內(nèi)容要么不加密要么改用 SSE-S3。在強制關閉默認時匿名訪問 SSE-KMS 對象僅由桶策略管轄。服務器在每個進程首次發(fā)生匿名拒絕時告警一次逐請求的拒絕會出現(xiàn)在審計條目中kmsOutcomefailure、kmsErrorClassaccess_denied、空 requester identity并記錄在 debug 級別。內(nèi)部工作流豁免。復制replication、生命周期轉換lifecycle transitions、修復healing與掃描器scanner都以系統(tǒng)主體system principal身份運行不受影響。授權先于密鑰狀態(tài)檢查。一次拒絕無法被用來探測密鑰是否存在、是否被禁用或處于待刪除狀態(tài)——響應一律是AccessDenied。分片上傳在創(chuàng)建時授權。會話數(shù)據(jù)密鑰session data key在創(chuàng)建時生成并授權后續(xù) Part 上傳與 Complete 復用該信封envelope不會針對目標密鑰重復授權。Copy 在兩端都校驗。源對象密鑰要求kms:Decrypt目標密鑰要求kms:GenerateDataKeyUploadPartCopy對源讀取的授權方式相同。遷移到每密鑰授權數(shù)據(jù)路徑強制默認關閉因為它會改變當前成功請求的結果現(xiàn)在僅持有s3:PutObject的身份也能用任意密鑰加密。不先準備策略就開啟會導致正常工作的負載直接報AccessDenied。RUSTFS_KMS_ENFORCE_SSE_KEY_POLICYtrue服務器會在啟動時記錄一次當前配置的模式在強制關閉狀態(tài)下啟動會給出告警。強制保持 opt-in目前沒有反轉默認值的路線圖。推薦遷移順序保持強制關閉。盤點哪些身份在讀寫 SSE-KMS 對象、各自使用哪些密鑰——S3 審計條目上的 KMS 字段sseType、kmsKeyId、kmsOutcome會報告每次請求實際使用的密鑰。為這些身份掛載KMSKeyUser或按其收窄的副本。強制關閉時這是無操作no-op因此可以提前鋪開。在單節(jié)點上開啟強制確認工作負載仍然成功。集群范圍鋪開。如果在第 3 步之后某個工作負載在 SSE-KMS 對象上開始報AccessDenied說明該身份在審計條目指名的密鑰上缺少kms:GenerateDataKey寫或kms:Decrypt讀。相關資源本文主體 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強制開關默認值與讀取 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），僅供參考