IAMポリシーのワークショップをやってみた

AWS Workshopの「How and when to use different IAM policy types」をやってみました

はじめに

データアナリティクス事業本部のおざわです。

7月25日は、自宅で井上尚弥選手の試合を観戦して盛り上がっていました。勝利者インタビューで「まだ改善の余地がある」と答えていたのが印象的でした。次の試合も楽しみですね。

今回は、AWSのWorkshop Studioの中から「How and when to use different IAM policy types」というワークショップをやってみました。普段、IAMポリシーを自分で設定する機会があまりなかったので、自分で手を動かしながらいろいろと試したくなったというのが理由です。

いまのところ英語版しかないようです。環境構築はワークショップ用のCloudFormationテンプレートが用意されています。期待したとおり、手を動かしながら各種ポリシーの設定を試すことができました。

コース概要

本ワークショップでは、以下の4種類のポリシーについて学びます。今回、4つ目に関してはAWS Organizationsの管理アカウントが必要になり、オプションとなっているので一旦飛ばしました。

  • アイデンティティーベース
  • リソースベース
  • アクセス許可の境界
  • Service control policy(SCPs)

前提条件

コースを進めるのに必要な前提知識は、IAMに関する基本的な知識とのことです。

AWSアカウントは2つ必要になります。

シナリオ

ワークショップのシナリオとしては、旅行用のアプリケーションを開発する会社のクラウドチームの一員として、各Labで指示されたとおりに環境構築や各種リソース、ポリシーの設定を行います。この会社のアカウントはAWSの複数アカウントのベストプラクティスに則ってアプリ用とデータレイク用の2つのAWSアカウントに分かれています。

アプリ用アカウントではCI/CD環境の構築、アプリケーションのデプロイを実施し、データレイク用のアカウント内にあるS3バケットから履歴情報(デモなのでダミーのテキストファイル)を取得します。

ワークショップの準備

もともとこのワークショップは、AWSのイベント中で実施されるもので、他の人とチームになって実行する想定で作られているようです。手順には2つのアカウントで同じ環境を構築し、アカウントIDとデータレイクのバケット名をパートナーと交換するように記載されています。

ただ、今回の私のように1人で手を動かす場合、CloudFormationを実行するのはアプリ用アカウントだけで問題ありません。データレイク用アカウントでは、履歴情報用のS3バケットの作成とバケットポリシーの設定をすればLab5までのワークショップは実施できました。

CloudFormationの実行

Workshop Setupの「On Your Own」タブにあるCloudFormationテンプレートをアプリ用のアカウントで実行すると、下図のような環境が構築されます。実際には他にもデプロイされるものがたくさんありますが、主要なものは以下のとおりです。

  • Lambda
  • S3
  • CodeCommit
  • CodePipeline
  • EC2
  • VPC Endpoint
※ワークショップのArchitecture Reviewから引用

データレイク用のアカウントでは、事前にS3バケットの作成が必要です。バケットを作成したら、中身はなんでもよいのでdatalake.txtという名前のテキストファイルを配置しておきます。Lab5でこのS3バケットにバケットポリシーの設定を行います。

ワークショップの内容

ワークショップ内のラボの簡単な説明と私が参考にさせてもらった記事のリンクを記載しています。

Lab0

Lab1では、セッションマネージャーでCLIを使用して、ワークショップで使用するお面…IAMロールを作成します。また、パラメータストア内の指定されたパラメータにデータレイク用アカウントに作成したS3バケットの名前を設定します。

IAMロールやAssumeRoleに関しては、こちらのブログをご参照ください。

Lab1

Lab1ではクラウドチームとしてアイデンティティーベースのポリシー設定を行います。アプリチームのIAMロールを作成して、トラブルシューティング用に特定のサービスに対して読み取り専用の権限とCodeCommitへのフルアクセスを与えます。

Lab2

Lab2ではCI/CDパイプラインで使用するロールを作成し、アクセス許可の境界を使います。CI/CDパイプラインがアプリケーション用のIAMロールを作成する際、IAMロールに対して適用可能な権限の範囲をアクセス許可の境界を使って限定します。次のLab3でこの境界が正しく機能していることを確認します。

Lab3

Lab3ではLab2で設定したCI/CDパイプラインを実行してアプリケーションがデプロイされ、アプリケーションに適切なIAMロールが適用されるていることを確認します。

ここでデプロイされるLambdaには、デモ用の処理が記述されています。パブリックアクセス可能なS3バケットやデータレイク用アカウントのS3の読み込み等が行われます。またLab2で設定したアクセス許可の境界ポリシーが機能していることを確認するため、エラーになる前提でIAMロール作成の処理が記述されています。

Lab4

Lab4ではアプリ用アカウントとデータレイク用アカウントのS3バケットへのアクセスをパブリック接続ではなく、プライベート接続にします。VPCエンドポイントを経由してアクセスさせるようにポリシーの設定を行います。

Lab5

Lab5ではデータレイク用アカウントのS3バケットにバケットポリシーを設定してアプリケーションからアクセスできるようにします。一人でワークショップを実施する場合はUpdate the bucket policyに記載されているバケットポリシーにアプリ用アカウントのLambdaのロールARNとResource部分にバケット名を追加して適用します。

おわりに

今回はAWSのIAMポリシーに関するワークショップをご紹介しました。手を動かしながら調べたことで以前よりほんのちょっとだけわかった気になれましたが、IAMまわりはすごーく奥が深いので、まだまだ知らなければいけないことがありそうです。

参考リンク