fix(gcp): 使われない GCP 鍵を dev の列挙から外す

[takemi-ohama]

Closes #134

背景

GCP_AUTH_MODE=adc が止めるのは鍵をファイルへ書き出すことだけで、環境変数としての配布は止まりません。GCP_CREDENTIALS_BASE64__* と GOOGLE_APPLICATION_CREDENTIALS_BASE64 は生成 compose の environment に名前だけの列挙として残るため、Compose が値を解決してコンテナへ渡します。

#133 でアカウントグループを分離した後も、他社のコンテナから env で nyle のサービスアカウント鍵の中身が読める状態が続いていました。

$ docker exec with-ai-dev-dev-1 env | grep GCP_CREDENTIALS_BASE64__default
（3172 文字 / デコードすると project_id=nyle-carmo-analysis の private_key）

変更内容

gcp_auth.dev_excluded_env_names() を追加し、dev の列挙から外す名前をここへ集約しました。

対象	判定	理由
GOOGLE_APPLICATION_CREDENTIALS / BIGQUERY_KEY_FILE	adc のとき外す（従来どおり）	実体の無いパスが DefaultCredentialsError を招く
GCP_CREDENTIALS_BASE64__<非アクティブ>	常に外す	entrypoint はアクティブプロファイルの 1 本しか読まない
GOOGLE_APPLICATION_CREDENTIALS_BASE64	鍵モード かつ アクティブの鍵が無いとき以外は外す	そのときだけ実際の供給源になる

3 行目が要点です。entrypoint は ${!var:-${GOOGLE_APPLICATION_CREDENTIALS_BASE64:-}} でフォールバックするため、一律に外すとプロファイル別キーへ未移行のプロジェクトが鍵を受け取れず壊れます。

判定には os.environ と「生成 compose へ列挙する名前」の両方を候補にしています。runtime.inject の呼び出し順に依存させないためです。

除外を dev だけに効かせる方針は踏襲しました。共通機密から鍵を受け取っていた非 dev サービス（独自に鍵を持つ batch 等）の列挙は絞りません。

この PR だけでは閉じないケース

アクティブプロファイルの鍵が無く、GCP_AUTH_MODE=adc も宣言していない構成では、後方互換キーが has_service_account_key() のフォールバックを通って鍵モードを引き起こし、そのまま残ります。これは #133 で with-ai-dev が踏んだ経路そのものです。

この場合は供給源なので外せません。プロジェクト側の GCP_AUTH_MODE=adc 宣言と組み合わせて初めて他社の鍵が渡らなくなります。挙動を明示するため test_legacy_key_still_drives_auto_key_mode としてテストに残しました。

テストプラン

• pytest tests/ 全件: 1714 passed（既存テストの期待値は 1 つも変更していません）
• ruff check --select=E9,F63,F7,F82 lib（CI と同じ）: All checks passed
• 単体テスト 9 件を tests/env/test_gcp_auth.py に追加（非アクティブ鍵の抽出、後方互換キーの 3 条件、空文字の扱い、重複排除）
• 生成 compose の結合テスト 6 件を tests/volume/test_compose_gcp_auth.py に追加
• 実環境の projects/*/env を使って生成 compose を作り、dev の environment を確認

実環境での生成結果:

プロジェクト	GCP_ACTIVE_PROFILE	dev に載る鍵系の名前
with-ai-dev	with	なし（GCP_AUTH_MODE=adc のみ）
project-trygroup-prd	kkg	なし（GCP_AUTH_MODE=adc のみ）
carmo-ai	未設定（default）	GCP_CREDENTIALS_BASE64__default / GOOGLE_APPLICATION_CREDENTIALS / BIGQUERY_KEY_FILE（従来どおり）

carmo-ai では GOOGLE_APPLICATION_CREDENTIALS_BASE64 も外れます。アクティブプロファイルの鍵が揃っておりフォールバックが発生しないためで、entrypoint の挙動は変わりません。

• devbase up でコンテナを再作成し、docker exec <c> env | grep BASE64 に他社の鍵が出ないことを確認（マージ後に実施）

関連

• fix: with-ai-dev のアカウントグループが default のままで、withjp アカウントの認証情報が nyle 系プロジェクトと共有されている #133 — アカウントグループが default のままで認証情報が共有されていた件（発見元）
• feat: 永続化ボリュームをアカウントグループ単位に分離し、gcloud/gws の認証情報を永続化する #116 — アカウントグループによる永続化ボリューム分離
• takemi-ohama/devbase-ext#19 — 同じ露出を空文字上書きで塞ぐ暫定措置。この PR がマージされたら撤去する

補足: ローテーションについて

#134 で「配られた鍵の失効・再発行が必要か」を確認事項に挙げていましたが、利用者が 1 名で同一のためローテーションは不要と判断いただきました。

🤖 Generated with Claude Code

https://claude.ai/code/session_01NMEpP29QkUDLwrsyYjpnDL

[takemi-ohama]

🤖 cross-review | round 1 | codex | REQUEST_CHANGES

ADC時および元Composeの直書き経路で、未使用のGCP秘密鍵がdevコンテナへ残るため、除外処理を全経路へ適用してください。

[takemi-ohama]

🤖 cross-review | round 1 | gemini | APPROVE

修正提案はありません。

[takemi-ohama]

🤖 cross-review | round 2 | codex | APPROVE

修正提案はありません。

[takemi-ohama]

🤖 cross-review | round 2 | gemini | APPROVE

ロジックは安全かつ適切で、テストの網羅性も高いため問題ありません。別プロファイルの鍵漏洩を確実に防ぐ実装になっています。