IAM OIDC Identity Provider の作成時、GitHub, Auth0 など一部の IdP で thumbprint の指定が(実質)不要になりました

記事タイトルとURLをコピーする

こんにちは。社内 SE の橋本です。

みなさんは GitHub Actions 使ってますか?便利ですよね。

今回は GitHub Actions で AWS との連携を行う場合の話をします。OIDC Identity Provider の設定がちょっと楽になりました。

参照元記事

こちらです。

github.blog

この記事は GitHub Actions に関するリリースなので GitHub Actions に特化した内容となっていますが、当該記事の中でリンクされている AWS Document(下記)を見る限りでは Auth0 や Google など他の一部 IdP でも共通するアップデートのようです。

docs.aws.amazon.com

"note" セクションに以下のように記載があります。

AWS secures communication with some OIDC identity providers (IdPs) through our library of trusted root certificate authorities (CAs) instead of using a certificate thumbprint to verify your IdP server certificate. These OIDC IdPs include Auth0, GitHub, Google, and those that use an Amazon S3 bucket to host a JSON Web Key Set (JWKS) endpoint. In these cases, your legacy thumbprint remains in your configuration, but is no longer used for validation.

概要

2023/08 現在、GitHub Actions で AWS API をリクエストするような処理を行いたい場合は aws-actions/configure-aws-credentials を利用できます。これを使うことで GitHub 側で AWS の資格情報 (AccessKey 等) を保持せずに認証ができます。

GitHub Actions と AWS を連携させるにあたって、AWS 側で事前に用意すべきリソースがあります。CloudFormation で言うところの AWS::IAM::OIDCProvider リソースがそれで、このリソースには

  • Url
  • ClientIdList
  • ThumbprintList

これら3つのプロパティに有効値を指定する必要がありました。

どういった値を指定すべきなのかは以下の関連記事をご覧ください;

blog.serverworks.co.jp

今回紹介するアップデートは、GitHub Actions を利用したいケースでは ThumbprintList に有効値を入れる必要がなくなる、というものです。これまでのように GitHub Actions 側の証明書の thumbprint を確認して入力する必要はなくなります。これまでは GitHub 側の証明書が更新されればユーザー側で ThumbprintList を都度更新する必要がありましたので、このアップデートは GitHub Actions & AWS ユーザーの保守タスクを減らすものになります。

既存ユーザーには影響がありません。前述した参考記事のように ThumbprintList を指定して AWS::IAM::OIDCProvider を作成した AWS ユーザーもこれまで通りに GitHub Actions を使い続けることができます。

今後はどうすればいいの?

あれこれ説明するより検証用のソースコード貼った方が早いと思うのでそちらをご確認ください。AWS CDK ver 2.92.0 を用いて記述されています。

github.com/hassaku63/aws-github-oidc-no-use-thumbprint-test

github.com

このレポジトリは AWS CDK (TypeScript) で構成されていますが、AWS::IAM::OIDCProvider リソースの定義には L1 Construct である CfnOIDCProvider を使っています。 L1 Construct は CloudFormation のプロパティと 1:1 対応するように作られているものなので、CloudFormation ユーザーの方にもなんとなく要領は把握できる内容になっている(はず)です。

また、このレポジトリは GitHub Actinos の定義を内包しており、その Action の中で AWS CLI を実行しています。AWS::IAM::OIDCProvider を作成しているのが以下の箇所で、 thumbprintList プロパティがダミー値になっています。

github.com

const gitHubIdProvider = new iam.CfnOIDCProvider(this, 'OIDCProviderGithub', {
  url: 'https://token.actions.githubusercontent.com',
  clientIdList: [
    'sts.amazonaws.com',
  ],
  // dummy value (work well)
  thumbprintList: ['0123456789012345678901234567890123456789'],
});

これまでは GitHub がアナウンスしている値(一例はこちら)を使うか、あるいは自前で GitHub Actions のサーバールート証明書および中間証明書の thumbprint を計算する必要がありました(どちらの方法でも結果に違いはありません)。今後はルート証明書の検証を AWS 側でやってくれるようになるのでユーザー側で有効な thumbprint を指定する必要がなくなります。

ただ、CloudFormation や API の仕様としては今回のアップデートを反映する変更は入っていないようです。この記事の寄稿時点では ThumbprintList プロパティは Required と記載されており、かつブランクな値を許容しない仕様になっています。

AWS::IAM::OIDCProvider - AWS CloudFormation

AWS API の仕様は以下です。こちらもThumbprintList の値は指定必須のようです。

CreateOpenIDConnectProvider - AWS Identity and Access Management

CloudFormation ベースの IaC あるいは API を使って AWS::IAM::OIDCProvider リソースを作成する場合は ThumbprintList に適当な40桁のダミー値を入れておく必要があります。 2023/08 現時点の仕様では、1つ以上の Thumbprint 値を指定しないと validation error になってしまい、リソース作成自体ができませんのでご注意ください。ダミー値を入れておく必要があります。 今回のアップデートの内容からするとブランク値を許容できる仕様になっている方がありがたいように感じますが、それは API の仕様を変えてしまう内容なのでそのへんは慎重なのでしょう(たぶん)。

記事のタイトルで「(実質)不要になりました」と書いているのはこういう事情です。ThumbprintList の指定は引き続き必要なんだけど、意味のある値を入れる必要はなくなりましたというのが今回のお話です。

さいごに

地味ながらも、こうしたユーザーの負担を減らすようなアップデートが入るのはありがたいですね。

この件は以前からウォッチしていた CDK の issue コメントから把握したんですが、AWS Blog でこのアップデートに触れているリリース情報は見つけられませんでした。知ってたらどなたか教えていただけると嬉しいです。

最後に、CDK の L2 Construct の話を補足します。CDK には AWS::IAM::OIDCProvider の L2 相当である OpenIdConnectProvider クラスがあります。このクラスを利用する場合でもほぼここでご紹介した内容と同じことが言えるはずです。

docs.aws.amazon.com

thumbprints プロパティが任意指定となっていますが、ここにダミー値を指定する必要があります。

無指定でもOKですが、その場合の cdk synth は実際に GitHub Actions の証明書から thumbprint を計算して CloudFormation プロパティに埋めるような挙動になります。

しかし、2.92.0 の時点でこのリソースはカスタムリソースで構成されていてネイティブの CloudFormation リソースを利用しない実装なので、今回の (GitHub Actions 向けの) ユースケースなら個人的には無理に L2 を使う必要もないかなと考えています。L1 と比べたときに見えてる字面がさほど変わらず楽できてる感が薄いので、それならカスタムリソースを用いる L2 の方をわざわざ採用するメリットもないかな、という所感です。

橋本 拓弥(記事一覧)

プロセスエンジニアリング部

業務改善ネタ多め & 開発寄りなコーポレートエンジニアです。普段は Serverless Framework, Python, Salesforce あたりと遊んでいます