459-AWS SAP AWS 「理論・実践・一問道場」GitHub Action（OIDC）

type

status

date

slug

summary

理論

1. AWS STS (Security Token Service)

STSは、短期間有効な認証情報を生成するサービスで、IAMユーザーやサービスがAWSリソースにアクセスするための一時的なセキュリティトークンを発行します。

sts:AssumeRoleを使ってIAMロールを引き受け、短期的な認証情報を得ることができます。

2. OIDC (OpenID Connect)

OIDCは、WebアプリケーションやCI/CDパイプラインにおいて、ユーザー認証のための標準的なプロトコルです。GitHubなどの外部サービスがAWSと連携する際に利用されます。

GitHub Actionsでは、OIDCを使って、IAMロールへのアクセスを一時的な認証情報を通じて安全に取得できます。

3. GitHub Actions と AWS の連携

GitHub Actionsは、CI/CDパイプラインを自動化するためのツールで、AWSリソースを操作するためには、認証情報が必要です。長期的なアクセスキーを使う方法はセキュリティ上のリスクがあるため、短期的なSTSトークンを使う方法が推奨されます。

4. セキュリティのベストプラクティス

長期的な秘密鍵やアクセスキーの使用を避け、一時的なSTSトークンを使用することで、セキュリティリスクを最小限に抑えます。

OIDCやSAMLなどの外部認証プロバイダーを使うことで、AWSのアクセスをよりセキュアに管理できます。

これらの知識を理解することで、GitHub ActionsのようなCI/CDパイプラインをAWSに統合し、セキュリティと運用の負担を軽減することが可能です。

実践

略

一問道場

問題 #459

ある企業は、GitHub Actionsを使用してCI/CDパイプラインを実行し、AWSリソースにアクセスしています。パイプラインは、AWSに認証するためにシークレットキーを使用するIAMユーザーを持っています。既存のIAMロールには、リソースをデプロイするために必要な権限を持つポリシーがアタッチされています。企業のセキュリティチームは、新しいポリシーにより、パイプラインでは長期間使用されるシークレットキーが使えなくなったという要件を導入しました。ソリューションアーキテクトは、シークレットキーを短期間で利用可能な別の方法に置き換える必要があります。

この要件を最も運用負担を軽減して満たす解決策はどれでしょうか？

A. AWS Identity and Access Management (IAM)でSAML 2.0アイデンティティプロバイダー(IdP)を作成し、適切な信頼ポリシーを設定した新しいIAMロールを作成します。そのロールに、sts:AssumeRole API呼び出しを許可し、既存のIAMポリシーをアタッチします。GitHubでSAML認証を使用するようにパイプラインを更新します。

B. AWS Identity and Access Management (IAM)でOpenID Connect (OIDC)アイデンティティプロバイダー(IdP)を作成し、GitHub OIDC IdPからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する信頼ポリシーを設定した新しいIAMロールを作成します。GitHubを更新して、そのロールをパイプラインで引き受けるようにします。

C. Amazon Cognitoアイデンティティプールを作成し、GitHubを認証プロバイダーとして設定します。その後、GitHub認証プロバイダーからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する信頼ポリシーを設定した新しいIAMロールを作成します。パイプラインをCognitoを使用するように設定します。

D. AWS Private Certificate Authorityで信頼アンカーを作成し、AWS IAM Roles Anywhereで使用するクライアント証明書を生成します。信頼ポリシーを設定した新しいIAMロールを作成し、sts:AssumeRole API呼び出しを許可します。パイプラインで資格情報ヘルパーツールを使用し、クライアント証明書の公開鍵を参照してIAMロールを引き受けるように設定します。

解説

この問題は、CI/CDパイプラインでAWSリソースにアクセスする際に使用されている長期的なIAMユーザーのシークレットキーを、短期間で利用可能な解決策に置き換える方法に関するものです。セキュリティチームの新しい方針に従い、長期間使われるシークレットキーの代わりに、短期的な認証情報を使いたいという要件があります。

各選択肢の解説

A. SAML 2.0 アイデンティティプロバイダーを使用する方法

SAMLは、組織内の認証情報をAWSに渡すための標準的なプロトコルです。これを利用するためには、GitHub ActionsがSAML認証をサポートしていなければならず、これを設定するには多少のカスタマイズが必要です。SAML 2.0は通常、企業内シングルサインオン(SSO)に使用されるため、GitHub Actionsのような外部サービスと組み合わせるのは少し手間がかかります。

B. OpenID Connect (OIDC) アイデンティティプロバイダーを使用する方法

OIDCは、GitHub ActionsとAWSを安全に接続するための非常に適した方法です。GitHub Actionsは、OIDCをサポートしており、AWS側でOIDCを使った一時的な認証を行うことができます。この方法は、最もシンプルかつ運用負担が少ない方法です。GitHub ActionsからのAPI呼び出しを許可するため、IAMロールで sts:AssumeRoleWithWebIdentity ポリシーを使う設定を行います。

C. Amazon Cognito を使う方法

Cognitoは、ユーザー認証を簡単に行えるサービスですが、GitHub ActionsのパイプラインでCognitoを認証プロバイダーとして使う方法は、セットアップが複雑になる可能性があり、直接的な利点が少ない場合もあります。OIDCを使った方法に比べると運用負担が大きくなるかもしれません。

D. AWS IAM Roles Anywhere を使用する方法

IAM Roles Anywhereは、証明書ベースの認証を使って、オンプレミスや外部システムからAWSリソースへのアクセスを管理するものです。この方法は、GitHub Actionsでの利用には過剰な設定が必要で、運用負担が大きくなる可能性があります。特に、証明書の管理や資格情報ヘルパーツールの使用など、追加の手間がかかります。

最適な解決策

最もシンプルで運用負担が少なく、GitHub ActionsとAWS間で短期的な認証を行うために最適な方法は、B. OIDCを使用する方法です。これにより、GitHub Actionsは直接AWSのIAMロールを引き受け、一時的な認証情報を得ることができます。これにより、シークレットキーを使用する必要がなく、セキュリティ要件も満たすことができます。