今更知ったGitHub Actionsからのキーなし認証（OIDC認証）の解説とやり方

これまで、GitHub ActionsからGoogle Cloudへアクセスする場合は、サービスアカウントキーを用いた認証が一般的でした。しかし、この方法には「キーが漏洩すると不正アクセスのリスクが非常に高い」「定期的なキーの管理やローテーションが大変」という課題があります。

最近知ったことなのですが、実はGoogle Cloudではかなり以前からOIDC（OpenID Connect）を利用したキーレス認証が提供されていました。

今更ながら、これまで使ってきたサービスアカウントキーからOIDC認証に切り替えるべく、その仕組みや設定手順を調査し、実際に設定してみましたので、同じようにこれから取り組む方のために詳しく解説していきます。

（👇の画像はChatGPTでこの記事をグラレコっぽくまとめてもらった画像です）

OIDCを利用したキーレス認証とは？

OIDCを利用したキーレス認証とは、簡単に言うと「一時的なトークンを使ってGoogle Cloudへ安全にアクセスする仕組み」です。

サービスアカウントキー方式との違いは？

従来のサービスアカウントキー方式と比べ、OIDC認証のメリットは次のようなものがあります。

セキュリティの向上

サービスアカウントキーは一度漏洩すると長期間悪用される可能性があります。

一方、OIDC認証は短時間のみ有効なトークンを利用するため、万が一漏洩しても影響は限定的です。

管理負担の軽減

サービスアカウントキーのようにキーの生成、保存、定期的なローテーションが不要です。

GitHub Actionsにキーを保存しなくて良いので、秘密情報がGitHub上に存在するリスクがなくなります。

このOIDC認証をGoogle Cloudで実現するための仕組みが、次に説明するWorkload Identity Federationです。

Workload Identity Federationとは？

Workload Identity Federationは、外部サービス（GitHub ActionsやAWSなど）から発行された認証情報をGoogle Cloud上で安全に受け入れるための仕組みです。

具体的には、次の3つの重要な要素があります。

1. Workload Identity プール

Workload Identityプールは、GitHub Actionsのような外部認証サービスから発行されたOIDCトークンをGoogle Cloudが安全に受け入れるための入れ物です。

プールの中には複数のプロバイダを設定でき、Google CloudのIAMが一元的に管理します。

2. Workload Identity プロバイダ

Workload Identityプロバイダは、GitHub Actionsなどの外部サービスが発行したOIDCトークンの信頼性を検証するための身元確認係です。

例えば、GitHub Actionsの場合は以下のような設定をします。

• Issuer（発行元）：https://token.actions.githubusercontent.com
• Audience（対象者）：https://github.com/example-org/my-repo（対象となるGitHubリポジトリのURL）

3. プロバイダの属性（Attributes）

OIDCトークン内には、発行元や発行された条件に関する情報（クレーム）が含まれています。

これらの情報をGoogle Cloudが認証条件として利用するためにマッピングする設定が「プロバイダの属性」です。

例えば、GitHub Actionsでよく使われる属性には以下のようなものがあります。

• リポジトリ名（例：example-org/my-repo）
• ブランチ名（例：refs/heads/main）
• 実行ユーザー名（例：github-username）

プロバイダ設定時にこれらのクレームをGoogle Cloud側の属性として次のようにマッピングします。

google.subject: assertion.sub
attribute.actor: assertion.actor
attribute.repository: assertion.repository

実際にGitHub ActionsでキーなしのOIDC認証を設定する手順

では実際に、Google CloudとGitHub ActionsでキーなしのOIDC認証を設定する手順を解説していきます。

1. Google Cloud側の設定（GUI操作）

まずGoogle Cloudコンソールにログインし、「Workload Identityプール」を作成します。

IAMと管理 > Workload Identity プール から「プールを作成」を押します。

ID プールを作成する入力フォームが表示されるので値を入力します。

プールの名前には用途が分かりやすい名前（例：github-actions-pool）を設定します。

次に、作成したプール内に新しいプロバイダを追加します。

プロバイダは「OpenID Connect (OIDC)」を選択します。その後、各項目は下記のように入力します。

最後にプロバイダの属性のマッピング値を設定します。

下記のように設定すると良いです。

属性条件には assertion.repository_owner == '[Organization名]' を指定することで、この Workload Identity が使えるのは特定の GitHub Organization に限定されるようにしています。

assertion.repository_owner == "<GitHub の Organization 名>"

2. サービスアカウントとの紐づけ

作成したWorkload Identity のプールとサービスアカウントを紐づけます。予めサービスアカウントを作成しておいてください。

作成したプールの詳細からアクセスを許可をクリックし、そこから該当のサービスアカウントを指定し紐付けることができます。

プリンシパルは属性名を repository 、属性値としてGitHub Organization とリポジトリ名を <Organization>/<Repository> の形式で入力します。

これで設定が完了です！

最後に下記のようなGithub Actionsの設定を実行してみて問題ないかを確認します。

name: Deploy to Google Cloud

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: "Authenticate to Google Cloud"
        uses: "google-github-actions/auth@v2"
        with:
          workload_identity_provider: "principal://iam.googleapis.com/projects/<Worklord Identityのプロジェクト番号>/locations/global/workloadIdentityPools/<Worklord IdentityプールID>"
          service_account: "<サービスアカウント名>@<プロジェクトID>.iam.gserviceaccount.com"

      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2

まとめ

OIDC認証を導入することで、サービスアカウントキーのように長期間有効な認証情報が漏洩するリスクを回避できるだけでなく、キー管理の負担も軽減できます。

Workload Identity Federationを理解することで、安全かつ効率的なクラウド運用が可能になります。

まだサービスアカウントキーを使っている方は、ぜひこの機会にOIDCを利用したキーなし認証への移行を検討してみてはいかがでしょうか。