前言：裸奔留給其他人，你的 API Key 不可以

準備好為我們的應用程式注入 AI 大腦了嗎？取得 Gemini API Key 的那一刻總是令人興奮，但請先冷靜一下！

因為在正式開始使用 AI 之前，有一件事情一定要先做好——保護你的 API Key。
很多人為了方便，會直接把 API Key 寫死在程式碼裡，或是放在 .env 檔案中，卻忘記加入 .gitignore。結果一個 git push，金鑰就可能直接出現在 GitHub 或其他公開平台上。

這不只是資安問題，更可能讓別人拿著你的 API Key 使用服務，最後帳單直接算在你頭上。更別說我們前幾天才剛設定好的預算警報，可能瞬間開始狂響。💸

所以今天除了要透過 Google AI Studio 取得 Gemini API Key，還要學會正確保護這把「AI 的鑰匙」。
這次我們會使用 Secret Manager，把 API Key 從程式碼中分離出來，安全地保存機密資訊。
AI 可以大方接進來，但 API Key 可不能跟著一起裸奔。 😎

動手實作 1：申請 Gemini API Key

Google AI Studio 提供了非常友善的介面與免費額度供開發者測試。

1. 前往 Google AI Studio。
2. 選擇左下角的鑰匙 icon 之後，選擇Import Project。
3. Import projects的視窗跳出後，勾選昨天建好的Project。
4. 選右上角的Create API Key，並選擇你的Project，輸入API名稱，這邊取Gemini API Key。

完成後會產生一組API Key。這樣就產生了你的Gemini API Key了，在這邊我們可以先把這個Key複製起來，但不要傳給任何人。

觀念解說：為什麼不用 .env 就好？

在本地端開發時，.env 確實很方便。但當我們準備將程式碼容器化並部署到 Cloud Run 時，把.env 一起打包進 Docker Image 是一個巨大的安全隱患。Google Cloud Secret Manager 就像是一個雲端的高級保險箱，我們的程式碼在執行時，才會動態地去向保險箱請求金鑰，做到「程式碼與機密配置完全分離」。

動手實作 2：將金鑰存入 Secret Manager

API Key 已經取得了，接下來我們要做的就是把它安全地交給 Google Cloud 管理。

啟用 Secret Manager API 並建立 Gemini API Key Secret

在 Google Cloud Console 搜尋 Secret Manager，進入後啟用 API。
啟用完成後，建立一個新的 Secret。
在建立畫面中名稱，輸入 GEMINI_API_KEY，密鑰值貼上剛剛複製的 Gemini API Key
確認無誤後，點選 「建立密鑰」 。
這樣一來，Gemini API Key 就不需要再直接寫進我們的程式碼或設定檔，而是交由 Secret Manager 保存。

授予 Cloud Run 存取權限

Secret 建立完成後，還有一個非常重要的步驟：
Cloud Run 必須先取得「讀取這個 Secret」的權限。
還記得我們昨天建立的 Service Account 嗎？

這次就要把 GEMINI_API_KEY 的讀取權限授予它。未來 Cloud Run 執行服務時，就會透過這個 Service Account 取得 API Key，操作方式如下：

1. 進入剛剛建立的 GEMINI_API_KEY。
2. 切換到 「權限」，點選 「授予存取權」。
3. 在 「新增主體」 輸入昨天建立的 Service Account，例如：cloud-run-executor@marathon-app-504603.iam.gserviceaccount.com
4. 在 「指派角色」 中選擇 「Secret Manager 密鑰存取者」（Secret Manager Secret Accessor）。
   確認後點選 「儲存」。

也就是說，Cloud Run 不需要知道 API Key 是什麼，只需要透過自己的 Service Account，向 Secret Manager 取得它需要的機密。
這樣就完成了第一層的安全隔離：API Key 留在 Secret Manager 裡，而不是寫進程式碼。

完成後，這個 Service Account 就具備讀取 GEMINI_API_KEY 的權限。
這裡的關係可以簡單理解成：

Cloud Run → Service Account → Secret Manager → GEMINI_API_KEY

Cloud Run 本身不需要把 API Key 寫在程式碼裡，而是透過自己的 Service Account，取得 Secret Manager 中保存的機密。

後續程式碼的呼叫：如何優雅地讀取 Secret

當我們的應用程式跑在 Cloud Run 時，Google Cloud 提供了一種掛載方式，可以直接把 Secret Manager 裡的值當作環境變數注入，可能會像是以下，舉個例子:

# 1. 部署時：在 Cloud Run 部署指令中將 Secret 映射為環境變數
gcloud run deploy my-spring-boot-api \
  --image asia-east1-docker.pkg.dev/your-project-id/my-repo/my-api:latest \
  --region asia-east1 \
  --service-account cloud-run-executor@your-project-id.iam.gserviceaccount.com \
  # ✨ 關鍵參數：告訴 Cloud Run 把 Secret Manager 裡的 GEMINI_API_KEY 最新版本注入給環境變數
  --set-secrets "GEMINI_API_KEY=GEMINI_API_KEY:latest"

後端程式碼會像是以下:

// 2. 應用程式內部 (Java / Spring Boot 範例)
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class GeminiConfig {

    // Spring Boot 會自動去環境變數（或 application.yml）中尋找 GEMINI_API_KEY 並注入
    @Value("${GEMINI_API_KEY}")
    private String geminiApiKey;

    @Bean
    public GeminiClient geminiClient() {
        if (geminiApiKey == null || geminiApiKey.isBlank()) {
            throw new IllegalStateException("❌ 致命錯誤：找不到 GEMINI_API_KEY 環境變數！");
        }
        
        // 成功讀取！將金鑰交給 Gemini API Client 進行初始化
        // (這裡以假想的 Client 類別為例，實務上可依照你使用的 SDK 調整)
        return new GeminiClient(geminiApiKey);
    }
}

【重點解析】
透過這種方式，程式碼裡完全看不到任何真實的 API Key。我們只負責呼叫環境變數，至於環境變數怎麼來的？那是 Cloud Run 透過 Secret Manager 安全注入的！這正是現代雲端原生 (Cloud Native) 應用的標準作法。

今日總結與明日預告

今天成功透過 Google AI Studio 快速取得了 Gemini API，並學會了如何用 Secret Manager 保護我們的 API 金鑰。環境、權限、金鑰都準備就緒了！

為了讓接下來的開發旅程更有方向感，規劃將後續的實戰拆分為三大核心階段：

• 第一階段：後端實作與雲端部署
  • 目標：從零打造具備 AI 記憶力與防護機制的後端 API，並將其打包部署至 Google Cloud 雲端上。
• 第二階段：前端開發與 API 串接
  • 目標：使用 React Native 打造跑者專屬的 APP 介面，並完成與雲端大腦的前後端資料串接。
• 第三階段：體驗優化與最終上線
  • 目標：打磨 UI/UX 細節與操作流暢度，最後將 APP 部署至實體手機上進行全面測試與專案總結。

明天（Day 6），即將正式踏入第一階段，啟動「KAKERU」後端專案的建置。準備好在你的 IDE 裡敲下第一行 AI 互動程式碼了嗎？我們明天見！