DevelopersIO RSS feed【非公式】 on Nostr: 【[アップデート]Amazon Data Firehoseが認証情報をAWS Secrets ...

【[アップデート]Amazon Data Firehoseが認証情報をAWS Secrets Managerより取得できるようになりました】
初めに 先日Amazon Data FirehoseとAWS Secrets Manager統合のリリースがありました。 これまでAmazon Data FirehoseではNew RelicのAPIキー等認証情報を入力するサービスを利用する際その値をFirehose側で直接指定する形となっておりました。 CloudFormation等を利用して構築する際は動的参照を利用することでSecrets Managerの値を参照してデプロイ時に差し替え、Secrets Manager側からのローテーション時のLambda関数処理による差し替えといったことは可能でしたがあくまで外側の仕組みとしてFirehose側の設定値を書き換えるものとなっておりました。 (シークレットの値の変更＋αのαの部分がうまくやればできたけど機能としてのサポートではなかった) 今回のアップデートで認証情報の値直接ではなくシークレットのARNを指定できるようになりFirehose側が必要に応じてSecrets Managerより値を取得するようになったため、＋αの処理なくシークレットの値の変更のみで対応できるようになり秘密情報のローテーションをよりシンプルに実現することができるようになります。 またシークレットの値を直接取り扱わないため設定の変更処理をより安全に実現することも可能となります。 試してみる 今回はCloudFormationを利用して設定してみます。今回はHTTPエンドポイントを利用しますがSecretsManagerConfigrationというパラメータが追加されておりこちらに対して有無効、シークレットのARN、取得に利用するIAMロールの指定をすればよさそうです。 またこの値は従来のアクセスキーの指定同様、リクエスト上のX-Amz-Firehose-Access-Keyヘッダに反映されます。 どのヘッダに利用されるか等は送信先のサービスにより異なるため各種サービスの設定値のドキュメントをご参照ください。 実装 以下のテンプレートで環境を構築します。 シークレットに指定すべき値についてはサービスにより異なりますので利用するサービスに合わせて設定しましょう。今回HTTPエンドポイントの場合はapi_keyがキーとなるJSON値を設定します。 今回は以下のような値となっております。 HTTPエンドポイントの先ではX-Amz-Firehose-Access-Keyヘッダの値をログに出力するようにしておきます。通信はPOSTで来るため受信側でメソッドの判定がある場合は注意しましょう。 動作確認 ストリームにデータを設置するとシークレット上のapi_keyの値が出力されていることが確認できます。 Firehose側に変更が入らないように個別にシークレットの値を送信して再度データし変更されていることを確認します。 https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/using-secrets-manager.html Firehose caches the secrets with an encryption and uses them for every connection to destinations. It refreshes the cache every 10 minutes to ensure that the latest credentials are used. なおFirehoseではシークレットの値を約10分程度キャッシュするため切り替えタイミングと配信タイミング次第で意図せず旧値が混ざってしまう可能性があります。 実際に04:44(UTC)ごろに変更を行いデータの送信を行いましたが04:58頃もキャッシュが残っているためか一発目は古いシークレットが利用されており、その直後から値が切り替わっていることが確認できました。 キャッシュ時間や削除については画面を見る限りでも本日入れたAWS CLIのv1側でもそれっぽい機能は見当たらないためこの辺りの制御は現状できなさそうです。 終わりに シークレットの値を直接参照してくれるようになったことで、必要以上に秘密情報を外側で取り合わずより安全にシンプルに対応できるものとなるアップデートでした。 Firehose側で直接値を持つわけではなくSecrets Manager側を動的に参照するためがシークレット参照による料金発生がある点は注意しましょう。 10分程度キャッシュは行われるため毎回というほどではありませんが、逆にキャッシュしてしまう関係で変更反映にラグができてしまうため送信先で認証情報が一つしか持てない場合は一時的に送信に失敗してしまう可能性があります。 現状この辺りのコントロールができるわけではなさそうなのでローテーションが必要でも場合により別の方法でローテーションした値を直接Firehose側に持たせた方が良い場合もありそうです。 あくまで選択肢が一つ増えたほどで見たいただくのが良いのではないかなと個人的には考えております。
https://dev.classmethod.jp/articles/data-firehose-support-secrets-manager-integration/