fix: with-ai-dev のアカウントグループが default のままで、withjp アカウントの認証情報が nyle 系プロジェクトと共有されている

[takemi-ohama]

概要

#116 でアカウントグループ単位の永続化ボリューム分離が実装されましたが、with-ai-dev プロジェクトにはグループの指定が入っておらず、default グループのまま起動しています。

その結果、withjp.inc のアカウントで認証した情報が、nyle.co.jp 系のプロジェクトと同じボリュームへ書き込まれます。#116 の問題2として挙げられていたアカウントの混線が、このプロジェクトで実際に起きている状態です。

実態

稼働中のコンテナで確認した内容です。

項目	#116 での想定	実際の値
DEVBASE_ACCOUNT_GROUP	with	default
AWS_PROFILE	with	default
GCP_ACTIVE_PROFILE	with	default
/persistent/group のボリューム	devbase_home_with	devbase_home_default

$ docker inspect <container> --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{"\n"}}{{end}}'
devbase_home_ubuntu  -> /persistent/ai
devbase_home_default -> /persistent/group
devbase_work_1       -> /work

グループ別ボリュームの一覧です。devbase_home_with は作成されていません。

$ docker volume ls | grep devbase_home
devbase_home_default
devbase_home_kkg
devbase_home_ubuntu

kk-generation 側は devbase_home_kkg が作られており、仕組み自体は動いています。設定が入っていないのは with-ai-dev だけです。

同じ devbase_home_default を、稼働中の次のコンテナが共有しています。

ideabase-dev-1 / ideabase-dev-2
ai-plugins-dev-1
carmo-system-console-dev-1 / carmo-system-console-dev-2

何が起きるか

グループ別ボリュームに置かれる認証情報が、企業をまたいで共有されます。実際に次の事象を確認しました。

1. Google Workspace CLI の認証が上書きされる。 with-ai-dev のコンテナで withjp.inc のアカウントにログインしたところ、/persistent/group/gws/credentials.enc が置き換わりました。このファイルは nyle 系プロジェクトのコンテナからも同じパスで参照されるため、そちらの認証も withjp.inc のものに変わります。

2. OAuth クライアントのプロジェクトが合わない。 /persistent/group/gws/client_secret.json は nyle 側の GCP プロジェクトで作られたものです。withjp.inc のアカウントでログインすると、API 呼び出し時にクォータプロジェクトの権限エラーになります。

Caller does not have required permission to use project <nyle側のプロジェクト>.
Grant the caller the roles/serviceusage.serviceUsageConsumer role ...

環境変数でクォータプロジェクトを差し替えても解消しません。OAuth クライアントが属するプロジェクトが使われるため、グループごとに別のクライアントを持つ必要があります。

3. 別グループのトークンが残っている。 /persistent/group/gcloud/ に kk-generation 向けのアクセストークンのファイルが残っていました。分離前の共有状態の名残と見られます。

4. アクセストークンのキャッシュが認証情報より優先される。 再ログイン後も古いアカウントで API が呼ばれる事象がありました。credentials.enc は更新されている一方、token_cache.json が前のアカウントのまま残っていたためです。ログイン時にキャッシュを破棄する挙動になっていると、切り替え直後の混乱を避けられます。

対処案

projects/with-ai-dev/env に #116 の記載どおり 3 行を追加し、コンテナを再作成する。

DEVBASE_ACCOUNT_GROUP=with
AWS_PROFILE=with
GCP_ACTIVE_PROFILE=with

再作成すると devbase_home_with が新規に作られ、空の状態でマウントされます。

再作成後に必要な再認証

グループ別ボリュームが空になるため、#116 の分類 B に当たるものを取り直します。

対象	方法
Claude Code の認証と MCP 接続	起動時に再ログイン。Atlassian / Google Drive などの MCP も繋ぎ直す
gcloud のユーザー認証	withjp.inc のアカウントで gcloud auth login
Google Workspace CLI	withjp 側の GCP プロジェクトで作った OAuth クライアントを配置して gws auth login

確認したい点

• 他プロジェクトのグループ指定。 default のまま動いているコンテナが 5 つあります。nyle 案件であれば default が正しい想定ですが、意図した状態かを確認したいです。
• GCP プロジェクト系の環境変数。 GOOGLE_CLOUD_PROJECT / GOOGLE_APPLICATION_CREDENTIALS / BIGQUERY_KEY_FILE が default グループの値のままです。グループごとに切り替わる仕組みがあるか、projects/*/env で個別に指定する運用かを整理したいです。
• OAuth クライアントの配布方法。 グループごとに別の OAuth クライアントが要ります。環境変数で配って entrypoint が復元する形にするか、グループボリュームへ手で置く運用にするかを決めたいです。

[takemi-ohama]

対応 PR

takemi-ohama/devbase-ext#18 を出しました。projects/* は plugin repo への symlink のため、修正は devbase 本体ではなくそちらに入ります。

実機で確認した内容

issue の記載を実機で追ったところ、報告どおりの状態に加えて 2 点の食い違いがありました。

1. project-trygroup-prd も default のままだった

「設定が入っていないのは with-ai-dev だけ」とありますが、project-trygroup-prd にも DEVBASE_ACCOUNT_GROUP は入っていません。git 管理下の projects/*/env、暗号化ストア secrets/projects/*.env.age、グローバル env のいずれにも DEVBASE_ACCOUNT_GROUP の記述はありませんでした。

$ docker inspect project-trygroup-prd-dev-1 --format '{{range .Config.Env}}{{println .}}{{end}}' | grep DEVBASE_ACCOUNT_GROUP
DEVBASE_ACCOUNT_GROUP=default

devbase_home_kkg ボリュームは存在しますが、どのコンテナからもマウントされていません。稼働中の dev コンテナ 15 本すべてが devbase_home_default を共有していました。手動で DEVBASE_ACCOUNT_GROUP=kkg を付けて起動した際の残骸と見られます。

グループボリュームの中身にも痕跡があります（issue の事象 3 と同じもの）。

$ docker exec with-ai-dev-dev-1 ls /persistent/group/gcloud
... kkg_sheets_token.json ...
$ docker exec with-ai-dev-dev-1 ls /persistent/group
.claude  .claude.json  .gemini  gcloud  gws  gws-withjp

gws と gws-withjp が併存しているのは、混線を手動で回避した跡と思われます。

2. 3 行の追加だけでは nyle の SA 鍵が残る

対処案の 3 行だけでは不十分でした。GCP_ACTIVE_PROFILE=with にしても GCP_AUTH_MODE は key のままになります。

lib/devbase/env/gcp_auth.py の has_service_account_key() は、プロファイル別の GCP_CREDENTIALS_BASE64__with が無いとき後方互換キー GOOGLE_APPLICATION_CREDENTIALS_BASE64 へフォールバックします。この変数はグローバル env に nyle の BigQuery サービスアカウント鍵として存在するため、resolve_auth_mode() が key を返し続けます。実機の with-ai-dev コンテナも GCP_AUTH_MODE=key で、GOOGLE_APPLICATION_CREDENTIALS=/home/ubuntu/.config/gcloud/credentials.json に nyle の鍵が書き出されていました。

PR では GCP_AUTH_MODE=adc を明示し、gcloud auth login によるユーザー認証へ倒しています。

3. gcloud は nyle アカウントでログイン済みだった

issue の事象 1・2 の裏付けです。

$ docker exec with-ai-dev-dev-1 gcloud auth list
     Credentialed Accounts
ACTIVE  ACCOUNT
*       takemi_ohama@nyle.co.jp

$ docker exec with-ai-dev-dev-1 ls /persistent/group/gcloud/legacy_credentials
takemi_ohama@nyle.co.jp

確認したい点への回答

他プロジェクトのグループ指定

稼働中の dev コンテナを repo の owner で分類しました。

プロジェクト	リポジトリの owner	適切なグループ
with-ai-dev	takemi-ohama（withjp 案件）	with → PR で対応
project-trygroup-prd (+ -customer)	KK-Generation	kkg → PR で対応
carmo-ai / carmo-cdk / carmo-system-console / bi-tools / nyle-dx	volareinc	default のままで正しい
ai-plugins / md-specgen / github_work_time	devbasex	default のままで正しい
uttaro-system	uttaro-dev2	別組織なので要判断
ideabase	takemi-ohama（個人）	個人利用なら default で可、要判断

uttaro-system は GitHub org が uttaro-dev2 で、#116 の表にある 3 分類のどれにも当てはまりません。別グループが要るかご判断ください。

GCP プロジェクト系の環境変数

グループごとに切り替わる仕組みはありません。 プロファイルを見るのは GCP_CREDENTIALS_BASE64__<profile> の 1 本だけで、GOOGLE_CLOUD_PROJECT / BIGQUERY_PROJECT / BIGQUERY_DATASET / BIGQUERY_LOCATION はグローバル env の値がそのまま全コンテナへ流れます。したがって projects/*/env で個別に上書きする運用になります。

PR では nyle の値を持ち込まないよう空で上書きしました（AWS_CONFIG_BASE64= と同じ書き方）。各社の値が必要になった時点で書き足す方針です。

OAuth クライアントの配布方法

この点は未決のまま残しています。 判断材料として、両案の差分を整理しました。

方式	利点	欠点
環境変数で配って entrypoint が復元	devbase env sync の対象になり、マシンを変えても再現する。既存の GCP_CREDENTIALS_BASE64__<profile> と同じ構造に乗る	devbase 本体の改修が要る（キー定義・entrypoint・compose 生成）
グループボリュームへ手で置く	追加実装なし。今日から運用できる	ボリュームを消すと失われる。手順が属人化する

client_secret.json はプロファイル別キーの仕組みがそのまま使えるため、中長期には前者が素直だと考えています。ご意向をいただければ別 issue に切り出します。

残課題

GCP_CREDENTIALS_BASE64__default と GOOGLE_APPLICATION_CREDENTIALS_BASE64 は、生成 compose に名前だけの列挙として残ります。GCP_AUTH_MODE=adc によって entrypoint はこれをファイルへ書き出さなくなりますが、値（nyle の SA 鍵 JSON）は他社コンテナの環境変数として読める状態が続きます。

根本的には、アクティブプロファイル以外の GCP_CREDENTIALS_BASE64__* と、adc モード時の GOOGLE_APPLICATION_CREDENTIALS_BASE64 を dev サービスの列挙から外す devbase 本体側の対応が要ります。必要であれば別 issue を立てます。

[takemi-ohama]

対応完了の報告

takemi-ohama/devbase-ext#18 をマージし、実機のコンテナを再作成して検証しました。

検証結果

確認項目	with-ai-dev-dev-1	project-trygroup-prd-dev-1/2
/persistent/group	devbase_home_with ✅	devbase_home_kkg ✅
DEVBASE_ACCOUNT_GROUP	with ✅	kkg ✅
AWS_PROFILE / GCP_ACTIVE_PROFILE	with / with ✅	kkg / kkg ✅
GCP_AUTH_MODE	adc ✅	adc ✅
~/.config/gcloud/credentials.json（nyle の SA 鍵）	書き出されず ✅	書き出されず ✅
gcloud auth list	nyle が消えた ✅	takemi_ohama@kk-generation.com ✅

/persistent/ai（共通資産）と /work は保持され、default グループの 12 コンテナは無変更です。

残骸の移動

事象 3 で指摘のあった別グループのファイルを、それぞれの所属グループへ移しました。コピー → md5 検証 → 動作確認 → 移動元削除の順で実施しています。

対象	移動元	移動先
gws 一式（withjp の OAuth クライアント gws-client-507311 + 認証情報）	devbase_home_default:/gws-withjp/	devbase_home_with:/gws/
kkg_sheets_token.json	devbase_home_default:/gcloud/	devbase_home_kkg:/gcloud/

これにより with-ai-dev の gws は再認証なしで使える状態になりました。

"user":       "ohama.takemi@withjp.inc"
"project_id": "gws-client-507311"
"token_valid": true

未解消: default グループの gws が withjp アカウントのまま

分離前の上書き（事象 1）の影響が devbase_home_default に残っています。

$ docker exec carmo-ai-dev-1 gws auth status
"project_id": "nyle-carmo-analysis"      ← OAuth クライアントは nyle
"user":       "ohama.takemi@withjp.inc"  ← 認証アカウントは withjp

この組み合わせでは事象 2 の roles/serviceusage.serviceUsageConsumer エラーになります。default グループのコンテナ 1 つで入り直せば、共有ボリュームなので 12 コンテナすべてに反映されます。

rm -f /persistent/group/gws/token_cache.json   # 事象 4 を避けるため先に破棄
gws auth login                                  # takemi_ohama@nyle.co.jp

確認したい点の決着

• 他プロジェクトのグループ指定 — uttaro-system（uttaro-dev2 org）は業務委託契約が終了し当面稼働しないため、default のまま据え置きと判断いただきました。他のプロジェクトは owner が volareinc / devbasex で default が正しい状態です
• GCP プロジェクト系の環境変数 — グループごとに切り替わる仕組みはなく、projects/*/env での個別上書き運用。今回は nyle の値を持ち込まないよう空で上書きしました
• OAuth クライアントの配布方法 — 未決。今回は手動配置（グループボリュームへ配置）で運用が成立しましたが、GCP_CREDENTIALS_BASE64__<profile> と同じく環境変数で配る方式にするかは判断待ちです

別途対応が必要な残課題

GCP_CREDENTIALS_BASE64__default と GOOGLE_APPLICATION_CREDENTIALS_BASE64 は生成 compose に名前だけの列挙として残るため、値（nyle の SA 鍵 JSON）は他社コンテナの環境変数として読める状態が続きます。アクティブプロファイル以外の鍵を dev サービスの列挙から外す devbase 本体側の対応が必要です。

[takemi-ohama]

残課題として挙げていた「非アクティブプロファイルの GCP サービスアカウント鍵が dev の列挙に残る」件を #134 に切り出しました。

この issue（#133）で残っているのは次の 2 点です。

• default グループの gws 再ログイン（分離前の上書きの残存。nyle 系コンテナ 1 つで gws auth login すれば 12 コンテナに反映）
• OAuth クライアントの配布方法（手動配置で運用は成立。環境変数配布方式にするかは未決）

[takemi-ohama]

決着

残っていた「OAuth クライアントの配布方法」は グループボリュームへの手動配置で確定 としました。環境変数で配る方式は採りません。

理由:

• 今回 with-ai-dev で実際に運用が成立している。gws auth status は ohama.takemi@withjp.inc / project_id: gws-client-507311 / token_valid: true を返す
• 環境変数方式は devbase 本体の改修（キー定義・entrypoint の復元処理・compose 生成）が要る一方、得られるのは「マシン移行時の再現性」だけ。利用者 1 名・マシン 1 台の現状では割に合わない
• 必要になった時点で GCP_CREDENTIALS_BASE64__<profile> と同じ構造に乗せられる。今決め打つ必要がない

新しいアカウントグループを作るときの手順

グループボリュームは空で作られるため、gws を使うなら次のどちらかを行います。

A. そのグループで新規に認証する

# 対象グループのコンテナ内で
# 1. そのグループの GCP プロジェクトで作った OAuth クライアントを配置
cp <client_secret.json> /persistent/group/gws/client_secret.json
# 2. 認証
gws auth login

B. 既存ボリュームから移す（別グループで作った資産を引き継ぐ場合）

docker run --rm \
  -v <移行元ボリューム>:/src \
  -v <移行先ボリューム>:/dst \
  alpine:latest sh -c '
    cp -a /src/<gws ディレクトリ>/. /dst/gws/
    chmod 700 /dst/gws && chown -R 1000:1000 /dst/gws'

コピー後に md5 で照合し、コンテナ内で gws auth status が期待するアカウントを返すことを確認してから移行元を消します。

この issue の対応まとめ

論点	決着
アカウントグループ未設定	takemi-ohama/devbase-ext#18 で with / kkg を設定。実機で分離を確認
GCP_AUTH_MODE が key に倒れる	同 PR で adc を明示。nyle の SA 鍵がファイル化されなくなった
鍵の実体が env として残る	#134 → #135 で compose 生成側から除外
default グループの gws が withjp のまま	nyle アカウントで再ログイン済み。takemi_ohama@nyle.co.jp / token_valid: true を確認
別グループの残骸（kkg_sheets_token.json / gws-withjp）	それぞれ devbase_home_kkg / devbase_home_with へ移動済み
他プロジェクトのグループ指定	uttaro-system は業務委託契約終了で default 据え置き。他は owner が volareinc / devbasex で default が正しい
GCP プロジェクト系の環境変数	グループ連動の仕組みは無く、projects/*/env での個別上書き運用。nyle の値は空で打ち消し済み
OAuth クライアントの配布方法	手動配置で確定（本コメント）

派生した issue

issue	内容	状態
#134	非アクティブプロファイルの鍵が env で渡る	CLOSED（#135）
#136	新規グループの .claude.json が 0 バイトで Claude Code が起動しない	CLOSED（#137）
#139	devbase build <image> が失敗する	OPEN

すべて決着したためクローズします。