Amazon QuickSight Author 権限で自己プロビジョニングできるスイッチロール用の IAM ロールを CloudFormation で作成してみた

Amazon QuickSight Author 権限で自己プロビジョニングできるスイッチロール用の IAM ロールを CloudFormation で作成してみた

2025.07.25

はじめに

Amazon QuickSight の Author 権限を持つユーザーが自己プロビジョニングできるスイッチロール用の IAM ロールを最小権限で作成したい。そう考えながら検証した成果物を CloudFormation テンプレートにしましたのでご紹介します。

概要

IAM ユーザーが MFA 認証後にスイッチロールします。その後、QuickSight の Author 権限で自己プロビジョニングができ、ダッシュボードの作成ができるようになります。

この方法で QuickSight の管理者の作業負荷を軽減したいという私の願いから生み出されました。

QS-Auther-Role.png

Author 権限でできること

QuickSight 上のユーザー管理や SPICE 容量追加などの操作には Admin 権限が必要です。ダッシュボードの作成であれば Author 権限で十分です。

QuickSight の Author 権限では以下の操作が可能です。

  • 分析(ダッシュボード)の作成・編集・削除
  • データセットの作成・編集・削除
  • 自身のユーザープロビジョニング
    • quicksight:CreateUserのアクションが許可されていれば

Amazon QuickSight アカウント/ユーザー管理におけるポイント

引用: https://pages.awscloud.com/rs/112-TZM-766/images/[第一部]AmazonQuickSightアカウントユーザー管理におけるポイント_1014.pdf

実装方法

IAM ポリシーの作成

IAM ポリシーは複数の IAM ロールで使い回すことを想定しています。そのため、別途作成します。

author-policy.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudFormation template to create IAM policy for QuickSight user creation'

Resources:
  QuickSightAutherPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: quicksight-auther
      Description: 'IAM policy to allow QuickSight Auther user creation'
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - quicksight:CreateUser
            Resource: !Sub 'arn:aws:quicksight::${AWS::AccountId}:user/${!aws:userid}'

補足

最小権限かつ、リソースの制限をした上で検証した結果、以下の IAM ポリシーに落ち着きました。

セッションタイトル.png
引用: Amazon QuickSight における シングルサインオンの設計と実装

IAM ロールの作成

複数の IAM ユーザーからスイッチロール可能な IAM ロールテンプレートを作成します。セキュリティ強化のため MFA 認証を必須としています。スイッチロール元の AWS アカウントをTrustedAWSAccountIdとして入力してください。

CloudFormation_-_スタックの作成.png

author-role.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: Template for Creating IAM Role to Switch from AWS Account

Parameters:
  IAMUserName:
    Type: String
    Description: IAM Role Name
  TrustedAWSAccountId:
    AllowedPattern: "^[0-9]*$"
    Type: String
    Description: Trusted Account ID

Resources:
  IAMRoleForQuickSightAuther:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          Effect: "Allow"
          Action: "sts:AssumeRole"
          Principal:
            AWS: !Sub 'arn:aws:iam::${TrustedAWSAccountId}:user/${IAMUserName}'
          Condition:
            Bool:
              aws:MultiFactorAuthPresent: 'true'
      ManagedPolicyArns:
        - !Sub 'arn:aws:iam::${AWS::AccountId}:policy/quicksight-auther'
      RoleName:
        !Sub
          - ${IAMUserName}-QuickSightAuther
          - {IAMUserName: !Ref IAMUserName}

動作確認

自己プロビジョニングの実行

スイッチロール後、QuickSight コンソールにアクセスすると自己プロビジョニングが可能になります。メールアドレスを入力して「続行」をクリックすると、Author 権限のユーザーが作成されます。

Provide_Email.png

分析の作成

プロビジョニング完了後、分析の作成や編集が可能になります。CSV をアップロードしてデータセットを作成し、グラフを作成できることを確認しました。

網走観光名所ダミーデーター_-_シート1__1__csv_analysis.png

ダッシュボードの公開

問題なくダッシュボードの作成もできました。

テストダッシュボード-2.png

まとめ

QuickSight の Author 権限で自己プロビジョニングを実現する方法を紹介しました。メリットは、管理者の作業負荷を軽減、ユーザーが必要なタイミングでログインして、プロビジョニングできることです。QuickSight のユーザー管理を効率化したい方の参考になれば幸いです。

おわりに

QuickSight のユーザー管理する私の負荷を軽減しつつ、最小権限にするための試行錯誤していました。

IAM ポリシーでquicksight:CreateUserのアクションを許可していても、Resourceの制限を誤ると以下のエラーが出力されます。エラーメッセージからの切り分けが難しかったです。

Provide_Email-2.png

自己プロビジョニングでは上記のエラーがでないものの、プロビジョニング後に QuickSight 画面を開けないこともありました。こちらについては 15 分ほど時間をおいてから画面を更新かけたら QuickSight 画面を開くことができました。IAM ポリシーまた違うのかと切り分けていたのですが、時間が解決するオチでした。

HTTPステータス_500_–_Internal_Server_Error.png

思いの外ハマり、複数の QuickSight ユーザーを作成して検証することになり利用費もかかりました。同じことしたい方が時間とお金を節約できるように書き残しました。

この記事をシェアする

facebookのロゴhatenaのロゴtwitterのロゴ

© Classmethod, Inc. All rights reserved.