こんにちは。技術課の山本です。
IAM Roles Anywhere の認証方式を理解するために、一通り触ってみて、概要を整理してみました。
具体的な手順等は別の記事に記載予定です。

⏩書きました。 Private CA 篇：

OpenSSL 篇：

IAM Roles Anywhere の利用目的
IAM Roles Anywhere が利用可能になる前の認証方式
- １． IAM ユーザーを発行し、長期的な AWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行する
- ２． AWS Security Token Service (AWS STS) を使用し短期的なAWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行する
IAM Roles Anywhere の認証方式
- １．AWS ACM の Private CA を認証局として使用する方式
まとめ
リンク集
追記
余談

IAM Roles Anywhere の利用目的

まずは、IAM Roles Anywhere の利用目的について、考えてみます。
AWS のニュースブログ（※１）には以下の利点が挙がっています。
※１IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する | Amazon Web Services ブログ

１箇所目：

IAM Roles Anywhere を利用することで、オンプレミスのサーバー、コンテナ、またはアプリケーションが一時的な AWS クレデンシャルを取得するセキュアな方法を提供し、長い有効期間の AWS クレデンシャルを作成・管理する必要性を無くすことができます。

２箇所目：

IAM Roles Anywhere は、AWS 上のワークロードが IAM ロールを使用するのと同じ方法で、AWS 外部にあるアプリケーションが IAM ロールを使用して AWS API にセキュアにアクセスできるようにします。IAM Roles Anywhere により、短い有効期間のクレデンシャルを、オンプレミスのサーバー、コンテナ、または他のコンピューティングプラットフォームに対して提供できます。IAM Roles Anywhere を使用して短い有効期間のクレデンシャルを払い出すと、長い有効期間の AWS アクセスキーとシークレットを利用する必要がなくなり、セキュリティが向上し、長い有効期間のクレデンシャルを管理およびローテーションする運用オーバーヘッドが無くなります。さらに IAM Roles Anywhere を使用して、ハイブリッドワークロード間でクレデンシャル管理のための一貫したエクスペリエンスを備えることができます。

すなわち、以下の２点と読めます。

AWSではない環境（オンプレミスなど）のサーバー・コンテナ・アプリケーションが、一時的な AWS クレデンシャルを取得するセキュアな方法を提供する。それにより、長い有効期間の AWS クレデンシャルを作成・管理する必要性を無くす。
AWSではない環境（オンプレミスなど）と、AWS環境を組み合わせて使用しているシステムが複数ある時に、AWS クレデンシャルを管理する一貫した仕組みを提供する。

IAM Roles Anywhere が利用可能になる前の認証方式

まずは、IAM Roles Anywhere が利用可能になる前には、どのような方式があったのか、確認してみましょう。

１． IAM ユーザーを発行し、長期的な AWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行する

「長い有効期間の AWS クレデンシャルを作成・管理する必要性」と、ニュースブログに書いているのは、本方式のことと推察します。

アクセスキーは、IAM ユーザーまたは AWS アカウントルートユーザーの長期的な認証情報です。

引用元：IAM ユーザーのアクセスキーの管理 - AWS Identity and Access Management

AWS クレデンシャルの発行と使用は、以下の流れになります。例としまして、オンプレミスのサーバーから S3 バケットにファイルをアップロードします。

IAM ユーザーを作成し、長期的な AWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行
AWS の API を実行する各種ツールを使い、AWS に API を発行する。その際に、１で発行したアクセスキー・シークレットアクセスキーを使用。

また、本方式では課題として以下が挙がります。

アクセスキー・シークレットアクセスキーは長期的に使えるものとなる。期限等は設定できない。
AWS 上で発行した、アクセスキーとシークレットアクセスキーをオンプレミスのサーバーに登録するために、情報の受け渡しが必要

２． AWS Security Token Service (AWS STS) を使用し短期的なAWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行する

IAM ユーザーを発行し、IAM ユーザーが、権限のある IAM ロールにスイッチロールする方式です。
IAM ユーザーを発行するものの、IAM ユーザーには権限を与えず、 IAM ロールに権限を与えます。
IAM ユーザーが IAM ロールにスイッチロールする際に、短期的なAWS クレデンシャル（アクセスキー・シークレットアクセスキー）を発行します。

引用元：IAM の一時的な認証情報 - AWS Identity and Access Management

AWS クレデンシャルの発行と使用は、以下の流れになります。こちらも例としまして、オンプレミスのサーバーから S3 バケットにファイルをアップロードします。

IAM ユーザーを作成し、アクセスキー・シークレットアクセスキーを発行
1 で発行したアクセスキー・シークレットアクセスキーを使用し、AWS STS の API (AssumeRole) を実行する。AWS STS の API (AssumeRole) では、スイッチロールに使用するアクセスキー・シークレットアクセスキー・セッショントークンを発行する。その際に有効期限を指定する。
AWS の API を実行する各種ツールを使い、AWS に API を発行する。その際に、２で発行したアクセスキー・シークレットアクセスキー・セッショントークンを使用。

※ 本方式では IAM ユーザーを発行していますが、 AWS 以外の外部システムで使用しているユーザー ID 等を用いることも可能です。詳細は下記リンクを参照ください。条件として AWS Organizations の利用が必須です。
IAM の一時的な認証情報 - AWS Identity and Access Management
AWSアカウントシングルサインオンの設計と運用

また、本方式では課題として以下が挙がります。

スイッチロール元の IAM ユーザーにアクセスキー・シークレットアクセスキーを発行することになる。長期的に使えるものであり、期限等は設定できない。
AWS STS の API (AssumeRole) で発行した短期的なアクセスキー・シークレットアクセスキー・セッショントークンを、手動登録して使う必要がある。登録を自動化するにはシェルスクリプト等の作り込みが必要。
- 例（右記リンクを参照しています。：AWS リソースを使用した一時的な認証情報の使用 - AWS Identity and Access Management）：
  - export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
  - export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  - export AWS_SESSION_TOKEN=AQoDYXdzEJr...

IAM Roles Anywhere の認証方式

IAM Roles Anywhere の認証方式を確認します。
AWS ACM の Private CA を認証局として使用する方式と、自身が管理する認証局を使用する方式があります。
本記事では前者の方式を紹介します。折を見て、後者の方式を追記しようと考えていますので、ご期待ください。

１．AWS ACM の Private CA を認証局として使用する方式

まず、エンドエンティティ証明書の準備をします。

オンプレミスのサーバー上で Openssl コマンド等を使い、エンドエンティティ証明書の秘密鍵と署名リクエスト（CSR）を作成。
AWS ACM の Private CA に認証局を作成し、エンドエンティティ証明書を発行する。エンドエンティティ証明書を発行する際に、１で作成した署名リクエスト（CSR）を使用する。暗号化アルゴリズムや有効期限も指定する。（エンドエンティティ証明書を発行する API：IssueCertificate は、AWSマネジメントコンソールから実行できないため、CloudShell や EC2 環境を使用して実行する。）
作成したエンドエンティティ証明書をダウンロードし、オンプレミスのサーバーに配置する。（エンドエンティティ証明書をダウンロードする API：GetCertificate は AWSマネジメントコンソールから実行できないため、CloudShell や EC2 環境を使用して実行する。）

次に IAM Roles Anywhere を使用する準備をします。

Private CA に作成したエンドエンティティ証明書をIAM Roles Anywhere で、Trust anchors （信頼アンカー）として設定する
IAM Roles Anywhere にプロファイルを作成し、オンプレミスのサーバーの使用する IAM ロールを登録する。
オンプレミスのサーバーに aws_signing_helper をインストールする。

AWS クレデンシャルの発行と使用は、以下の流れになります。

オンプレミスのサーバー上で aws_signing_helper を使用する。IAM Roles Anywhere から IAM ロールを使用するためのアクセスキー・シークレットアクセスキー・セッショントークンを受け取る。その際に、エンドエンティティ証明書と秘密鍵の情報を引数に入れて認証する。
１で受け取ったアクセスキー・シークレットアクセスキー・セッショントークンを使用して、AWS に API を発行する。

補足：

以下は、aws_signing_helper の使用イメージです。エンドエンティティ証明書・秘密鍵の他に、信頼アンカー、プロファイル、IAM ロールの情報をオプションで指定します。
エンドエンティティ証明書と秘密鍵、信頼アンカーを認証に使い、プロファイル内の IAM ロールの認証情報を要求します。

./aws_signing_helper credential-process \
     --certificate ./cert.pem \
     --private-key ./private-key.pem \
     --trust-anchor-arn $TA_ARN \
     --profile-arn $PROFILE_ARN \
     --role-arn $ExampleS3WriteRole_ARN

なお、AWS のクレデンシャルを設定するファイルに以下のように記載することにより、自動的に認証情報を設定することも可能です。

[default]
 credential_process = ./aws_signing_helper credential-process
    --certificate /path/to/certificate.pem
    --private-key /path/to/private-key.pem
    --trust-anchor-arn <TA_ARN>
    --profile-arn <PROFILE_ARN>
    --role-arn <ExampleS3WriteRole_ARN>

引用元：IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する | Amazon Web Services ブログ

他、仕様の補足です。（緑色の吹き出し部分です。）

有効期限が７日以内のエンドエンティティ証明書のみを発行する場合は、Private CA の低コストのモードである "Short-Live" を利用可能。
IAM Roles Anywhere のプロファイル内にある各 IAM ロールの権限を、セッションポリシー機能を使って、横断的に制限可能。異なる制限をかける場合には、新しいプロファイルを作成する。
認証に使うエンドエンティティ証明書（の Subject ）に応じて、使用可能な IAM ロールを制限可能。IAM ロールの信頼ポリシーを記述することにより実現。

最後に、本方式では課題として以下が挙がります。

aws_signing_helper をオンプレのサーバーに配置する必要がある。脆弱性等がある場合は新しいものを配置し直すことが想定される
発行したエンドエンティティ証明書の期限切れ等には注意が必要
IAM Roles Anywhere のプロファイルと、プロファイルに紐づく IAM ロールの管理が必要

他、調査した際に気付いた留意点１

Private CA にエンドエンティティ証明書を発行する API には、IssueCertificate の他に、RequestCertificate もあります。
RequestCertificate は AWSマネジメントコンソールからエンドエンティティ証明書を発行する、 CSR が不要な方式になります。
仕様上の制約として、エンドエンティティ証明書の有効期間が 13ヶ月になります。
また、Private CA を "Short-Live" モードにした場合には、有効期限が７日以内のエンドエンティティ証明書しか発行できないため、RequestCertificate API ではエンドエンティティ証明書を作成できません。

ACM コンソールでリクエストされたプライベート証明書は 13 か月間有効です。有効期間が CA の有効期間を超えていると、ACM プライベート CA はプライベート証明書を発行できません。CA の有効期間が 13 か月未満の場合、ACM コンソールでプライベート証明書をリクエストすると [Failed] (失敗) エラーが表示されます。

引用元： ACM-PCA の有効期間が 13 か月未満の場合に ACM を使用してプライベート証明書をリクエストする

上のような制約があるため、本記事では構成の記載を割愛しました。

他、調査した際に気付いた留意点２

エンドエンティティ証明書を発行する際に選択する暗号化アルゴリズムは、RSA でも ECDSA でも大丈夫です。

To authenticate a request for credentials, IAM Roles Anywhere validates the incoming signature by using the signature validation algorithm required by the key type of the certificate, for example RSA or ECDSA.

引用元：https://docs.aws.amazon.com/ja2_jp/rolesanywhere/latest/userguide/trust-model.html#signature-verification

料金

IAM Roles Anywhere は無料です。

IAM Roles Anywhere は、ほとんどの商用リージョンにおいて追加料金なしで使用できます。

引用元：AWS Identity and Access Management で AWS 外のワークロード向けの IAM Roles Anywhere がリリース

Private CA は料金がかかります。以下の料金ページをご確認ください。

AWS Private CA Pricing – AWS Private Certificate Authority – Amazon Web Services

まとめ

IAM Roles Anywhere を使うと、オンプレミスなどAWS外部のサーバーに、AWS環境からアクセスキーやシークレットアクセスキーを払い出す必要がなくなります。
オンプレミスなどAWS外部のサーバー上で発行し保管している秘密鍵を使って、AWS の API を実行できるようになります。
個別に IAM ユーザーを作成してクレデンシャルを発行するのではなく、IAM Roles Anywhere を使って、認証を一元管理できます。
一方で、認証を行う新しいツールである aws_signing_helper を対象のサーバー上に配置する必要があります。また、認証に使用するエンドエンティティ証明書の有効期限に注意する必要があります。