Amazon Web Services ブログ
AWS Single Sign-On を使用して Amazon CloudWatch ダッシュボードを共有する
この記事は、Share your Amazon CloudWatch Dashboards with anyone using AWS Single Sign-On (記事公開日: 2021 年 11 月 18 日) を翻訳したものです。
Amazon CloudWatch は、お客様が監視・運用データをログ、メトリクス、アラーム、イベントの形で収集することで、ワークロードの可視化や通知を容易に行うことができるサービスです。従来、運用状況データへのアクセスは、テクニカルサポートスタッフしか見ることができず、その結果、運用状況は多くのビジネスパーソンにとって不透明なものとなっていました。しかし、CloudWatch のデータへのアクセスをクラウドやオンプレミス環境のテクニカルサポートスタッフ以外の人々にも拡大することで、実用的で貴重なビジネスインサイトを得ることができます。
例えば、E コマースアプリケーションでの購入率、ウェブアプリケーション全体の応答時間、データセンターインフラ全体への影響を示すアラートなど、意味のあるビジネス指標が得られます。CloudWatch は、時系列、ログ、イベント、アラームを管理する多目的システムであり、ビジネス KPI に可観測性を持たせるために容易に利用することができます。そして、このデータを関係者に公開することがより容易にできるようになりました。
この情報アクセスを管理するために、Amazon CloudWatch は CloudWatch ダッシュボードの共有を導入しました。CloudWatch ダッシュボードの共有により、お客様は簡単かつ安全にCloudWatch ダッシュボードを組織外の人、別のビジネス組織、または AWS コンソールにアクセスできない人と共有することができます。本ブログでは、セキュアなアクセスを仲介するために SAML プロバイダーを介してダッシュボードを企業全体で共有する方法を紹介します。
この例では、Amazon CloudWatch を AWS Single Sign-On (AWS SSO) と統合する方法と、必要なコンポーネントの概要を説明します。 本ブログでは、AWS SSO の設定には焦点を当てず、AWS SSO または他の設定された SAML プロバイダーの環境を持っていることを前提とします。AWS SSO の設定と運用方法については、こちらのガイダンスをご覧ください。
ソリューション概要
このソリューションでは、ユーザーが CloudWatch ダッシュボードにアクセスするための入り口として、AWS SSO を利用します。AWS SSOは、ユーザーに CloudWatch ダッシュボードへの読み取り専用アクセスを許可する Amazon Cognito ユーザープールと連携する SAML プロバイダーとして機能します。本ブログでは AWS SSOを利用していますが、他のIDプロバイダーを利用することもでき、また環境に AWS SSO を含める必要はありません。AWS SSO は、公開する CloudWatch ダッシュボードアプリケーションにグループを割り当てることでダッシュボードへのアクセス権を持つユーザーを制御します。
図 1: AWS SSO、Amazon Cognito、Amazon CloudWatch 間のフローを示したソリューション概要図
前提条件
本ブログでは、以下の前提条件をクリアしている必要があります。
- AWS SSO が ID プロバイダーを使用するように設定済みであること。SAML 属性として、ユーザーのメールアドレスを利用します。注:お客様の環境によっては多少異なる場合があります。
- CloudWatch ダッシュボードを共有できる状態であること。
本ソリューションで利用するサービス
Amazon CloudWatch は、監視・運用データをログ、メトリクス、イベントの形で収集し、ダッシュボードで可視化することでAWS とオンプレミスで稼働する AWS リソースやアプリケーション、サービスを統一的に把握することができます。
AWS SSO は、AWS 内で従業員の ID を作成または接続し、組織全体のアクセスを一元管理する場所です。AWS アカウントまたはクラウドアプリケーションへのアクセスのみを管理するように選択します。
Amazon Cognito (Cognito) を使用すると、Web およびモバイルアプリケーションにユーザーサインアップやサインイン、およびアクセス制御を迅速かつ簡単に追加することができます。Cognito は、数百万ユーザーまで拡張可能で、Apple、Facebook、Google、Amazon などのソーシャル ID プロバイダーや、SAML 2.0 および OpenID Connect によるエンタープライズ ID プロバイダーによるサインインに対応しています。
ダッシュボードの共有を有効にするための手順
先に進む前に、 以下のことを考慮してください。
- ダッシュボードの共有を有効にすると、有効にしたアカウントとリージョンのすべてのダッシュボードが SAML プロバイダーによってアクセス可能になり、アプリケーションへのアクセスを許可されたユーザーは、そのリージョンのすべてのダッシュボードに読み取り専用でアクセスできるようになります。
- CloudWatch はリージョナルサービスです。そのため、複数のリージョンからダッシュボードを共有したい場合は、各 AWS リージョンで同手順の一部を繰り返す必要があります。
- CloudWatch で作成されたデフォルトの Identity and Access Management のロールを利用しています。これは、CloudWatch Logs データや複合アラームのデフォルトの表示を許可しません。必要であれば後で有効にすることができます。
実装手順
- AWS コンソールを開き、CloudWatch に移動します。左下にある設定を見つけます。これをクリックすると、CloudWatchの設定が表示されます。
図 2: CloudWatch の設定画面の様子
- ダッシュボードの共有セクションの設定をクリックします。すると、SSO プロバイダーダイアログが表示されます。
図 3: CloudWatch の SSO プロバイダー選択画面
- SSO プロバイダーの管理をクリックし、次のステップを開始します。新しいブラウザタブに Cognito コンソールが開かれます。CloudWatch コンソールのタブは開いたままにしておいてください。
図 4:Cognito コンソールでの画面
- すでに CloudWatchDashboardSharing という Cognito ユーザープールが作成され、部分的に設定が完了しています。次に、AWS SSO がユーザーのアクセスを仲介するための SAML インテグレーションを作成します。フェデレーテッドアイデンティティプロバイダーのサインインセクションでアイデンティプロバイダーを追加をクリックし、その後 SAML ラジオボタンをクリックします。
アカウントのダッシュボードへのアクセスを許可するシングルサインオンアプリケーションを生成できるように、新しいブラウザタブで AWS SSO コンソールを開きます。AWS SSO コンソールから、左側のアプリケーションをクリックします。以下はアプリケーションのリストの例です。新規で AWS SSO を開くユーザーの場合はリストにアプリケーションは表示されません。
- 新規アプリケーションの追加をクリックして次に進みます。AWS SSO には CloudWatch の事前設定されたアプリケーションはありませんので、代わりにカスタムSAML 2.0 アプリケーションを作成します。カスタムSAML 2.0 アプリケーションの追加をクリックします。
図 6:カスタムSAML 2.0 アプリケーションの設定の開始
設定ダイアログでは、CloudWatch コンソールと Cognito コンソールからいくつかのデータをコピーする必要があります。同様に、Cognito コンソールにいくつかのデータをコピーして戻す必要があり、それによって両方のアプリケーション間の信頼関係が構築されます。
- 新しい SSO アプリケーションに、共有したいダッシュボードに対応する名前と説明を入力します。
- 次に、AWS SSO SAML メタデータファイル の URL のコピー をクリックし、URL を Cognito コンソールのメタデータドキュメントのエンドポイント URL を入力 に貼り付けます。プロバイダー名フィールドも入力し、Cognito コンソールで アイデンティティプロバイダーを追加 をクリックします。新しいプロバイダーは、フェデレーテッドアイデンティティプロバイダーのサインインセクションに表示されます。
図 8: AWS SSO メタデータドキュメントを読み込むための Cognito の設定
- Cognito コンソールで、作成されたIDプロバイダーを選択し、属性マッピングをクリックします。ID プロバイダーから Cognito に一貫してユーザー ID をマッピングできるように値を追加する必要があります。別の属性を追加 をクリックし、ユーザープール属性と SAML 属性の両方に email を入力します。その後、変更を保存 をクリックします。
図 9: email 属性を利用したユーザー ID
- アプリケーションの統合タブから下にスクロールし、アプリケーションクライアントを作成をクリックして Cognito の設定を継続しアプリクライアントを追加をクリックします。
図 10: CloudWatch ダッシュボードを利用するための新しいアプリクライアントの作成 (1)
図 11: CloudWatch ダッシュボードを利用するための新しいアプリクライアントの作成 (2)
- アプリケーションクライアント名を入力し、残りの設定は変更しないでください。下部のアプリケーションクライアントを作成をクリックして次に進みます。
- ここで、CloudWatch ダッシュボードのサインインとサインアウトの URL をアプリクライアントに伝えます。アプリケーションの統合タブをクリックします。作成したアプリクライアントが表示されますが、まだ使用できる状態にはなっていません。作成したアプリケーションクライアント名を選択し、ホストされた UI の編集から以下の変更を行います。
図 12: アプリクライアントの設定
- 許可されているコールバック URL と許可されているサインアウト URL の両方に、https://cloudwatch.amazonaws.com/dashboard.html を入力します。これらは、ログインまたはログアウトに成功した後、ユーザーがリダイレクトされる場所を示しています。
- ID プロバイダーには手順 7 で作成した ID プロバイダーを指定します。
- OAuth 2.0 権限タイプで認証コード付与を選択します。
- OpenID 接続スコープで OpenID、 aws.cognito.signin.user.admin、Eメールを選択します。
- 以上の設定が終了したら変更を保存をクリックします。
- CloudWatch コンソールに戻り、設定からダッシュボードの共有ページに移動します。利用可能な SSO プロバイダーセクションのリフレッシュアイコンをクリックし、作成された SSO プロバイダーを選択し、変更を保存をクリックします。これで、残りの Cognito ユーザープール の設定がプロビジョニングされ、AWS SSO アプリケーションを確定することができます。
図 13: SSO プロバイダーを CloudWatch にアタッチ
- AWS SSO に対して、SAML アプリケーションを完全に構成するために2つの情報を提供する必要があります。まず、Cognito コンソールで アプリケーションの統合 をクリックします。今までの手順が完了していれば ドメイン名が表示されています。ドメイン名をクリップボードにコピーします。
図 14: 新しく作成されたドメイン名の画面
- AWS SSO コンソールに戻ります。メタデータファイルがない場合は、手動でメタデータ値を入力できます。をクリックします。すると、以下の図のような アプリケーションメタデータセクションが表示されます。
図 15: AWS SSO アプリケーションのアプリケーションメタデータの設定
- 手順 14 でクリップボードにコピーしたドメインの値を AWS SSO コンソールのアプリケーション ACS URL に貼り付けますが、末尾に以下を追加してください:
/saml2/idpresponse
本例のように、SAML プロバイダーで POST バインディングを送信している場合、アプリケーション ACS URL は次のようになります:
https://cw-db-XXX.auth.AWS-REGION-CODE.amazoncognito.com/saml2/idpresponse
- 次に、アプリケーション SAML 対象者を入力します。Cognito コンソールに戻り、作成されたユーザープールをクリックしユーザープール ID をクリップボードにコピーします。
図 16: コンソールから見た Cognito ユーザープール ID の表示例
- 手順 17 でクリップボードにコピーした値を AWS SSO ページの アプリケーション SAML 対象者 フィールドに貼り付けますが、以下のプレフィックスを付けてください:
urn:amazon:cognito:sp:
完成した値は次のようになります:
urn:amazon:cognito:sp:AWS-REGION-CODE_xXXXXXXXX
- CloudWatch コンソールから、共有したいダッシュボードに移動します。各ダッシュボードは、同じアプリケーション ACS URL とアプリケーション SAML 対象者で一意のアプリケーションとして公開できるようになりました。実際のダッシュボードの開始 URL のみ変更する必要があります。対象のダッシュボードに移動し、アクション、ダッシュボードの共有の順にクリックします。
図 17: 共有するダッシュボードの URL の検索
- シングルサインオン (SSO) を使用してアカウントの CloudWatch ダッシュボードを全て共有するから共有可能なリンクをコピーし、AWS SSO コンソールのアプリケーション開始 URL に貼り付けて、変更の保存をクリックします。
また、属性マッピングタブをクリックし、以下を入力します。
この文字列値または AWS SSO のユーザー属性にマッピング: ${user:email}
形式:emailAddress
注:SAML プロバイダーは、ユーザーを CloudWatch ダッシュボードにリダイレクトする際に作成するアサーションで、電子メールを提供します。
図 18: AWS SSO 内でのユーザーのメールアドレスのマッピング
- 最後に、変更の保存をクリックします。 これで設定は完了です!
最後に新しいアプリケーションにユーザーを割り当てる必要があります。一度ユーザーの割り当てが完了すると、ユーザーは AWS SSO ログインページを通じてダッシュボードにアクセスできるようになります。
図 19: AWS SSO ログインページの標準ビュー
まとめ
ユーザーは、公開したダッシュボードを閲覧することができるようになりました。ビジネスユーザーでも、CloudWatch が持つデータをフルに活用することができます。このプラットフォームの利用には、AWS アカウントアクセス、ロールなど、特別な許可は必要なく、企業の ID プロバイダーのユーザーは便利で安全な方法で運用指標、ログ、アラームを利用できるようになります。
図 20: CloudWatch ダッシュボード閲覧時のアニメーション GIF