CIにおけるOIDCとは何か?

OIDCを使うと、CIのjobがクラウドプロバイダーに自身の身元を証明し、短命なtokenを取得できます - つまり、長命なクラウド認証情報をsecretとして保存する必要が一切ありません。

OpenID Connect(OIDC)は、OAuth 2.0の上に構築されたアイデンティティ層です。CIでは、保存されたクラウドキーを信頼関係に置き換えます: CIプラットフォームがjobを記述した署名付きtokenを発行し、クラウドプロバイダーがそのtokenを一時的な認証情報と交換します。

保存されたキーの問題

CIのsecret内にある長命なクラウドアクセスキーはリスクです: めったにローテーションされず、常時アクセスを付与し、漏洩すれば誰かが気づくまでアカウントを危険にさらします。OIDCはこれらを完全に取り除きます。

交換の仕組み

• CIプラットフォームが、job(repo、branch、workflow)を記述した署名付きのJWTアイデンティティtokenを発行します。
• クラウドプロバイダーが署名を検証し、claimを信頼ポリシーと照合します。
• 一致すれば、プロバイダーはroleにスコープされた短命な認証情報を返します。

小さな例

GitHub Actionsでは permissions: id-token: write を設定し、role ARNを指定してクラウドログインactionを使います。actionはOIDC tokenを取得し、AWS STSと交換して一時的な認証情報を得ます - どこにも ${{ secrets.AWS_ACCESS_KEY_ID }} はありません。

なぜより安全なのか

tokenはjobごとに発行され数分で失効するため、盗まれる常時のものが存在しません。信頼ポリシーは、どのリポジトリとbranchがどのroleを引き受けられるかを正確に固定するため、forkや別のリポジトリは引き受けられません。

信頼条件を固定する

セキュリティは信頼ポリシーに依存します。それを正確なリポジトリ、そして理想的にはbranchやenvironmentにスコープしてください。緩い条件(組織内のどのrepoでも)は、無関係なworkflowにあなたのroleを引き受けさせてしまいます。

重要なポイント

• OIDCは、保存されたクラウドキーを、job単位の短命なtokenに置き換えます。
• クラウドプロバイダーは署名付きのclaimを検証し、一時的な認証情報を返します。
• 信頼ポリシーが、どのリポジトリとbranchがどのroleを引き受けられるかを固定します。

関連ガイド