Google認証の「魔法」の正体を解き明かす

https://www.googleapis.com/auth/compute.readonly

import google.auth
creds, project = google.auth.default()

gcloud compute instances create instance-1 ... \
    --scopes=cloud-platform,

gcloud compute ssh instance-1 -- python3
>>> import google.auth
>>> creds, project = google.auth.default()
>>> from google.auth.transport import requests
>>> creds.refresh(requests.Request())
>>> creds.scopes
['\
```\
\
[https://www.googleapis.com/auth/cloud-platform'](https://www.googleapis.com/auth/cloud-platform%27)\
\
```\
, '\
```\
\
[https://www.googleapis.com/auth/drive'](https://www.googleapis.com/auth/drive%27)\
\
```\
]
````

GCEとGKEで「比較的恵まれている」と書いたのは、スコープが作成時にしか指定できないからです。VMが1台ならまだしも、GKEではスコープを1つ追加するためだけにノードプール全体を作り直す羽目になることもあります。

結局のところ、コード自体は変わらないものの、事前にDevOps的な仕込みが欠かせない、というわけです。

とはいえ、VMにあらかじめ許可されて_いない_スコープでも認証情報を取得する方法はあります。これについては記事の後半で解説します。

#### Google App Engine

App EngineはGCPでも最古参のサービスのひとつで、多くの面で時代を先取りした本格的なサーバーレスフレームワークです。ただし、長い歴史にはレガシーな制約もつきものです。そのひとつが、すべてのApp Engineアプリのスコープが`cloud-platform`に固定されていて、簡単には抜け出せないという点です。

回避策のひとつは、デフォルトのApp Engineサービスアカウントから別のサービスアカウント、あるいは自分自身に「なりすまし(impersonate)」を行いつつ、新しいスコープを要求する方法です。Google Cloudの公式ドキュメントは[**こちら**](https://cloud.google.com/iam/docs/understanding-service-accounts#acting_as_a_service_account)。Pythonでの書き方を見てみましょう。

````
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
svcacc = "test
````

[@my-project-id.iam.gserviceaccount.com](mailto:[email protected])

`cache_discovery=False`引数に注意してください——[バグ](https://github.com/googleapis/google-api-python-client/issues/299)のため、これを付けないと動きません。上のコードを動かすには、プロジェクト内のAppEngineデフォルトサービスアカウントから対象のサービスアカウントへ、Token Creatorロールを付与する必要もあります。

[appspot.gserviceaccount.com](https://console.cloud.google.com/iam-admin/serviceaccounts/details/108759703281763060579?authuser=1&project=zaar-playground)

**このアプローチには重要なセキュリティ上の注意点がある**ことを忘れないでください——同じプロジェクト内のApp Engineサービスはすべて _同一のサービスアカウント_ で動作します。つまり _そのすべて_ がなりすましを実行できてしまうため、セキュリティ上の懸念になり得ます。

残念ながら手軽な回避策はありませんが、解決策は記事の後半で紹介します。

**2021年11月のアップデート:** 現在App Engineでは、サービスごとに[カスタムサービスアカウントを指定できる](https://cloud.google.com/appengine/docs/standard/python3/user-managed-service-accounts)ようになりました。

#### Cloud Run / Functions

Cloud RunサービスやCloud Functionをデプロイするときには、スコープに関する話は一切登場しません——ようやくです! 必要なスコープを次のようにその場で要求できるなら、わざわざ事前に縛り付けておく必要はありませんよね。

````
import google.auth
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
creds, _ = google.auth.default(scopes=SCOPES)
````

あとは、お好みのAPIで普段どおりに処理を進めるだけです。完全な例は[こちら](https://medium.com/@guillaume.blaquiere/yes-my-experience-isnt-the-same-63ac3c783864)を参照してください。

個人的には、GKE/GCE/GAEでも本来こうあるべきだったと思っています。

念のため——GCE/GKEで同じことをやっても期待した動きにはなりません。GCE/GKEでは、アプリ内で要求したスコープは無視され、VMやノードプールに設定されたスコープに上書きされてしまいます。

#### **ローカル開発環境**

Google Directory APIを触り始めたとき、APIを呼び出すには**必ず**GCPサービスアカウントが必要で、対象APIを有効化したGCPプロジェクトもきちんと用意しなければならないと知って、驚いたのを覚えています。

ローカル開発環境(つまり手元のノートPC)で取得したADC認証情報は、通常は個人ユーザーに紐づいているため、Directory APIをはじめとする多くの非GCP APIではほぼ使い物になりません。

結局のところ、ここでもなりすましを使うしかなく、上のGAEのセクションで紹介したコードがそのまま流用できます。

## サブジェクト(Subject)とは

サブジェクトは、認証のブートストラップコードをさらに複雑にする、ちょっとした要素です。_Directory API_にアクセスする(たとえばG Suiteドメインのユーザー一覧を取得する)場合、ディレクトリ内の特定ユーザーの代理として動作することになり、そのユーザーを認証情報の_subject_として指定する必要があるのです。

これを踏まえると、ローカル開発環境からの実行は、なりすましがぐるりと一周する構図にもなり得ます——ローカルで認証された`[email protected]`が、自ドメインのDirectory APIと通信するためにサービスアカウントになりすまし、そのサービスアカウントが今度はディレクトリ内で`[email protected]`として動作する、というわけです。

いずれにせよ、この「act as」のメールアドレスを認証情報のサブジェクトとして指定する必要があり、認証セットアップのコードは次のように膨らみます。

[https://accounts.google.com/o/oauth2/token](https://accounts.google.com/o/oauth2/token)

````
"
SCOPES = ["\
```\
\
[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/spreadsheets.readonly)\
\
```\
"]
svcacc = "test
````

[@my-project-id.iam.gserviceaccount.com](mailto:[email protected])

このコードはここまで紹介したすべてのケースで動きます——Directory APIを使わない場合は`subject=None`を渡し、Token Creatorロールを適切に割り当てるのを忘れないでください。

**これで解決策が手に入りました!** ……とはいえ、このアプローチを「本番運用」レベルに仕上げ、_identity_トークンまで絡めると、認証情報を取得するだけでおよそ200行の[コード](https://gist.github.com/haizaar/fcf8ee4b98b2452c618582bca632a338)になってしまうのが難点です。しかも半分はコメント。これは大抵、複雑さの裏返しです。

## もっと良い方法はないのか?

App Engineの潜在的なセキュリティ懸念を除けば、どこでも動く解決策は手に入りました。しかし、以前のシンプルな`google.auth.default()`呼び出しと比べると、なんとも込み入った印象は否めません。別の道はないのでしょうか?

人によってはこちらの方がシンプルに感じられるかもしれない、ひとつの提案があります。少なくとも、なりすましにまつわるApp Engineのセキュリティ懸念には対処できます。手順は次のとおりです。

-   なりすまし対象のサービスアカウントについて、キーファイルを作成します。そう、あの昔ながらの「不格好な」キーファイルです。
-   [Mozilla sops](https://github.com/mozilla/sops) + GCP KMSでファイルを暗号化し、コードと一緒に保管します。
-   サービスアカウントキーファイルの暗号化に使ったGCP KMSキーに対して、運用用サービスアカウントにdecryptorロールを付与します。

ブートストラップコードはこのようになります。

得られた`creds`オブジェクトには便利な`with_scopes()`と`with_subject()`というメソッドが用意されており、スコープやサブジェクトを差し替えた新しい認証情報オブジェクトを返してくれます。

セットアップの手間は確かに増えます(Cloud Functionsやコンテナイメージに30MiBほどの`sops`バイナリを組み込む必要もあります)。とはいえ、フローが格段に追いやすいのが大きな利点です(先ほどのアプローチとは対照的です)。

この方法はApp Engineの問題も解決してくれます——確かに、App Engineのデフォルトサービスアカウントはすべてのキーファイルを復号できる可能性こそ残るものの、別々のgitリポジトリからデプロイされたGAEサービス同士は、互いに暗号化されたサービスアカウントキーファイルにアクセスできません。つまり、シークレットの分離が実現できるのです!

#### 認証のトレーサビリティ

ここからはおまけのパートです——ここまで読んでくださってありがとうございます。

不格好なサービスアカウントキーファイルに対して、なりすましには嬉しい副次的な利点があります。サービスアカウントへのなりすましを行った元のプリンシパルを追跡できる、という点です。

監査のチートシートはこちらです。

-   IAMサービスのデータアクセス監査ログを[有効化](https://cloud.google.com/iam/docs/audit-logging#enabling_audit_logging)する
-   なりすましを実行する。例: `gcloud --impersonate-service-account=<email> projects list`
-   [Logs Explorer](https://console.cloud.google.com/logs)を開き、「Resource」ドロップダウンから「Service Account」を、「Log name」ドロップダウンから「data\_access」を選択する

あるいは、次のクエリを直接入力してもかまいません。