# 今更知ったGitHub Actionsからのキーなし認証（OIDC認証）の解説とやり方 > GitHub ActionsからGoogle Cloudへ安全にアクセスするためのOIDC認証について、その仕組みや設定手順を詳しく解説しています。従来のサービスアカウントキー方式に代わるキーレス認証のメリットやWorkload Identity Federationの要素についても説明しています。 - 公開日: 2025-03-28 - 更新日: 2025-03-28 - 著者: やました - タグ: GCP, CI/CD, Github Actions - URL: https://tech.anycloud.co.jp/articles/github-actions-oidc --- これまで、GitHub ActionsからGoogle Cloudへアクセスする場合は、サービスアカウントキーを用いた認証が一般的でした。しかし、この方法には「**キーが漏洩すると不正アクセスのリスクが非常に高い**」「**定期的なキーの管理やローテーションが大変**」という課題があります。最近知ったことなのですが、実はGoogle Cloudではかなり以前から**OIDC（OpenID Connect）を利用したキーレス認証**が提供されていました。

GitHub Actions からのキーなしの認証の有効化 | Google Cloud 公式ブログWorkload Identity 連携を使用して Google Cloud リソースを作成および管理するために、GitHub Actions から認証を行います。

今更ながら、これまで使ってきたサービスアカウントキーから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側の属性として次のようにマッピングします。 ```plaintext 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)」を選択します。その後、各項目は下記のように入力します。

項目	入力内容
プロバイダの選択	OpenID Connect（OIDC）
プロバイダ名	管理用の任意の名前です。例えば、`github-provider` や `gha-prod-provider` など、わかりやすい名前にしておくと後で便利です。
発行元（URL）	OIDCトークンを発行するサービスのURL（Issuer）を入力します。 Github Actionsの場合は `https://token.actions.githubusercontent.com` を設定
JWKファイル（JSON）	通常は入力不要です。JWK（JSON Web Key）ファイルは、OIDCの発行者が公開鍵を公開していない特殊な場合にのみ必要です。 GitHub Actionsのような一般的なサービスでは自動的に取得されるため、ここは空欄で問題ありません。

最後にプロバイダの属性のマッピング値を設定します。下記のように設定すると良いです。

Google Cloud側の属性	OIDCトークンのクレーム（入力値）	解説
`google.subject`	`assertion.sub`	トークンの主体（GitHub Actionsでの実行者情報など）をGoogle Cloudの内部的なIDとして使用。必須。
`attribute.aud`	`assertion.aud`	トークンが意図する受信者。OIDCトークンの `aud` フィールドを使用します。
`attribute.actor`	`assertion.actor`	GitHub Actionsを実行したユーザー名。
`attribute.repository`	`assertion.repository`	トークンが発行された GitHub リポジトリ名（例：`example-org/my-repo`）。

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

### 2\. サービスアカウントとの紐づけ作成したWorkload Identity のプールとサービスアカウントを紐づけます。予めサービスアカウントを作成しておいてください。作成したプールの詳細からアクセスを許可をクリックし、そこから該当のサービスアカウントを指定し紐付けることができます。プリンシパルは属性名を `repository` 、属性値としてGitHub Organization とリポジトリ名を `/` の形式で入力します。

これで設定が完了です！最後に下記のようなGithub Actionsの設定を実行してみて問題ないかを確認します。 ```yaml 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//locations/global/workloadIdentityPools/" service_account: "<サービスアカウント名>@<プロジェクトID>.iam.gserviceaccount.com" - name: Set up Cloud SDK uses: google-github-actions/setup-gcloud@v2 ``` ## まとめ OIDC認証を導入することで、サービスアカウントキーのように長期間有効な認証情報が漏洩するリスクを回避できるだけでなく、キー管理の負担も軽減できます。 Workload Identity Federationを理解することで、安全かつ効率的なクラウド運用が可能になります。まだサービスアカウントキーを使っている方は、ぜひこの機会にOIDCを利用したキーなし認証への移行を検討してみてはいかがでしょうか。