沒有自動佈署就好像吃麵沒有筷子。

既然是做專案，想要持續優化與擴展功能，就不能落掉 CI/CD 這個環節。
至於什麼是 CI/CD... Google 一下、或問問 GPT 都能找到定義。
AI 還會一直問你要不要畫圖
不過 CI/CD 的範圍包山包海，一時間也很難完整實作，這次就先從開發者最有感的需求切入，為開發流程加上自動佈署的機制！

接下來，會使用開發人員都熟悉的 Git + AWS OIDC 來實作自動佈署的流程。

GitHub Actions 搭配 AWS OIDC。

AWS OIDC
AWS 上使用的身分驗證協定： OpenID Connect (OIDC) 。

OIDC 是建立在 OAuth 2.0 授權協定上的身份驗證層，主要用於讓外部（例如 GitHub、Google 等）實現登入和委派存取權限，且 不需要自行管理憑證或是金鑰。
常用於授權 AWS 資源存取，也很適合用來處理自動化流程。

實作方式：

• 在 AWS IAM 中建立 OIDC 身分供應商 (Identity Provider)
• 讓 GitHub Actions 能以「臨時授權」的方式安全登入 AWS
• 透過 GitHub workflow 自動佈署 Lambda

GitHub Push → GitHub Actions 觸發 → OIDC 驗證 → Assume Role → Deploy Lambda

在 AWS 建立 IAM Identity providers

• 進入功能 IAM > Identity providers (身分供應商)，並按下「新增供應商」
  
• 填入資訊
  
  供應商 URL

  https://token.actions.githubusercontent.com
  

  對象

  sts.amazonaws.com
  

• 建立完成
  

為 GitHub 驗證設定權限

從開篇強調到現在第 26 天，對雲端的授權機制都快變成反射動作了。

• 進入 IAM → Roles → Create role
  這次終於不是自訂信任政策，而是選擇「Web 身分」，並在身分供應商中選擇「github」
  

• 新增許可直接跳過，到下一步輸入 Role 名稱：
  
  在這個畫面就可以看出前面填寫的內容，最後被組合成 AWS 的信任政策

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Principal": {
                "Federated": "arn:aws:iam::590184072539:oidc-provider/token.actions.githubusercontent.com"
            },
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": [
                        "sts.amazonaws.com"
                    ]
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": [
                        "repo:MinxSu/ITHome-ironman-2025:ref:refs/heads/develop"
                    ]
                }
            }
        }
    ]
}

其中的 token.actions.githubusercontent.com:sub 會用來決定哪個 repo 或是 branch　可以被授權

這樣設定後，只有 MinxSu/ITHome-ironman-2025 這個 repo 的 develop 分支 執行 workflow 時，
才會被允許 Assume Role，大大提升了安全性。

建立 AWS Role 許可政策

建立完成後，基於這個 Role 要能更新 Lambda，所以必須為 Role 加上相關授權。

• 點選剛剛建立的角色，進入「許可」頁籤，新增許可(建立內嵌政策)
  
• 編輯指定許可
  
  在 Resource 的陣列中填入指定的 Lambda ARN，確保這個 Role 只能用來更新指定的 Lambda 服務

{
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:UpdateFunctionCode"
      ],
      "Resource": "arn:aws:lambda:<REGION>:<ACCOUNT_ID>:function:<FUNCTION_NAME>"
    }

• 檢視一下建置內容，並輸入政策名稱
  
• 建置完成
  

為什麼 Create Role 的時候跳過，建好才又回頭補？

這是因為在建置過程中，編輯許可政策的畫面只能從 AWS 預先做好的設定值中作選擇。
如果想透過自行編寫 JSON 進行更精細的控管，就只能先建立完 Role 再編輯許可政策做更新。

統整

最後說明一下 OIDC 機制的詳細資訊 和 Identity Provider 設定值

https://token.actions.githubusercontent.com

這是 GitHub 提供的 OIDC Identity Provider 固定 URL。
當 GitHub Actions 執行 workflow 時，會透過自己的 OIDC 端點 (也就是 https://token.actions.githubusercontent.com) 發行一個具簽章的 OIDC token。

sts.amazonaws.com

當 AWS STS 收到這個 GitHub 的 token，會依據 IAM 中設定的信任條件進行驗證：

• iss（Issuer）是否等於 https://token.actions.githubusercontent.com
• aud 是否等於信任的值（通常是 sts.amazonaws.com）
• 其他 claim（例如 sub）是否符合 IAM Role 的 trust policy 條件

檢核通過後，STS 會簽發臨時憑證（temporary credentials）。
GitHub 就能透過這個短期授權的臨時憑證，對 AWS Account 內的資源進行操作。

更詳細的內容可參考官方文件：在 IAM 中建立 OpenID Connect (OIDC) 身分提供者

補充資訊

AWSSSO_DO_NOT_DELETE
在建立 Identity Provider 的過程中，出現了一個神祕的設定值：AWSSSO_DO_NOT_DELETE
它在啟用身分驗證相關服務時，AWS 會自動建立的 provider。名稱通常類似：AWSSSO_xxx_DO_NOT_DELETE

常見會觸發自動建立的情境有：

1. AWS Control Tower
2. AWS IAM Identity Center（前身為 AWS SSO）
3. 當 AWS Organizations 與 SSO 功能整合時

大致上，這些資源都是因應 系統授權需求 而產生的。
AWS 透過自動建立的 AWSSSO_DO_NOT_DELETE，確保平台能擁有正確的權限與信任關係，避免因人為設定錯誤導致登入不安全。同時，它也是 Identity Center（SSO）正常運作所必須的角色。若被刪除，登入與授權流程將無法正常使用。