遵循最佳實踐利用執行環境重用來提高函式的性能，我正在調查boto3在使用 Lambda 預配置并發時快取客戶端是否有任何負面影響。該boto3客戶端通過快取@lru_cache裝飾，這是懶惰的初始化。現在，擔心的是boto3客戶端的底層憑據不會重繪 ，因為預置并發將使執行環境保持活動狀態一段未知的時間。此生命周期可能比 Lambda 環境注入的臨時憑證的持續時間更長。
我找不到任何解釋如何處理此案的檔案。有誰知道在上述情況下 Lambda 環境如何處理憑據的重繪 ？
uj5u.com熱心網友回復：
如果您使用硬編碼憑據：
您有一個比“重用”憑證更大的安全問題，應該立即洗掉它們。
從檔案：
不要將文字訪問鍵放在您的應用程式檔案中。如果這樣做，例如，如果您將專案上傳到公共存盤庫，則會產生意外暴露您的憑據的風險。
不要在您的專案區域中包含包含憑據的檔案。
將它們替換為執行角色。
如果您使用的是執行角色：
您不會為任何 AWS 開發工具包呼叫手動提供任何憑證。SDK 的憑證自動來自Lambda 函式的執行角色。
即使 Boto3 角色憑證在內部呼叫之間共享以提供并發性（沒有人確定），會有什么問題？
讓 Amazon 處理角色憑證——管理它根本不是你的責任。
我更擔心應用程式代碼存在安全缺陷，而不是亞馬遜使用執行角色憑證自動驗證 SDK 請求。
uj5u.com熱心網友回復：
他們不是。
Boto3的檔案并沒有很好地描述憑證鏈，但是CLI 檔案顯示了憑證的各種來源（并且由于 CLI 是用 Python 撰寫的，因此它提供了權威檔案）。
與從實體元資料中檢索基于角色的憑證的 EC2 和 ECS 不同，Lambda 在環境變數中提供憑證。Lambda 運行時在啟動時設定這些環境變數，并且每次呼叫該 Lambda 運行時都使用相同的值。
并發 Lambda 接收單獨的憑據集，就像您對 STS 進行并發顯式呼叫一樣AssumeRole。
預配置并發有點棘手。您可能認為相同的 Lambda 運行時“永遠”存在，但實際上并非如此：如果您重復呼叫具有預置并發性的 Lambda，您會看到它在某個時候創建??了一個新的 CloudWatch 日志流。這表明 Lambda 已經啟動了一個新的運行時。Lambda 將在停止向舊運行時發送請求之前完成對新運行時的初始化，因此您不會遇到冷啟動延遲。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/319054.html
標籤：亚马逊网络服务 缓存 aws-lambda boto3 证书