View a markdown version of this page

ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする - AWS 規範ガイダンス
概要前提条件と制限事項アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース追加情報

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする

Benjamin Morris、Nima Fotouhi、Aman Kaur Gandhi、および Chad Moon、Amazon Web Services

概要

パイプラインのスコープを超える AWS Identity and Access Management (IAM) ロールのアクセス許可は、組織に不要なリスクをもたらす可能性があります。開発者は、開発中に広範なアクセス許可を付与することがありますが、コードのトラブルシューティング後にアクセス許可の範囲を絞り込むことを忘れることがあります。これにより、ビジネスニーズのない強力なロールが存在し、セキュリティエンジニアによってレビューされていない可能性がある問題が発生します。

このパターンの場合、問題の解決策としてロールベンディングマシン (RVM) があります。RVM は、一元化された安全なデプロイモデルを使用して、開発者の労力を最小限に抑えながら、個々の GitHub リポジトリのパイプラインに対して最小特権の IAM ロールをプロビジョニングする方法を示します。RVM は中央ソリューションであるため、セキュリティチームを変更の承認に必要なレビューアーとして設定できます。このアプローチにより、セキュリティチームは過剰な権限のパイプラインロールリクエストを拒否できます。

RVM は Terraform コードを入力として受け取り、パイプライン対応の IAM ロールを出力として生成します。必要な入力は、 AWS アカウント ID、GitHub リポジトリ名、およびアクセス許可ポリシーです。RVM はこれらの入力を使用して、ロールの信頼ポリシーとアクセス許可ポリシーを作成します。結果として得られる信頼ポリシーにより、指定された GitHub リポジトリがロールを引き受け、パイプラインオペレーションに使用できます。

RVM は IAM ロール (ブートストラップ中に設定) を使用します。このロールには、組織内の各アカウントで role-provisioning-role を引き受けるアクセス許可があります。ロールは、 AWS Control Tower Account Factory for Terraform (AFT) または AWS CloudFormation StackSets を介して設定されます。role-provisioning-roles は、開発者向けのパイプラインロールを実際に作成するロールです。

前提条件と制限事項

前提条件

  • アクティブ AWS アカウント。

  • GitHub Actions を通じて Infrastructure as Code (IaC) をデプロイするために使用される GitHub 組織。(GitHub Enterprise/Premium/Ultimate は必要ありません 。)

  • マルチアカウント AWS 環境。この環境の一部である必要はありません AWS Organizations。

  • all AWS アカウント (AFT や CloudFormation StackSets など) に IAM ロールをデプロイするメカニズム。

  • Terraform バージョン 1.3 以降がインストールされ、設定されている。

  • Terraform AWS Provider バージョン 4 以降がインストールされ、設定されています。

制限事項

  • このパターンのコードは GitHub Actions と Terraform に固有のものです。ただし、パターンの一般的な概念は、他の継続的インテグレーションおよびデリバリー (CI/CD) フレームワークで再利用できます。

  • 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「AWS サービス (リージョン別)」を参照してください。特定のエンドポイントについては、「サービスエンドポイントとクォータ」を参照して、サービスのリンクを選択してください。

アーキテクチャ

次の図は、このパターンのワークフローを図解したものです。

GitHub Actions を使用して IAM ロールの作成とデプロイを自動化するワークフロー。

ロールベンディングマシンは、一般的に以下のステップで使用されます。

  1. 開発者は、新しくリクエストされた IAM ロールの Terraform コードを含むコードを RVM GitHub リポジトリにプッシュします。このアクションは、RVM GitHub Actions パイプラインをトリガーします。

  2. パイプラインは、OpenID Connect (OIDC) 信頼ポリシーを使用して RVM ロール引き受けロールを引き受けます。

  3. RVM パイプラインは実行されると、開発者の新しい IAM ロールをプロビジョニングするアカウントの RVM ワークフローロールを引き受けます。(RVM ワークフローロールは、AFT または CloudFormation StackSets を使用してプロビジョンされました。)

  4. RVM は、適切なアクセス許可と信頼を持つ開発者の IAM ロールを作成し、そのロールを他のアプリケーションパイプラインが引き受けられるようにします。

  5. アプリ開発者は、この RVM がプロビジョニングしたロールを引き受けるようにアプリパイプラインを設定できます。

作成されたロールには、開発者がリクエストしたアクセス許可とReadOnlyAccess ポリシーが含まれます。ロールを引き受けられるのは、開発者が指定したリポジトリの main ブランチに対して実行されるパイプラインだけです。このアプローチで、ロールを使用するためにブランチの保護とレビューを要求できます。

自動化とスケール

最小特権のアクセス許可では、プロビジョニングされる各ロールの詳細に注意する必要があります。このモデルにより、これらのロールの作成に必要となる複雑さが軽減され、開発者は追加の学習や多大な労力をかけることなく、必要なロールを作成できます。

ツール

AWS のサービス

  • AWS Identity and Access Management (IAM) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。

  • AWS Organizations は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。

その他のツール

  • Git はオープンソースの分散バージョンの管理システムです。これには、組織アカウントを作成する機能が含まれます。

  • GitHub Actions は、GitHub リポジトリと密接に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、ビルド、テスト、デプロイパイプラインを自動化できます。

  • 「Terraform」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

コードリポジトリ

このパターンのコードは、GitHub 内の role-vending-machine リポジトリで利用できます。

ベストプラクティス

  • 正しい方法は簡単に、間違った方法は難しく – 正しい方法を簡単に行えるようにします。開発者が RVM プロビジョニングプロセスに苦戦しているときに、他の方法でロールを作成しようとする可能性があります。その場合、RVM の中心的な性質が損なわれます。セキュリティチームが RVM を安全かつ効果的に使用する方法について明確なガイダンスを提供していることを確認します。

    また、開発者が間違った方法で作業するのが難しくなるようにする必要があります。サービスコントロールポリシー (SCPs) またはアクセス許可の境界を使用して、他のロールを作成できるロールを制限します。このアプローチによって、ロールの作成を RVM やその他の信頼できるソースのみに制限できます。

  • 良い例を提供する – 一部の開発者は、必然的に非公式テンプレートとして RVM リポジトリ内の既存のロールを適応させ、新しいロールにアクセス許可を付与するようになります。コピー可能な最小限のアクセス許可の例がある場合は、それを提供して、開発者が広範でワイルドカードの多いアクセス許可をリクエストするリスクを軽減できるようにします。多数のワイルドカードを持つアクセス許可の多いロールから開始すると、時間の経過とともにその問題が増大する可能性があります。

  • 命名規則と条件を使用する – 開発者がアプリケーションで作成されるすべてのリソース名を知らなくても、命名規則を使用してロールのアクセス許可を制限する必要があります。例えば、Amazon S3 バケットを作成する場合、リソースキーの値は arn:aws:s3:::myorg-myapp-dev-* のようになります。これにより、ロールはその名前に一致するバケット以外のアクセス許可を持たなくなります。IAM ポリシーを使用して命名規則を適用すると、命名規則への準拠が向上するという別の利点があります。これは、一致しないリソースは作成できなくなるためです。

  • プルリクエスト (PR) レビューを要求する – RVM ソリューションの価値は、新しいパイプラインロールをレビューできる一元的な場所を作成することにあります。ただし、この設計は、安全で質の高いコードが RVM にコミットされるよう保証するガードレールがある場合にのみ役立ちます。コード (main など) をデプロイするために使用されるブランチを直接のプッシュから保護し、それらをターゲットとするマージリクエストの承認を要求します。

  • 読み取り専用ロールを設定する – デフォルトでは、RVM はリクエストされた各ロール readonly バージョンをプロビジョニングします。このロールは、terraform plan パイプラインワークフローなど、データを書き込まない CI/CD パイプラインで使用できます。このアプローチは、読み取り専用ワークフローの動作が異常である場合に、不要な変更を防ぐのに役立ちます。

    デフォルトでは、 AWS 管理ReadOnlyAccessポリシーは読み取り専用ロールと読み取り/書き込みロールの両方にアタッチされます。このポリシーによって、必要なアクセス許可を決定する際のイテレーションの必要性を軽減できますが、一部の組織では過度な許可となる場合があります。必要に応じて、Terraform コードからポリシーを削除できます。

  • 最小限の権限を付与する – 最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「最小限の特権を認める。」と「IAM でのセキュリティのベストプラクティス」を参照してください。

エピック

タスク説明必要なスキル

サンプルリポジトリを GitHub 組織にコピーします。

このパターンのリポジトリをクローンするか、このリポジトリを GitHub 組織にフォークして、ニーズに合わせて調整できるようにします。

  • このリポジトリのクローンを作成する場合は、次のコマンドを使用できます。git clone https://github.com/aws-samples/role-vending-machine

  • リポジトリを GitHub 組織にフォークすることを選択した場合は、次のコマンドを使用できます。

    gh repo fork aws-samples/role-vending-machine --org YOUR_ORGANIZATION_NAME

DevOps エンジニア

RVM AWS アカウント の を決定します。

RVM AWS アカウント に使用するインフラストラクチャのデプロイを決定します。管理アカウントまたはルートアカウントを使用しないでください。

クラウドアーキテクト

(オプション) 組織のパイプラインに PR の作成を許可します。

注記

このステップは、generate_providers_and_account_vars ワークフローに PR の作成を許可する場合にのみ必要です。

組織のパイプラインに PR の作成を許可するには、次の手順を実行します。

  1. https://github.com/organizations/YOUR_ORG/settings/actions に移動します。

  2. [GitHub Actions にプルリクエストの作成と承認を許可する] を選択します。

詳細については、GitHub ドキュメントの「リポジトリの GitHub Actions の設定を管理する」を参照してください。

DevOps エンジニア

RVM アカウントに読み取り専用アクセス許可を付与します。

RVM アカウントに読み取り専用アクセス許可を付与する委任ポリシーを管理アカウントに作成します。これにより、RVM GitHub ワークフローは、generate_providers_and_account_vars.pyスクリプトの実行時に AWS 組織のアカウントのリストを動的にプルできます。

次のコードを使用して、 をステップ 2 で選択した AWS アカウント ID <YOUR RVM Account ID>に置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<YOUR RVM Account ID>:root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
クラウド管理者

サンプルリポジトリのデフォルト値を更新します。

特定の環境で動作するように RVM を設定するには AWS リージョン、次の手順を実行します。

  1. scripts/generate_providers_and_account_vars.py およびその他のファイル (bootstrap フォルダなど) を、運用している適切なリージョンで更新します。

  2. AWS アカウント ID、リージョン、および指定するその他の変数を使用して.github/workflows/.envファイルを更新します。

DevOps エンジニア
タスク説明必要なスキル

RVM リポジトリをブートストラップします。

このステップは、RVM パイプライン自体で使用される OIDC 信頼ロールと IAM ロールを作成するために必要です。これにより、他のロールの運用と販売を開始できるようになります。

RVM アカウントのコンテキストで、scripts/bootstrap ディレクトリから terraform apply コマンドを手動で実行します。変数ドキュメントに基づいて必要な値を指定します。

DevOps エンジニア
タスク説明必要なスキル

github-workflow-rvm および github-workflow-rvm-readonly ロールをすべてのアカウントにデプロイします。

AFT や StackSets など、組織のプラクティスに沿ったデプロイ方法を選択します。このメソッドを使用して、scripts/assumed_role/main.tf ファイル内の 2 つの IAM ロール (デフォルト名 github-workflow-rvm と github-workflow-rvm-readonly) を、RVM がパイプラインロールを作成できる各アカウントにデプロイします。

これらの IAM ロールには、RVM アカウントのロール引き受けロール (または readonly と同等のロール) が引き受けることを許可する信頼ポリシーがあります。このロールには、github-workflow-role-* に一致するロールの読み取りと書き込み (readonly ロールを使用している場合を除く) を許可する IAM アクセス許可ポリシーもあります。

AWS 管理者

generate_providers_and_account_vars ワークフローを実行します。

RVM を設定してパイプラインロールを作成する準備を整えるには、次の手順を実行します。

  1. workflow_dispatch を使用して generate_providers_and_account_vars ワークフローを実行します。

  2. ワークフローが作成する PR をマージします。

ワークフローが完了すると、RVM は次を行う準備が整います。

  • 新しいパイプラインロールのリクエストを受け入れる。

  • 必要に応じて、読み取り専用ロールまたは読み取り/書き込みロールを作成する。

  • 指定された にロールをデプロイします AWS アカウント。

DevOps エンジニア

トラブルシューティング

問題ソリューション

RVM を使用してロールを作成しましたが、GitHub がロールを引き受けることができません。

GitHub リポジトリの名前が github_workflow_roles モジュールに指定された名前と一致していることを確認します。引き受けられるリポジトリが 1 つだけになるように、ロールの範囲が設定されています。

同様に、GitHub パイプラインで使用されるブランチが、github_workflow_roles モジュールに指定されたブランチの名前と一致することを確認します。通常、書き込み権限を持つ RVM 作成ロールは、main ブランチ (つまり、main から取得されたデプロイ) を対象とするワークフローでのみ使用できます。

特定のリソースを読み取るアクセス許可がないため、読み取り専用ロールはパイプラインの実行に失敗しています。

ReadOnlyAccess ポリシーには広範な読み取り専用アクセス許可がありますが、一部の読み取りアクション (特定の AWS Security Hub CSPM アクションなど) はありません。

github-workflow-roles モジュールの inline_policy_readonly パラメータを使用して、特定のアクションのアクセス許可を追加できます。

関連リソース

追加情報

GitHub 環境の使用

GitHub 環境は、ロールアクセスのブランチベースの制限に代わるアプローチです。GitHub 環境を使用する場合、IAM 信頼ポリシーの追加条件の構文の例は以下のようになります。この構文は、GitHub アクションが Production 環境で実行されている場合にのみロールを使用できることを指定します。

"StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production"
}

構文の例では、次のプレースホルダー値を使用します。

  • octo-org は GitHub 組織名です。

  • octo-repo はリポジトリの名前です。

  • Production は特定の GitHub 環境名です。