QuickSight のデータソース接続構成に AWS Secrets Manager が使えるようなりました

いわさです。

API だけ更新されていてまだアップデート履歴が出ていないのですが、どうやら QuickSight でデータストアを構成する際に Secrets Manager を使えるようになったようです。

本日はこれまでどういう状況だったのかを確認と、新しい機能を試した結果を共有したいと思います。
今回の機能は QuickSight でもセキュリティのベストプラクティスを適用しやすくなるアップデートなので、運用環境でご利用されている方は是非ご検討ください。

いままで

前提の知識として、QuickSight で「ダッシュボード」を作成するためには「分析」を作成する必要があります。
また、「分析」を作成するためには「データセット」を作成する必要があります。
そして「データセット」を作成する際には「データストア」を構成します。

S3 などをデータストアに指定する場合は QuickSight が利用するロールが対象の S3 バケットへ接続出来るようになっていればよく IAM ロールのみでセキュアに構成することが出来ます。
一方で RDS を始めとするデータベースへ接続する際には以下のように接続情報を指定する必要があり、これまではホスト名、ユーザー名、パスワードをデータストア作成時に指定する必要がありました。

データストアで認証情報を含めて指定を行うことで以下のように分析上へ表示することが出来ていました。

しかし、固定で接続情報を指定しているのでこれまで以下の問題を抱えていました。

• データストアを構成するためにユーザー名とパスワードを扱う必要がある
• Secrets Manager のローテーションが利用出来ない

試したことが無いですが、おそらくこれまでは Secrets Manager のシークレットから秘匿情報を取得し API を使ってデータストアを構成する仕組みをカスタム作成することでどうにか実現出来ていたというところではないでしょうか。

当然ながら、それらを設定せずに Secrets Manager で RDS のパスワードをローテーションしてしまうと以下のように SPICE の更新に失敗してしまいます。

AWS CLI で設定出来る

本日時点では AWS CLI の v1.25.90 から設定が出来るようになっています。

create-data-sourceで新規構成出来ますが、update-data-sourceなども対応しているため既存のデータストアも Secrets Manager の利用へ切り替えが可能です。
また、マネジメントコンソールからの新規構成は本日は出来ませんがそのうち出来るようになると思います。試したことを後述します。

既に RDS の接続情報を Secrets Manager で管理している前提で設定を行ってみます。

まず QuickSight の実行ロールが Secrets Manager へアクセス出来る必要があります。
これは QuickSight の管理設定から対象のシークレットへのアクセス許可を行う必要があります。

アクセス許可が出来てればあとは構成を行うだけです。
credentialsでSecretsArnを指定します。

% uuidgen                               
755C3D60-4917-48D9-A4BD-93C1721580DD

% aws-v1 quicksight create-data-source \
    --aws-account-id 123456789012 \
    --data-source-id 755C3D60-4917-48D9-A4BD-93C1721580DD \
    --name hoge1008rdssecret \
    --type MYSQL \
    --data-source-parameters '{"RdsParameters": {"InstanceId":"hoge1008mysql","Database":"hoge"}}' \
    --credentials '{"SecretArn":"arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:hoge1008secret-FWOuJo"}' \
    --permissions '[
            {
                "Principal": "arn:aws:quicksight:ap-northeast-1:123456789012:user/default/cm-iwasa.takahito/cm-iwasa.takahito",
                "Actions": [
                    "quicksight:UpdateDataSourcePermissions",
                    "quicksight:DescribeDataSourcePermissions",
                    "quicksight:PassDataSource",
                    "quicksight:DescribeDataSource",
                    "quicksight:DeleteDataSource",
                    "quicksight:UpdateDataSource"
                ]
            }
        ]' \
    --profile hoge
{
    "Status": 202,
    "Arn": "arn:aws:quicksight:ap-northeast-1:123456789012:datasource/755C3D60-4917-48D9-A4BD-93C1721580DD",
    "DataSourceId": "755C3D60-4917-48D9-A4BD-93C1721580DD",
    "CreationStatus": "CREATION_IN_PROGRESS",
    "RequestId": "f48266ed-e9e6-40ad-9877-7eb4b290fc20"
}

上記実行時にpermissionsを指定していることにご注意ください。
こちらを実行しないと作成したデータストアが、データセット作成時に表示されず利用が出来ません。
このあたりの権限周りは QuickSight 利用の最初は戸惑いますが「なんか表示されねえな...」と思ったらまず権限を疑いましょう。

ユーザー ID やパスワードをデータストアに設定していませんが上記のようにデータセット、データストアを作成後に分析にデータベースから SPICE へ取り込んだ情報を表示出来ることが確認出来るはずです。

もちろんローテーションも出来る

Secrets Manager でしかも RDS であればポチポチっと設定するとパスワードのローテーションが出来るようになります。
今回の昨日によって QuickSight でもパスワードローテーションに対応したので確認してみましょう。

手動ローテーション実行後に古いパスワードが使えないことを確認します。

% mysql -h hoge1008mysql.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -u admin -p hoge
Enter password: 
ERROR 1045 (28000): Access denied for user 'admin'@'i223-217-77-3.s41.a001.ap.plala.or.jp' (using password: YES)

では QuickSight でデータセットを更新してみましょう。
Secrets Manager を構成する前のデータセットではローテーション後は SPICE 更新ができなくなっていましたね。
果たして...

SPICE の更新に成功しました！
パスワードローテーションに追従出来ていますね、素晴らしいです。

ちなみに CloudTrail で確認すると、QuickSight が GetSecret していることが確認出来ます。

AWS CLI で設定したあとであればマネジメントコンソールでも確認出来る

本日時点でマネジメントコンソールでは新規構成が（私の環境では）出来なかったのですが、先程の手順で AWS CLI でデータストアを構成後にデータストアの編集画面を開くと、なんと以下のようにマネジメントコンソールでもこの機能を確認出来るようになっています。

部分的に新機能がロールアウトされてる感じですかね...QuickSight はアップデート情報が先行して、マネジメントコンソールで利用出来るまでは少しタイムラグがあることが多いので、気長に待ちましょう、いずれ使えるようになるはずです！

さいごに

本日は QuickSight のデータソース接続構成でついに AWS Secrets Manager が使えるようなったとのことで確認してみました。

秘匿情報の所有者を Secrets Manager のみにして、さらに定期的なローテーションに追従することも出来るようになりました。
QuickSight で今までこれを行う場合はちょっと頑張らないといけない感じだったと思いますがセキュリティのベストプラクティスに標準機能で対応出来るようになりました。

閲覧者に変化の出る目立つアップデートではないですが、運用視点で見ると非常に重要なアップデートではないでしょうか。
現在ユーザー名とパスワードで管理されている方は是非見直しをご検討ください。