IAM サービス アカウントでの Cloud SQL for PostgreSQL に対する認証
Google Cloud Japan Team
※この投稿は米国時間 2021 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。
2020 年 10 月、Google は Cloud SQL for PostgreSQL に対する IAM 認証のプレビューを開始すると発表しました。今回のブログ投稿は、プレビューの実行に必要な手順である ELI5 プロシージャの概要を紹介することを目的としています。
IAM 認証用に Cloud SQL を構成する
割り当てられたサービス アカウントの認証情報を使用して、指定されたデータベースに接続できるようユーザー エージェントを構成する
注: 個別に割り当てられたアカウントにも同じ手順が使えますが、サービス アカウントの有効化や権限借用の手順は省いてください。
Cloud SQL の IAM 認証を導入するには、主に次の 3 つの手順を行います。
IAM を構成する
SQL インスタンスを構成する
そのインスタンスで SQL Database に接続する
本投稿は Google Cloud IAM について詳細情報まで細かく説明することを目的としておらず、アカウントが Cloud SQL データベースに適切に認証されるために必要な項目に絞って説明しています。必要に応じて、こちらをご覧ください。アカウントはユーザー アカウントでも（推奨）サービス アカウントでもかまいません。
ただし、少なくともそのアカウントに、対象となる DB インスタンスに対する権限がなくてはなりません。
サービス アカウントの場合、ユーザーがそのサービス アカウントを使ってデータベースに接続できるようにするには、そのユーザー アカウントにサービス アカウントに代わって OAUTH2 トークンを生成する権限が付与されている必要があります。これで、そのアカウントでデータベースを呼び出す場合、そのサービス アカウントでの権限借用が可能になります。
呼び出しアカウントの権限 - 既存のユーザー アカウントまたは（推奨）サービス アカウントに以下の最小限の権限を追加する必要があります。次のロールか、あるいはこうした権限をまとめたカスタムロールを使用できます。
管理用ユーザー アカウント権限 - OAUTH2 トークンの権限借用（ユーザー アカウントでサービス アカウントとしてサービスを呼び出す場合に必要です）:
IAM 認証用に Cloud SQL を構成する
構成フラグを指定して IAM 認証を有効にする - IAM 認証はアカウントを追加しただけでは使用できません。フラグを有効にする必要があります。既存のインスタンスの場合は以下の Cloud UI と GCloud の各項目をご覧ください。
今後 IAM 認証を有効にしたいインスタンスにこちらを追加する必要があります。
また、上述のリンク先ガイドから、メールアドレスで指定してアカウント用の SQL ユーザーを作成します。
（サービス アカウントのメールアドレスは、sa-name@projectid.iam の形式にし、接尾辞「.gserviceaccount.com」を省いたものにしなければ、エラーになります）
構成を完了するには、IAM SQL ユーザーにデータベースへの権限を付与する必要があります。まず、デフォルトの postgres ユーザーか、ローカルで作成したアカウントで接続し、権限の作成を有効にします。psql コマンドは次のようになります。
*注: IAM アカウントを昇格させてからローカル アカウントの権限を取り消すという方法もありますが、IAM 認証の障害を回避しなければならない場合に備え、フェイルセーフ用アクセスとして、少なくともパスワードが保管された 1 つのローカル cloudsqlsuperuser アカウントを保持する必要があるので、この方法はおすすめしません。
GCP クラウド リソースに接続するには 2 つの認証が必要です。
IAM ユーザー アカウント（または SA） - クラウド用の「バッジ」です
psql ユーザー アカウント - インスタンス用の「バッジ」です
要件: GCloud SDK - 呼び出し側のサーバーやワークステーションのリソースから gcloud SDK にアクセスできる必要があります。以下では、GCloud SDK が起動しており、ユーザー アカウントが認証された状態であることを想定しています。
IAM ユーザー アカウントに直接アクセスできるようになっている場合は、後述の SA 鍵管理のパートを省略できます。
以下では、ユーザー アカウントにデータベースのインスタンスに接続されているSA の権限を借用する権限があると想定しています。
現行の OAUTH2 アクセス トークンでは、次のコマンドにより、サービス アカウントに代わってアクセスできます。
このトークンの有効期限は 60 分です。
注: ユーザーに（サービス アカウント トークン作成ロールとは異なる iam.serviceAccounts.actAs 権限を許可する）サービス アカウント ユーザー権限がある場合、管理者は SA アクセスキー（機密）をダウンロードし、サービス アカウントとして GCloud Auth セッションを直接有効にするという、別の方法を取ることができます。この場合、どちらの方法であっても OAUTH2 トークンを生成できます。ダウンロードした SA JSON キーを使う自動化にはメリットがあるかもしれませんが、こうしたキーはサービス用のキーですので、細心の注意を払って安全に取り扱う必要があります。
psql: データベースへの接続に使用できるツールにはありとあらゆる種類がありますので、ここにすべてを記載することはしません。基本的には、次の方法で接続文字列を作成するのが一番簡単です。
ホスト名: ホスト名または IP アドレス
ユーザー名: SA メールアドレス
パスワード: OAUTH2 トークン
トークンを動的に回転させてパスワードとして入力するのがコツです
postgres については、投稿者の場合 ~/.pgpass ファイルに適切なアクセス認証情報を入力することで構成できました。
このファイルはフラット ファイルで、書式なしテキスト形式になっています。
ファイル構成要件（アクセス許可、環境変数など）には注意が必要です。接続構成は警告もなく無視されます。
pgAdmin - 認証情報をパスワード構成フィールドに貼り付けることで対処しました。もちろん、ほとんどの psql 管理ツールは psql の枠組みを拡張して pgpass ファイルのユーザーをサポートしています（pgAdmin もパスワード ファイルをサポートします）。接続前に行う認証作成やパスワード ファイル更新の操作にはあまり時間がかからないので、この手順の操作は非常に透明性があります。
最終的な接続のワークフロー:
チームが適切にデータベースを構成し終えデータにアクセスできるようになると、それぞれのデータベースに対し独自の IAM サービス アカウントの関連付けを行い、各ユーザー アカウントに任意のサービス アカウントの権限借用のための権限を付与できます。
管理者がデータベースへの接続を希望する場合、それぞれの接続ワークフローは次のように至ってシンプルになります（また、DB インスタンスと SA ID をペアにした Key-Value のリストがあれば、以下のようなスクリプトできわめてスムーズに処理できます）。
IAM SA「メール」アドレスを検索する
例: sa-name@project-id.iam.gserviceaccount.com
GCloud SDK: セッションを確立し SA 用に OAUTH トークンを獲得する: [gcloud auth print-access-token --impersonate-service-account sa-name@project-id.iam.gserviceaccount.com]
環境変数として保存するか、ローカルのパスワード ファイルを更新する
接続する
これで IAM で認証される Cloud SQL データベースをお使いいただけます。
