SecretManagerにアクセスできるサービスアカウントを設定する
はじめに
本記事ではSecret Managerにアクセスするためだけの用途を想定したサービスアカウントを作成します。
この記事は以下の記事の補足的な内容となっており、先にこちらの親記事をご覧頂くと何のための作業かわかりやすいです。
Cloud Functions(Google Cloud)でAWS SDKを実行する - Zenn
なお、AWSのIAMユーザーの作成等についてはこの記事内では記載していないです。
サービスアカウントとは
Google Cloudのサービスアカウントとは、アプリケーションからGoogle Cloudにアクセスする際に用いられるアカウントです。アプリケーションの実行権限は、それに紐づくサービスアカウントの権限によって制限されるため、最小権限の原則に基づき必要な権限のみを付与してアプリケーションが操作可能な範囲を限定しておくことが大事です。
サービスアカウントを準備する手順
手順は主に以下のとおりです。
- Secretの登録
- サービスアカウントの作成
- サービスアカウントがSecretにアクセスできるように紐付ける
順番に見ていきたいと思います。
1. Secretの登録
サービスアカウントを作成する手順は、個人のローカル環境に履歴を残して見返すために、また手順書にメモとして残す意味でもGoogle Cloudのコンソール画面ではなく、CLIツール(gcloud)で作業を行う方が良いのではと個人的に考えています。
しかし、Secretの登録に際しては、あえてコンソール画面から行いました。
Google Cloudのコンソールから、セキュリティ → Secret Managerと進み、Secretの名前と値を設定します。
先の記事の内容に則るなら、sec_aws_access_key_id
、sec_aws_secret_access_key
の2つを設定する必要があります。(画面とは異なるのでご注意下さい。)
なお登録されたSecretは、以下のコマンドで確認することができます
gcloud secrets list
▼ 実行結果の一例
NAME CREATED REPLICATION_POLICY LOCATIONS
sec_aws_access_key_id 2021-09-24T09:01:19 automatic -
sec_aws_secret_access_key 2021-09-24T09:01:48 automatic -
2. サービスアカウントの作成
次に、以下のgcloudコマンドを実行してサービスアカウントを作成します。
USER_SA_OF_SECRET_MANAGER="user-sa-secret-manager"
gcloud iam service-accounts create ${USER_SA_OF_SECRET_MANAGER} \
--description="Service Account for Secret Manager"
ここでサービスアカウントの名前についてですが、あらかじめ命名規則をプロジェクト内で考えておくと良いのではないかと思われます。
サービスアカウントは様々な種類があり、初めのうちは区別しにくいものなので、今回は「ユーザー定義のサービスアカウントである」ことをわかりやすくするために、user-
というprefixを付けました。
サービスアカウントの種類について詳しく知りたい方はこちらの記事もご参照下さい。
3. サービスアカウントがSecretにアクセスできるように紐付ける
以下のようにadd-iam-policy-binding
をする必要があります。ここで、Secretにアクセスする権限secretAccessor
を先のサービスアカウントにバインドするためroleで指定します。
PROJECT_ID="foobar" # 適切なプロジェクトIDを設定しておきます。
gcloud secrets add-iam-policy-binding sec_aws_access_key_id \
--member="serviceAccount:${USER_SA_OF_SECRET_MANAGER}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
gcloud secrets add-iam-policy-binding sec_aws_secret_access_key \
--member="serviceAccount:${USER_SA_OF_SECRET_MANAGER}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
以上で、サービスアカウントの設定は完了です。
Cloud Functionsのデプロイ時にこのサービスアカウントを指定して実行すると、2つのSecretにアクセスすることができます。
おまけ (GitHub Actions用のサービスアカウント)
ここまでで一通りの設定はできましたが、このCloud FunctionsをGitHub Actionsでデプロイしたいと考えた場合には、GitHub Actions用のCloud Functionsのデプロイが可能な権限を持つサービスアカウントも別途必要になります。
まず、GitHub Actions用のサービスアカウントを作ります。
USER_SA_OF_SECRET_MANAGER="user-sa-secret-manager"
gcloud iam service-accounts create ${USER_SA_OF_ACTIONS} \
--description="Service Account for GitHub Actions"
一方で、Cloud Functionsデプロイに必要な権限をまとめたカスタムロールを作成します。
先に必要な権限を記載したYAMLファイルを作成しておきます。このカスタムロールの設定のためのYAMLファイルの記載はこちらが参考になります。
title: Custom_GitHubActions_Role
description: GitHub Actions Role
stage: GA
includedPermissions:
# Cloud Functions
- cloudfunctions.functions.get
- cloudfunctions.functions.sourceCodeSet
- cloudfunctions.functions.update
- cloudfunctions.operations.get
その後、以下のように--file
でファイル名を指定して実行します。
CUSTOM_ROLE_FOR_ACTIONS="custom_role_for_actions"
gcloud iam roles create ${CUSTOM_ROLE_FOR_ACTIONS} \
--project=${PROJECT_ID} \
--file=./policy-of-custom-role-for-actions.yaml
そしてGitHub Actions用のサービスアカウントに上記で作成したロールを紐付けます。
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${USER_SA_OF_ACTIONS}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role="projects/${PROJECT_ID}/roles/${CUSTOM_ROLE_FOR_ACTIONS}"
最後に、Actions用のサービスアカウントが「Secret Managerにアクセスできるサービスアカウント」を「使える」 = roles/iam.serviceAccountUser
ように紐付けます。
(ここが、個人的にはちょっとテクニカルだなと感じています)
gcloud iam service-accounts add-iam-policy-binding \
${USER_SA_OF_SECRET_MANAGER}@${PROJECT_ID}.iam.gserviceaccount.com \
--member="serviceAccount:${USER_SA_OF_ACTIONS}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
このサービスアカウントを利用したGitHub Actionsの設定全般に関する記事はまた後日書きたいと思います。
おわりに
Google Cloudのコンソール上からも本記事と同様の内容はもちろん設定できるのですが、CLIで実行すると上記のような手順になるはずです。
gcloudコマンドに限らずサブコマンドの多いツールを使用する際は、fishなど補完機能の強力なシェル環境に一時的に切り替えると快適に操作できるのでお薦めです。
どなたかに届けば幸いです。
参考文献
Discussion