歡迎來到本系列第十篇文章

在上一篇文章中，我們聊到了什麼是 CI/CD，以及如何用 GitHub Actions 串接自動化流程。不過我們也提到一個關鍵問題：CI/CD 要怎麼樣安全地存取雲端服務？這就是今天的主題 —— IAM (Identity and Access Management) 與憑證管理。

在雲端的世界裡，權限控制非常重要：

• 直接開最大權限雖然很方便，但風險極高（如果憑證外洩，駭客就能操控你的所有服務）。
• 權限設太少的話 Pipeline 什麼都做不了，整個流程卡死。

因此，我們需要找到一個平衡點：只給 CI/CD 所需的最低限度權限（Principle of Least Privilege），同時透過安全的方式（像是 GitHub Secrets 或 AWS IAM Role）來管理憑證。

接下來，我們會先快速認識 IAM 的基本概念，然後再進入 CI/CD 中實際的應用。

IAM 基本概念

在進入 CI/CD 的應用之前，我們先認識 AWS IAM 的重要元件。

下面這張圖可以幫助你快速掌握 IAM 的結構：

(圖片來源：Geeks for Geeks)

IAM 中權限的基礎：Policy 與 Statement

在 IAM 的世界裡，所有權限都是透過 Policy（策略）來描述的。
Policy 的本質就是一份 JSON 文件，裡面包含一個或多個 Statement（敘述）。

每個 Statement 就像是一條規則，描述「誰」能在「哪些資源」上「做什麼動作」。
主要欄位如下：

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

• Effect：決定是 Allow（允許）還是 Deny（拒絕）(如果同時有兩份statement作用 Deny 會勝過 Allow )。

• Action：指定可以呼叫的 API，例如 s3:PutObject(上傳一個物件到Bucket)、ec2:StartInstances(啟動一個EC2)。

• Resource：指定能操作的 AWS 資源，用 ARN（Amazon Resource Name）表示。

一份完整的 Policy 可以包含多個 Statement，以下是同時允許 S3 Bucket 的物件上傳以及下載的 Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

那麼這些權限要怎麼給別人？

這些 Policy 不會自己生效，必須綁定到某個 IAM 實體，例如：

**User（使用者） → 個別人員或應用程式帳號。

**Group（群組） → 一群使用者的集合，用來批次套用 Policy。

**Role（角色） → 提供臨時憑證給 AWS 資源或外部服務（例如我們會用到的 GitHub Actions）。

以下就讓我們來介紹這些 IAM 實體

1. User（使用者）

• 對象：人或應用程式（例如：你自己、某個服務帳號）。
• 用途：直接登入 AWS Console 或使用 Access Key/Secret Key 透過 CLI/SDK 存取服務。
• 特徵：每個使用者都能綁定一組憑證，通常搭配 MFA（多因子驗證）提升安全性。

2. Group（群組）

• 對象：一組使用者的集合。
• 用途：方便集中管理權限。例如：把「開發者」都加到一個 Group 裡，授予 S3 讀寫權限。
• 特徵：Group 本身不擁有憑證，只有 User 可以登入；Group 的目的是「批次管理 Policy」。

3. Role（角色）

• 對象：AWS 資源或外部服務（像是 EC2、Lambda、GitHub Actions）。
• 用途：讓一個實體臨時地獲得權限，而不是直接使用永久憑證。
• 特徵：Role 沒有使用者名稱或密碼，只有透過「Assume Role」的方式被使用。

為什麼 CI/CD 需要 Role？

在 CI/CD Pipeline 中，我們不希望把「永久性的 Access Key」塞到 GitHub Repo，因為一旦洩漏，後果不堪設想。
這時候 IAM Role 就是最佳解：

• CI/CD 服務（像 GitHub Actions 或 AWS CodePipeline）可以「扮演這個角色（Assume Role）」，臨時獲得權限來部署資源。
• 權限可以精準控制：例如只允許建立/更新 S3 Bucket，而不能刪除 DynamoDB。
• 憑證是短期的，降低了外洩風險。

結語

今天專注在IAM的基本概念講解，希望大家在經過今天的文章有更加了解 IAM 所扮演的角色。在下一篇文章，我們就會專注於 如何為 CI/CD 建立合適的 IAM Role，並將它實際套用在 GitHub Actions Workflow 中。敬請期待囉！