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

在上一篇文章中，我們第一次動手建立了一個 GitHub Actions Workflow，讓程式碼 Push 到 Repo 時就能觸發自動化流程，並且跑出一個最基礎的 CDK Deploy 範例。

不過，，在昨天中我們沒有真正的部署任何資源到 AWS 上
於是我們今天的目標就是讓我們的 GitHub Actions Workflow 「安全地」取得 AWS 權限來執行部署

還記得我們在 Day4 使用 CLI 介面與 AWS 互動時時創建了 IAM User，當時使用了Access Key 和 Secret Key才使得我們的終端取得了調用 AWS 資源的權限

那麼，在 CI/CD 的情境下，我們是不是也能直接把這組金鑰放進 GitHub Secrets 裡，讓 Workflow 在執行時讀取憑證呢？
這其實是最直覺、也是很多人第一時間會想到的做法。：

但這個做法其實還是有它的缺點，因為 IAM User 是一組長期有效的金鑰，一旦外洩，等於把你 AWS 帳號的鑰匙交給別人。而為了避免這樣的風險，我們就需要一個更安全、更彈性的方式 —— 這就是 IAM Role + OIDC Provider 的登場時機。

在今天的內容裡，我們會：

1.建立一個 IAM Role，專門給 GitHub Actions 使用

2.透過 OIDC Provider 讓 AWS 信任 GitHub，讓 Workflow 能在執行時自動「臨時換取憑證」，而不是使用長期金鑰。

OIDC 到底是什麼？

OIDC (OpenID Connect) 聽起來很陌生，但其實每天都會用到。

當你註冊一個新網站時，應該都看過這樣的按鈕：

• 「使用 Google 帳號登入」
• 「用 Facebook 登入」
• 「Continue with GitHub」

這些就是 OIDC( OpenID Connect) 在你生活中的應用。

它的運作方式大概是這樣：

• 你想登入某個 App
• App 本身並沒有幫你存帳號密碼，而是請第三方(如 Google)幫忙驗證。
• Google 確認這個人就是你後，給你一張 ID Token
• App 拿到Token，就知道你是誰，讓你登入成功。

這樣一來，你不用每個網站都記一堆密碼，也不用擔心帳號外洩，因為 驗證交給可信任的身份提供者 (Identity Provider, IdP)。

那 AWS 跟 GitHub Actions 又是怎麼用的呢？

把剛剛的例子換成我們的 CI/CD 流程：

• AWS 就像你想登入的 App。
• Github Actions Workflow 在這個例子裡可以視為使用者
• OIDC Provider (Github) 扮演「身份驗證的 Google」

流程大概是這樣：

1. Workflow 執行時，GitHub 說：「這次跑的 Pipeline 是來自 my-org/my-repo，這是它的身份票券。」
2. AWS 驗證這張票，發現跟 IAM Role 的信任政策 (Trust Policy) 符合，就頒發一組臨時憑證。
3. Workflow 拿著這個臨時憑證，就能在 AWS 裡執行 CDK Deploy。

所以回到我們的目標，你大概會發現我們需要先創建一個 IAM Role 並設定他的 Trust Policy

IAM Role 設定介紹

**Permission Policy & Trust Policy

在之前的文章中 我們提及了 IAM 中權限的基礎Policy和Statement。但其實，在 IAM Role中，Policy還能夠再細分為 Trust Policy 以及 Permission Policy。

• Permission Policy
  • 就如同我們先前介紹過的Policy，由 Statement 組成，描述這個Role「可以做的事情」。
• Trust Policy
  • Policy 來定義誰能 Assume(扮演)這個角色。

關於 AWS 與 Github Actions 的 OIDC 設定，Github 很貼心的推出了官方 Document 來教你怎麼樣串接，三大雲服務商皆有，有興趣的可以看一下，而接下來我將會帶你走過在 AWS 上串接 OIDC 的流程。

GitHub Actions 串接 AWS OIDC 官方流程

根據 GitHub 官方文件 與 AWS 安全最佳實踐，以下是設定 GitHub Actions 使用 AWS OIDC 身份聯盟（OIDC） 的推薦步驟：

1. 建立 OIDC 身份提供者 (OIDC Identity Provider)

在 AWS Console → IAM → 身分供應商 (Identity Provider) → 新增供應商 (Provider)：

• Provider type：OpenID Connect
• Provider URL：https://token.actions.githubusercontent.com
• Audience (Client ID)：sts.amazonaws.com

這樣 AWS 就能信任由 GitHub Actions 簽發的 OIDC Token。

2. 建立 IAM Role，設定 Trust Policy

建立一個專屬的 IAM Role，允許 GitHub Actions 透過 OIDC 來 AssumeRole：

在下方選單中選擇剛剛創建的 OIDC Identity Provider，並填入你的Github Repo的相關資訊

3. 附加 IAM Permission Policy

最佳實務而言，我們應該為這個 Role 授予 最小權限（Principle of Least Privilege），例如：

• S3 存取權限
• CloudFormation 部署權限
• Lambda 更新權限
• 依照 CI/CD 的需求調整即可。

但為了快速學習，我們這裡先將權限開到最大確保他動得起來XD

4. 在 GitHub Actions Workflow 使用 IAM Role

基於我們之前創建的 Workflow 中加入下面的permission和steps：

permissions:
  id-token: write   # 必須開啟，才能請求 OIDC Token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/YourRoleName
          aws-region: ap-east-1

      - name: CDK Deploy
        run: cdk deploy --require-approval never
        

arn號碼是AWS中用於辨識服務實體的編號，在這裡是指我們剛剛創建的 IAM Role
你可以在Console中點入你的Role的名稱來找到arn號碼，複製貼上於role-to-assume就對了！

當workflow執行時，可以看到Github Acitons成功執行了cdk deploy 只不過因為先前創建的L2 Bucket無法透過cdk來刪除，所以礙於s3 bucket的命名唯一性在L2 bucket的部分失敗了XD

當我們修改CDK的內容並重新commit至Github後

可以看到我們的自動化部署正式成功了！

可以在CloudFormation上看到我們部署的結果

最後我們來比較一下傳統常用的GitHub Secrets 金鑰管理方式和今天所介紹的 OIDC + IAM ROLE 的優劣勢！

結語

今天就正式完成了自動化部署的 Pipeline 建置！，從一開始只會 Console 點點到現在撰寫 IaC 並用 CI/CD 工具自動化部署流程是一段感人的旅程，希望各位對於今天的內容滿意！