AWS 認證資料如何流經 NetApp Workload Factory
AWS 認證資料流程描述了 NetApp Workload Factory 在部署和執行階段操作期間如何處理角色識別碼、外部 ID 和短期 AWS STS 認證資料。在一次性設定期間,您需要在 AWS 帳戶中建立 IAM 角色,並設定信任原則,該原則要求 Workload Factory 服務主體和正確的外部 ID。在執行階段,Workload Factory 會使用已儲存的角色 ARN 和外部 ID 來要求由每個要求的工作階段原則限定範圍的臨時認證資料,並會重複使用快取的認證資料,直到它們過期為止。
一次性設定
對於一次性設定,流程如下:
-
您產品發表 CloudFormation 堆疊或在您的 AWS 帳戶中手動建立 IAM 角色。
-
IAM 角色信任原則規定了兩個條件:
-
只有 Workload Factory 的服務主體才能承擔此責任。
-
呼叫者必須提供正確的外部識別碼。
-
-
Workload Factory 將角色 ARN 和外部 ID(加密)儲存在其資料庫中。
執行階段(每次 API 操作)
在執行階段,Workload Factory 使用儲存的角色 ARN 和外部 ID 來為每個 API 作業取得臨時的 AWS STS 認證資料。流程如下:
-
Workload Factory 從 MySQL 擷取儲存的角色 ARN 和外部 ID。
-
它會檢查 Redis 中是否有此角色的一組快取臨時 AWS STS 認證資料。
-
當快取未命中時,Workload Factory 會使用角色 ARN 和外部 ID 呼叫
sts:AssumeRole。此呼叫包含每個請求的即時工作階段原則,該原則將權限限制為僅該作業所需的特定 AWS 動作。 -
AWS STS 傳回帶有過期時間戳記的臨時認證資料(存取金鑰 ID、秘密存取金鑰、工作階段權杖)。
-
Workload Factory 將這些認證資料快取在 Redis 中,並使用它們來呼叫目標 AWS API。
-
發生快取命中率時,Workload Factory 會略過 STS 呼叫,並直接使用快取的認證資料。
工作階段原則
每個 STS 呼叫都包含一個即時工作階段原則,其範圍限定為所需的最少 AWS 操作。