我正在嘗試遵循最佳實踐，但我不清楚檔案。我有一個在本地運行的 python 腳本，它將一些檔案從我的本地驅動器移動到 S3 進行處理。Lambda 從那里獲取它并完成剩下的作業。到目前為止，我為此程序設定了一個 AWS 用戶，并將其連接到一個只能訪問所需資源的“策略”。
下一步是將我的腳本移動到本地服務器中的 docker 容器中。但我認為最佳實踐是使用帶有策略的角色，而不是帶有策略的用戶。但是，根據此檔案...為了 AssumeRole... 我必須首先以用戶身份登錄。
對 AWS STS AssumeRole 的呼叫必須使用現有 IAM 用戶的訪問密鑰 ID 和秘密訪問密鑰進行簽名，或者使用現有的臨時憑證（例如來自另一個角色的憑證）進行簽名。（您不能使用 root 帳戶的訪問密鑰呼叫 AssumeRole。）憑據可以在環境變數或組態檔中，并且將被 boto3.client() 函式自動發現。
因此，無論如何，我都需要將我的用戶憑據嵌入到我的 docker 映像（或至少是一個單獨的機密檔案）中，如果是這種情況，那么似乎在用戶和策略之間添加了一個“角色”似乎完全沒用和多余。任何人都可以確認或更正嗎？
uj5u.com熱心網友回復：
角色和策略適用于在 AWS 環境中運行的服務。對于角色，您定義信任策略。信任策略定義了可以代入的委托人（用戶、角色、AWS 服務等）。您還定義了假定委托人必須訪問 AWS 服務的權限。
對于在 AWS 內部運行的服務（EC2、Lambda、ECS），始終可以選擇一個 IAM 角色，該角色將由您的服務承擔。這樣，您的應用程式將始終獲得與 IAM 角色相對應的臨時憑證，您永遠不應使用 AWS 訪問密鑰 ID 和密鑰。
但是，這對于在本地或 AWS 環境之外運行的服務是不可能的。對于在本地運行的 Docker 容器，唯一真正的選擇是創建訪問密鑰 ID 和秘密并將其復制到那里。您仍然可以采取一些措施來確保您的帳戶安全：
- 遵循最低權限原則。創建僅提供對絕對必需資源的訪問權限的策略。
- 創建用戶（僅限編程訪問）并添加策略。將此用戶的 AWS 訪問密鑰 ID 和密鑰用于您的 Docker 容器。
- 確保定期輪換 AWS 憑證。
- 確保機密不在源代碼控制中提交，更喜歡機密檔案或 Vault 系統而不是環境變數。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/361832.html
標籤：亚马逊网络服务 码头工人 boto3 亚马逊 aws-sts