AWSソリューションTag Tamerを実装してみた

はじめに

　AWSのソリューションTag Tamerを実装します。
　Tag Tamerは、タグ付けに関するソリューションです。
　試した感じだと、習熟に多少の時間が必要そうです。

　Tag Tamerはパブリック用とプライベート用がありますが、本記事はパブリックを選択しています。
　プライベート用はVPNまたはDirect Connectが必要なため、構築に時間とコストがかかってしまうからです。

　本記事では実装ガイド通りに行って、スムーズにいかなかったところだけ記載しています。
　公式実装ガイドと、以下のclassmethod様の記事を非常に参考にさせていただきました。

実行環境

• macOS Big Sur 11.2.3
• Google Chrome 91.0.4472.114（Official Build） （x86_64）

構成図

引用：https://aws.amazon.com/jp/solutions/implementations/tag-tamer/

引用：https://docs.aws.amazon.com/solutions/latest/tag-tamer/architecture-overview.html

作成・利用までの流れ

• デプロイリージョンの決定
  • CognitoとSESの関係でus-east-1,us-west-2,eu-west-1のいずれか
  • 今回はus-east-1を選択
• ALBに使用するACM証明書準備
  • パブリックの場合に必要
• リンクされた各アカウントのクロスアカウントロール作成
  • 今回は実施せず
• SESにメールアドレス登録
  • Tag Tamer Web Appに登録する際の確認コード送信で利用
• SESのsending authorization policy追加
  • Cognitoがメールアドレスを使用できるようにするため
• 用意されているテンプレを使用してCloudFormation Stack起動
• Cognito IDプール設定
• マルチアカウント・マルチリージョン構成の設定
  • 今回は実施せず
• IAMロール作成
  • Web Appでタグ付け操作などを行うための管理者用のロール
• Cognitoユーザープールでグループ作成し、上記IAMロールをアタッチ
• Web Appにアクセスし、登録
• Cognitoユーザーグループに、登録したユーザーを割り当て
• 以後Web App利用可能に

作成してみる

実装ガイド通りに進めて、スムーズでなかったところだけ記載しています。

ACM証明書の準備

自己署名証明書で準備します。

途中でエラーが発生。
v3_caのロードでエラーが発生したとのこと。

# openssl req -new -x509 -nodes -days 398 -extensions v3_ca -key my-aws-private.key > my-aws-public.crt
Error Loading extension section v3_ca

こちらを参考に、

以下を設定ファイルに追加して解決しました。

/etc/ssl/openssl.cnf

[v3_ca] 
basicConstraints = Critical、CA：TRUE 
subjectKeyIdentifier = hash 
AuthorityKeyIdentifier = keyid：always、issuer：always

• v3_caは拡張セクションであり、コマンドで指定した拡張セクションが設定ファイル存在しないためエラーが発生
• 設定ファイルに拡張セクションv3_caを記述すれば解決
• セクションとは、opensslのコマンドが参照するセクションのこと
• basicConstraintsはCA証明書かどうかを示し、Criticalは設定内容の厳守を求める
• subjectKeyIdentifierは証明書の所有者の公開鍵を識別し、hashに指定するとRFC3280のガイドラインに自動的に従う
• AuthorityKeyIdentifierは証明書の署名検証のために認証局が所有する複数の公開鍵のうち、どれを使用するかを指定する
• keyidはsubjectKeyIdentifierを親証明書からコピー
• issuerは発行者の証明書から発行者とシリアル番号をコピー
• alwaysはコピーを強制する

上記のsubjectKeyIdentifier以降の記述は、よく理解せずに記載しておりますのでご注意ください。

以下は実装ガイドから引用したもの。
Chromeからだと、Common Nameはアクセスするドメイン名に合わせなければアクセスできなかったので、ALBのドメイン名に合わせる。
*.us-east-1.elb.amazonaws.comなどにする。

    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:Washington
    Locality Name (eg, city) []:Seattle
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:AWS
    Organizational Unit Name (eg, section) []:
    Common Name (e.g. server FQDN or YOUR name) []:*.aws.amazon.com
    Email Address []:

# openssl pkcs12 -inkey my-aws-private.key -in my-aws-public.crt -export -out my-aws-public.p12

• pkcs12はSSL証明書のバックアップ・エクスポート等に用いられる秘密鍵と証明書を一つのファイルに格納する方式

実装ガイドでは上記コマンド実行していますが、ACMへのインポートには不要な気がします。

なお、ACMのインポート作業でコストはかかりません。

SESの準備

Web Appの確認コードを取得するためのEメールアドレスを提供します。

コストは気にしなくていいくらいの金額。
メールの送信は6万2000通まで無料、メッセージのデータ量1GBごとに0.12USD。

作成

CloudFormation作成

CIDR Range

Web Appへのアクセスを許可するサブネットを入力します。
検証なので自分のIPアドレスか0.0.0.0/0を入力すればいいでしょう。
Web Appにアタッチされるセキュリティグループの、インバウンドルールのソースになります。

CognitoIDプール編集

CloudFormationの作成完了後、Cognitoを編集します。

実装ガイドおりにエラーなく完了しましたが、Cognitoに対する知識がなかったので、調査内容を個人用に残しておきます。

CognitoIDプールとは？

Cognitoの主要コンポーネントとして、ユーザープールとIDプールがある。
ユーザープールはアプリケーションのサインアップ、サインイン時の認証で利用され、IDプールはAWSリソースへのアクセスを許可するために利用される。

なお、ユーザープールのグループにIAMロールを割り当て、グループのメンバーにAWSリソースへのアクセスを許可することもできる。

マルチアカウント、マルチリージョン対応

今回は試しません。

Cognitoユーザグループに割り当てるロール作成

実装ガイド通りでOK

Cognitoユーザグループ作成

実装ガイド通りでOK

Tag Tamer Web App

ブラウザでアクセスする際の注意表示（自己署名証明書が原因）

ChromeでURLにアクセスする際（Chrome以外のブラウザも同様と思われる）、プライバシーが守られないと表示されますが、検証目的なので無視してアクセスします。

そのような表示が出る原因は、SSL証明書をSAN(Subject Alernative Name)対応で作成していないからです。
プライバシーが守られないと表示されないようにするためには、少なくとも以下の作業が必要になります。

• SSL証明書をSAN(Subject Alernative Name)対応で作成
• ChromeでSSL証明書を信頼できる証明書に設定

Web appへの登録

エラーなく完了。
登録後、SESに登録したメールアドレスからコードが記載されたメールが届くので、そのコードを入力します。

Cognitoユーザーグループに登録したユーザー割り当て

Web appに登録したユーザーがCognitoユーザープールに追加されています。

Web App利用可能に

自由にタグ付けなど行います。
何ができるのかは自分で色々と試してみるのが一番だと思います。
実際にWeb Appで何ができるかは、実装ガイドをご覧ください。

おわりに

こうしてソリューションを構築したのは初めてですが、以下の点からかなり勉強になりました。

• 普段扱わないサービスに触れるので、そのサービスの概要や基礎知識を知られる
• 意識していなかった自分が知らなかったところが分かる
• ソリューションを完成させるという目的があるので、学習意欲が下がりにくい

Tag Tamerは、マルチアカウント・マルチリージョンで統一すべきタグがある際に、より効果を発揮しそうですね。
パブリック用だとコストが嵩みますが、企業だとVPNやDirect Connectが導入済みなところが多いと思いますので、プライベート用を利用すればコストも抑えられそうです（EC2を使用時にだけ立ち上げるのもあり）。

欲を言えば、ソリューションではなく、マルチアカウント・マルチリージョンの全リソースに対してタグ付けを容易にするマネージドサービスが出てきてほしいです。
管理者アカウントのTag Editorでできると良いですね。

本記事は以上になります。
誰かのお役に立てれば幸いです。