Skip to main content
Information Security for Workload Factory
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

AWS 認證資料如何流經 NetApp Workload Factory

貢獻者 netapp-rlithman

AWS 認證資料流程描述了 NetApp Workload Factory 在部署和執行階段操作期間如何處理角色識別碼、外部 ID 和短期 AWS STS 認證資料。在一次性設定期間,您需要在 AWS 帳戶中建立 IAM 角色,並設定信任原則,該原則要求 Workload Factory 服務主體和正確的外部 ID。在執行階段,Workload Factory 會使用已儲存的角色 ARN 和外部 ID 來要求由每個要求的工作階段原則限定範圍的臨時認證資料,並會重複使用快取的認證資料,直到它們過期為止。

一次性設定

對於一次性設定,流程如下:

步驟
  1. 您產品發表 CloudFormation 堆疊或在您的 AWS 帳戶中手動建立 IAM 角色。

  2. IAM 角色信任原則規定了兩個條件:

    1. 只有 Workload Factory 的服務主體才能承擔此責任。

    2. 呼叫者必須提供正確的外部識別碼。

  3. Workload Factory 將角色 ARN 和外部 ID(加密)儲存在其資料庫中。

執行階段(每次 API 操作)

在執行階段,Workload Factory 使用儲存的角色 ARN 和外部 ID 來為每個 API 作業取得臨時的 AWS STS 認證資料。流程如下:

步驟
  1. Workload Factory 從 MySQL 擷取儲存的角色 ARN 和外部 ID。

  2. 它會檢查 Redis 中是否有此角色的一組快取臨時 AWS STS 認證資料。

  3. 當快取未命中時,Workload Factory 會使用角色 ARN 和外部 ID 呼叫 sts:AssumeRole。此呼叫包含每個請求的即時工作階段原則,該原則將權限限制為僅該作業所需的特定 AWS 動作。

  4. AWS STS 傳回帶有過期時間戳記的臨時認證資料(存取金鑰 ID、秘密存取金鑰、工作階段權杖)。

  5. Workload Factory 將這些認證資料快取在 Redis 中,並使用它們來呼叫目標 AWS API。

  6. 發生快取命中率時,Workload Factory 會略過 STS 呼叫,並直接使用快取的認證資料。

工作階段原則

每個 STS 呼叫都包含一個即時工作階段原則,其範圍限定為所需的最少 AWS 操作。