こんにちは、先日会話の流れで出てきた単語に反応して娘が「哺乳類ってなに？」と聞いてきたので「お母さんのお腹から産まれてきた赤ちゃんをお乳で育てる生き物のことだよ」と教えたら「じゃあ私も哺乳類だね！」と言ってきたのでいろいろなことをちゃんと理解できるようになってきたなと感心した木村です。
GitHub Actionsで秘匿情報を取り扱うときは基本的にはGitHubのシークレットを使いますが、今回は1passwordのService Accountsという機能を使ってみたので紹介します。
1password Service Accountsとは
1password Service Accountsは、個人のアカウントとは独立して1passwordの保管庫にアクセスできる機能です。これを使うことでアプリケーションや自動化手順の中から保管庫に安全にアクセスすることができます。
GitHub Actionsで試してみる
今回は自動化の例として、GitHub Actionsから使ってみます。SORACOMのAPIへアクセスするauth_keyとauth_keyidを管理し、私の作成したアクションであるaction-soracom-upload-soraretを動かしてみます。
Actionsを動かすサンプルのリポジトリとしてsoracom-orbit-assemblyscript-with-githubを使います。作業は1password-integrationブランチで行いました。
以下の公式ドキュメントに従って作業を勧めていきます。
1passwordの設定
まず1password側の設定を行います。今回は1password cliを使って作業していますが、Web画面からも操作可能です。cliのバージョンは2.18.0以降が必要です。cliのセットアップやサインインについてはここでは省略します。
Service AccountはデフォルトのPrivateといったVault(保管庫)にはアクセスできないので、最初に専用の新しいVaultを作ります。
$ op vault create Soracom
このVaultを読み込む権限を持ったService Accountを作ります。ひとまず期限は30日にしておきます。
$ op service-account create soracomApiKey --expires-in 30d --vault Soracom:read_items
ここでService Accoutのトークンが表示されます。トークンはここでしか表示できないので、1passwordに保存しておきましょう。
作成したVaultの中にsoracomApiKeyという名前のアイテムを作り、AUTH_KEYとAUTH_KEY_IDというフィールドを作ります。これにSORACOM APIにアクセスするauth_keyとauth_key_idを保存します。
ワークフローの修正
次に、ワークフロー内でシークレットにアクセスしている部分を、このVaultにアクセスするように変更します。公式ドキュメントに従って進めていきます。
まず、リポジトリのシークレットに、Service AccountのトークンをOP_SERVICE_ACCOUNT_TOKENという名前で登録します。
次に、GitHub Actionsのワークフローを修正します。修正後のファイルはこちらです。
actions/load-secrets-from-1passwordを使って、Service Accountsのトークンを使ってauth_keyとauth_keyidを取得し、それを利用するようにします。該当部分は以下のとおりです。
... - name: Load secrets from 1password id: op-load-secret uses: 1password/load-secrets-action@v1 with: export-env: false env: OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }} AUTH_KEY_ID: op://Soracom/soracomApiKey/AUTH_KEY_ID AUTH_KEY: op://Soracom/soracomApiKey/AUTH_KEY - name: upload uses: kenichiro-kimura/action-soracom-upload-soralet@1.2.1 id: upload with: soracom_auth_key: ${{ steps.op-load-secret.outputs.AUTH_KEY }} soracom_auth_key_id: ${{ steps.op-load-secret.outputs.AUTH_KEY_ID}} ...
id: op-load-secretというステップで取得し、その出力の${{ steps.op-load-secret.outputs.AUTH_KEY }}ならびに${{ steps.op-load-secret.outputs.AUTH_KEY_ID}}でアクセスします。
出力の名前と参照先のシークレットをenv:で指定しています。参照先のシークレットはop://vault-name/item-name/[section-name/]field-nameという形式で指定します。今回は登録時にセクションは使っていないので、section-nameは省略しています。
更新したら、このアクションを実行してみます。
Load secrets from 1passwordステップで取得したシークレットがAUTH_KEYとAUTH_KEY_IDに紐付けられ、次のuploadステップでそのシークレットを用いてSORACOM APIに正常にアクセスできたことが確認できました。
トークンのローテーションと取り消し
Service Accountのトークンのローテーションと取り消し(revoke)は、2024/8/11現在はWeb画面からのみ可能なようです。
Web画面にサインインし、デベロッパーツールから行います。
まとめ
1passwordのService Accountsを使い、GitHub Actionsのシークレットを管理してみました。
1passwordのService Accountsを使うと他の環境とのシークレットの共有が安全に行え、1passwordでの一元管理が可能になります。GitHub EnterpriseではOrganizationシークレットを使うことでOrganization下のリポジトリで共有できますが、1password Service AccountsだとGitHub以外のサービスとの共有やアクセス制限の管理が行えるので便利です。また、GitHubのシークレットでは登録したシークレットの内容を確認することは基本的にできませんが、1passwordであれば1password側で確認ができるのでデバッグ等も容易になります。
今回は動作させるところまでの紹介となりましたが、Azure KeyVaultやAWS Secrets Managerなどの他のシークレット管理サービスを使う場合との比較も行っていけたらと思っています。
皆さんのお役に立てば幸いです。
サービス一覧 www.alterbooth.com cloudpointer.tech www.alterbooth.com
