Help us understand the problem. What is going on with this article?

[GCP] ひとつのサービスアカウントで複数プロジェクトのリソースへアクセスする

はじめに

Hello Kids! 
キミはもう、たっぷり GCP 使えた ?
Google Cloud Certified Professional Cloud Architect とったキミも、
まだまだのキミも、「GCP」 に挑戦だ !!
How's your mouth rolling today !

なんとなく、イマクニ の ポケモン言えるかな? が頭をよぎったので書いちゃいました。

おふざけはこれでいいとして現在、PJ で GCP を使っています。
そこで、こんな要件が出てきました。

"ひとつのサービスアカウントで、複数プロジェクトのリソースへアクセスしたい"

要は、下図で説明すると service-account.json を持っている Host から、red-pj が抱える red-topic と yellow-pj が抱える yellow-topic のデータにアクセスをしたいということです。
GCP.png

サービスアカウントとは

そもそもサービスアカウントとは何かがよくわからない方のために説明すると、
通常、"アカウント"と単に言っても実際にそれを使用する対象は大きく 2 つのユーザが存在します。

  1. ユーザ(人間)
  2. ユーザ(アプリ)

1. ユーザ(人間)

一般的なアカウントとはこの、人間のために払い出されたアカウントです。
通常、みなさんが使用しているアカウントは全てこれと言っても過言ではないでしょう。
自分で、個人情報などを入力してパスワードを設定して・・・というフローを経て取得するのがこのアカウントです。

2. ユーザ(アプリ)

アプリからクラウド上の特定のサービスにアクセスするために、"アプリのために払い出されたアカウント"、これがサービスアカウントです。
当然ですが、クラウド上で構築したリソースに対してパブリックなアクセスを許してしまうとセキュリティ的に問題があります。
そのため、そのリソースに対してアクセスする最低限の権限(ロール)を付与した特別なアカウントを作成し、アプリはそのアカウントである証拠を持ってリソースにアクセスします。

ひとつのサービスアカウントで複数プロジェクトのリソースにアクセスするやり方

ここからが本題です。
そんなんできるん? て感じですが結論をいうとできます。
調べる中で こんな記事 を見つけましたがいまいち分かりにくいので自分で説明します。

大まかな流れとしては、red-pj で作成したサービスアカウントに対して yellow-pj で必要な権限を付与するといった形になります。

以降の画面では、
red-pj = gutomityan-redyellow-pj = guromityan-yellow
となっていますが適宜読み替えてください。

red-pj 上での作業

まず、red-pj でサービスアカウントを作成します。
image.png

必要な権限を選択 (ここでは、red-pj で必要な権限)
image.png

キーを作成 (JSON を選択)
image.png

ダウンロードしたキーはこのような形式になっています。

{
  "type": "service_account",
  "project_id": "xxxxxxxxxxxx",
  "private_key_id": "xxxxxxxxxxxx",
  "private_key": "-----BEGIN PRIVATE KEY-----xxxxxxxxxxxx",
  "client_email": "xxxxxxxxxxxx",
  "client_id": "xxxxxxxxxxxx",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": ""
}

見てわかる通り、秘密鍵が内包されています。
公開鍵は GCP で管理しているため、仮にサービスアカウントが流出してしまった場合は、その鍵を無効化することができますが、
間違っても、service-account.json を GitHub などに push しないように気をつけてください
「うちはプライベートリポジトリだから大丈夫♪」とか言わずに .gitignore に追加しましょう。
【実録】アクセスキー流出、攻撃者のとった行動とその対策

yellow-pj 上での作業

先ほど作成したサービスアカウント: service-account@red-pj.iam.gserviceaccount.comをコピーしてください。
次に、IAM 上で、「追加」をクリック。
image.png

先ほどコピーしたメールアドレスをペーストし、yellow-pj 上で必要な権限を選択し、保存。
image.png

これで作業は完了です。
あとはアプリ側で、環境変数 GOOGLE_APPLICATION_CREDENTIALSserivce-account.json への絶対パスを設定しておけば認証が通ります。
GCP ドキュメント - 認証の開始

最後に

書くのがめんどくさかったので割愛しましたが、今回の Cloud Pub/Sub で実際に動きを試したい場合は、以下の記事が参考になるかと思います。
pull を使用したメッセージの受信
2 つのプロジェクトそれぞれでトピックとサブスクリプションを定義し、Python コードを実行してみると、サービスアカウントでちゃんと認証されていることが確認できます。

また、よく "認証" と "認可" をごっちゃにしてしまいがちですが違います。
そこらへんを以前、少しだけまとめているためその違いは こちらの記事 を参考にしてみてください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした