OpenID Connect

OpenID Connect (OIDC) の概要

          GitHub Actions ワークフローは、多くの場合、ソフトウェアをデプロイしたり、クラウドのサービスを使用したりするために、クラウド プロバイダー (AWS、Azure、GCP、HashiCorp Vault など) にアクセスするように設計されています。 ワークフローは、このようなリソースにアクセスできるように、パスワードやトークンなどの資格情報をクラウド プロバイダーに事前に提供します。 通常、これらの資格情報はシークレットとして GitHubに格納され、ワークフローは実行されるたびにこのシークレットをクラウド プロバイダーに提示します。

ただし、ハードコーディングされたシークレットを使用するには、クラウドプロバイダーで資格情報を作成し、シークレットとして GitHub で複製する必要があります。

OIDC をサポートするクラウドプロバイダーとの信頼できる接続を確立した後に、有効期間の短いアクセストークンをクラウドプロバイダーに直接要求するようワークフローを構成できます。

OIDC を使う利点

OIDC トークンを使うようにワークフローを更新することで、次のような優れたセキュリティプラクティスを採用できます。

        **クラウド シークレットなし:** 有効期間が長い GitHub シークレットであれば、クラウド資格情報を複製する必要はありません。 代わりに、クラウド プロバイダー上で OIDC 信頼を構成し、OIDC を介して有効期間が短いアクセス トークンをクラウド プロバイダーに要求するようにワークフローを更新することができます。

        **認証と認可の管理:** クラウド プロバイダーの認証 (authN) および認可 (authZ) ツールを使ってクラウド リソースへのアクセスを制御することで、ワークフローから資格情報を使用する方法をより細かく制御できます。

        **資格情報のローテーション:** OIDC を使う場合、1 つのジョブに対してのみ有効であり、自動的に失効する有効期間が短いアクセス トークンがクラウド プロバイダーから発行されます。

OIDC と統合する方法 GitHub Actions

次の図は、 GitHubの OIDC プロバイダーがワークフローおよびクラウドプロバイダーと統合する方法の概要を示しています。

クラウドプロバイダーがアクセストークンと JSON Web トークンクラウドロール ID を介して GitHub Actions と統合する方法の図。

クラウドプロバイダーで OIDC の信頼関係を確立し、定義されたクラウドロールに代わって特定の GitHub ワークフローがクラウドアクセストークンを要求できるようにします。
ジョブが実行されるたびに、 GitHubの OIDC プロバイダーによって OIDC トークンが自動生成されます。このトークンには、認証対象の特定のワークフローに関する、セキュリティが強化された検証可能な ID を確立するための複数の要求が含まれています。
ワークフロージョブのステップまたはアクションは、 GitHubの OIDC プロバイダーにトークンを要求できます。これにより、ワークフローの ID の証明としてクラウドプロバイダーに提示できます。
クラウドプロバイダーは、トークンで提示した要求の検証を完了した後に、ジョブの期間中にのみ使用できる有効期間の短いクラウドアクセストークンを提供します。

各ジョブは、 GitHubの OIDC プロバイダーから OIDC トークンを要求します。これは、生成されるワークフロージョブごとに一意の自動的に生成された JSON Web トークン (JWT) で応答します。このジョブを実行すると、OIDC トークンがクラウドプロバイダーに提示されます。クラウドプロバイダーは、トークンを検証するために、OIDC トークンの subject とその他の要求がクラウドロールの OIDC 信頼定義に事前に構成されている条件と一致するかどうかを確認します。

次の OIDC トークン例では、sub リポジトリ内の prod というジョブ環境を参照する subject (octo-org/octo-repo) を使っています。

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "example-thumbprint",
  "kid": "example-key-id"
}
{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "environment": "prod",
  "aud": "https://HOSTNAME/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_visibility": "private",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "runner_environment": "github-hosted",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",
  "enterprise": "avocado-corp",
  "enterprise_id": "2",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://HOSTNAME/_services/token",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

OIDC を使用するカスタムアクションの認証

カスタムアクションは、Actions ツールキットの getIDToken() メソッド、または curl コマンドを使用して、OIDC を使用した認証を行います。

詳しくは、「OpenID Connect リファレンス」をご覧ください。

OIDC 向けのワークフローの更新

          GitHub Actions ワークフローでは、シークレットの代わりに OIDC トークンを使用して、クラウド プロバイダーに対する認証を行うことができます。 多くの一般的なクラウド プロバイダーは、ワークフローで OIDC を使用するプロセスを簡略化する公式ログイン アクションを提供しています。 特定のクラウド プロバイダーに関してワークフローを更新する方法の詳細については、「[AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments)」を参照してください。

          Dependabot に対する OIDC のサポート

          Dependabot OIDC を使用してプライベート レジストリで認証できるため、有効期間の長い資格情報をリポジトリ シークレットとして格納する必要がなくなります。 OIDC ベースの認証では、 Dependabot 更新ジョブは、クラウド ID プロバイダーから有効期間の短い資格情報を動的に取得できます。

          Dependabot は、AWS CodeArtifact、Azure DevOps Artifacts、または JFrog Artifactory でレジストリがホストされている場合に、 `username` および `password` 認証を使用する任意のレジストリの種類に対する OIDC 認証をサポートします。

          Dependabotの OIDC 認証の利点は次のとおりです。

* セキュリティ強化: リポジトリから、有効期間の長い静的な資格情報を削除します。 * 管理が簡単: プライベートレジストリへのセキュリティで保護されたポリシー準拠のアクセスを有効にします。 * レート制限を回避する: 動的な資格情報は、静的トークンに関連付けられているレート制限に達しないようにするのに役立ちます。

詳しくは、「Dependabot のプライベートレジストリへのアクセスの構成」をご覧ください。

次のステップ

OIDC の構成について詳しくは、「デプロイメントのセキュリティ強化」を参照してください。

OIDC のリファレンス情報については、「OpenID Connect リファレンス」を参照してください。

この記事で