はじめに
私が最近関わっているプロジェクトでは検証環境も本番環境も同じGWSアカウントで操作ができてしまいます。
このあたりの管理側のプロジェクト管理とかIAMの権限について実務でどうしたらいいのかについてはまだわかっていないのですが、GCSなどのはバケット名が世界で一意のものなため、Google Cloud CLIでGCPバケットの操作、閲覧をする際は現在のプロジェクト設定超えて操作できてしまいます。
コマンドミス一つで検証環境も本番環境も操作できてしまいます。
それでは怖いのでそれを防ぐ方法を調べて試してみました。
- 検証環境で使う操作アカウントを「検証用サービスアカウント（SA）」に限定する方法
- 本番への誤操作（プロジェクト取り違え・権限過多）を減らす考え方
- 実際にやってみて詰まった点と対処
先に結論（今回の運用）
- 検証環境の操作は「検証用SA」で行う
- 個人のGoogleアカウントで作業するのは本番だけに寄せる
背景：なぜ検証用サービスアカウントが必要だったか
- 弊社では全てのプロジェクトを同一のGWSアカウントで操作していた
- プロジェクトを取り違えて本番に対してコマンドを実行してしまう
- 多くの権限が付与されてるプロジェクトもあるため、誤って作業してしまい、影響範囲が大きくなる
前提として過剰な権限を与えないというのはありますが、現状グループ単位で権限が付与されており必要な権限の整理が大変なため、他のグループメンバーに影響しない方法で操作範囲を絞りたいというのがありました。
設計方針（最小権限・分離）
- 検証用SAには検証プロジェクトに必要な権限だけを付与する
- 別プロジェクトには検証用SAの権限を付けない
「なりすまし（Impersonation）」を使う
これが最近のGoogle Cloudで推奨されてる
通常、外部環境やローカルからサービスアカウントの権限を利用する場合、サービスアカウントキー（JSONファイル）を発行して認証を行うのが一般的でした。しかし、キーの発行には「漏洩のリスク」や「管理コスト」という大きな課題が伴います。
- *なりすまし（Impersonation）**は、自身のユーザーアカウント（または別のSA）に「一時的なアクセストークンを発行する権限」を付与することで、鍵ファイルを使わずに対象のサービスアカウントとして振る舞う仕組みです。
主なメリット：
- セキュリティの向上: 永続的な秘密鍵を発行・保存する必要がありません。
- 運用の簡略化: キーの更新作業（ローテーション）から解放されます。
やり方
前提条件
なりすましを行うには以下の権限が必要です。
-
ロール名:
roles/iam.serviceAccountTokenCreator（サービス アカウント トークン作成者）
手順
A. コマンドごとに指定する場合
コマンドの最後に --impersonate-service-account をつけるだけ！
gcloud storage ls --impersonate-service-account="[SERVICE_ACCOUNT_EMAIL]"
B. ずっとそのアカウントになりきって作業する場合
# 設定を有効にする
gcloud config set auth/impersonate_service_account [SERVICE_ACCOUNT_EMAIL]
# 終わったら解除
gcloud config unset auth/impersonate_service_account
これだけです。
またサービスアカウントが作業したことになるので、一部作成者が表示されるようなサービスだと通常ユーザーアカウント名が表示されますが、この方法だとサービスアカウント名が表示されるので本番環境などユーザーアカウントを表示させたくない時もこの方法が使えます。
おわりに
権限管理が複雑になりがちな大規模プロジェクトにおいて、個人のGoogleアカウント（GWS）ですべてを完結させるのは、常に「隣り合わせの事故」のリスクを孕んでいます。
今回紹介した「なりすまし」による運用は、設定自体は非常に簡単ですが、得られる安心感は絶大です。
もちろん、根本的な解決には「IAMグループの整理」や「最小権限の原則（PoLP）」の徹底が必要ですが、まずは「今すぐできる事故防止策」として、この運用を取り入れてみて良かったと感じています。
本番環境での「ヒヤリハット」を減らし、より開発に集中できる環境を整えていきましょう！