Datadog サービスアカウントのアプリケーションキーでAWS インテグレーションを設定する

こんにちは、なおにしです。

Datadog のサービスアカウントで作成したアプリケーションキーを使用してAWS インテグレーションを設定する機会がありましたのでご紹介します。

はじめに

Datadog を利用する際、監視対象からのデータ送信ではAPI キー、Datadog 自体の操作をAPI 経由で行う場合にはAPI キーと併せてアプリケーションキーを使用します(OAuth 経由もパターンとしてはありますが本記事では割愛します)。

https://docs.datadoghq.com/ja/account_management/api-app-keys/

API キーはDatadog 組織に紐づきますが、アプリケーションキーは作成した個人ユーザーに紐づきます。

したがって、アプリケーションキーを作成したユーザーが異動や退職となり、Datadog 組織上で対象ユーザーアカウントが無効化された場合、紐づくアプリケーションキーは失効(削除)となります。

一方、AWS インテグレーションを設定する場合、ガイドページに遷移するためのAdd AWS Account(s)ボタンを押下したタイミングで、操作しているユーザーに紐づくアプリケーションキーが作成されています。

キー名はAWS Integrations - Datadog Managedで登録されます。操作しているユーザーが初めて上記ボタンを押下した時に作成され、以降は同じアプリケーションキーが使用されます。もし当該キーを削除した場合はまた同じタイミングで再作成されますが、もちろんキーは新しくなります。

そのままAWS インテグレーションの設定ガイドページに進むと、CloudFormation 等のテンプレートに設定するパラメータを指定する画面になります。ですが、この画面にはアプリケーションキーを選択する箇所がありません。

API キーを選択してOpen in AWS Consoleボタンを押下すると、CloudFormation のスタック作成画面に遷移します。以下のとおり、アプリケーションキーは入力されている状態になります。

DatadogApiKeyの説明には先ほどの挙動が明記されています。

If this template was launched from the Datadog app, this key is tied to the user that launched the template, and is a key specifically generated for this integration.

(和訳)
このテンプレートがDatadogアプリから起動された場合、このキーはテンプレートを起動したユーザーに紐づけられ、このインテグレーション専用に生成されたキーです。

そもそもですが、ログをDatadog に転送するためのDatadog Forwarder を使用しない場合、用途から考えるとAPI キーとアプリケーションキーの両方とも不要なのでは？となるはずです。

Datadog がAWS インテグレーションを用いてメトリクスを取得する標準的な方法は、CloudWatch API のポーリングです。実際、先ほどのガイドページでSend AWS Logs to Datadog内のDeploy log forwarderを無効にした場合、API キーとアプリケーションキーのいずれもSecrets Manager のシークレットやSSM のパラメータストアにクレデンシャルとして保存されることはなく、CloudFormation のNoEcho として保存されるのみです。

したがって、CloudFormation スタックの作成/変更/削除のタイミングでのみ使用されるパラメータと考えれば良さそうです。では、具体的に何に使用されているのかというと、Datadog がCloudFormation スタックのデプロイ状況をチェックするために使用されているようです。

先ほどのガイドページの末尾にはDeployment Statusという項目があります。例えば、Open in AWS Consoleボタンを押してしばらくすると、以下のようにタイムアウト状態になります。

さらにCloudFormation テンプレートを確認したところ、スタック作成のタイミングだけではなく削除のタイミングでもAPI キー/アプリケーションキーを使用してDatadog のAPI を呼び出しているようです。挙動からするとおそらくはAWS インテグレーションの管理画面で以下のように登録されている対象アカウントを削除するために利用されているものかと思います。

上記の登録はDatadog 側からも削除可能であるため、CloudFormation スタックのデプロイ時に使用したアプリケーションキーが使用できなくなったとしても実害は無いと思いますが、チームでDatadog 組織を管理しており、異動/退職が発生する可能性のある環境なのであれば、使用するアプリケーションキーは個人に紐づくものではない方が良さそうです。

前置きが長くなりましたが、前述のような背景を踏まえ、Datadog のサービスアカウント機能を利用してAWS インテグレーションを設定してみます。

https://docs.datadoghq.com/ja/account_management/org_settings/service_accounts/

サービスアカウントは、チーム全体で共有されるアプリケーションキーやその他のリソースを所有するために使用できる非インタラクティブなアカウントです。サービスアカウントのアプリケーションキーは、キーを作成した本人が一度だけ閲覧することができます。

あなたの会社の社員が、個人のアプリケーションキーを使って Datadog API にリクエストを送信する自動スクリプトをセットアップしたとします。その社員が退社すると、その社員の Datadog アカウントを無効化し、そのアプリケーションキーは機能しなくなります。自動化されたスクリプトも、誰かが有効なアプリケーションキーで更新するまで、動作しなくなります。Datadog API への自動リクエストに個人のアプリケーションキーの代わりにサービスアカウントのアプリケーションキーを使用することで、この問題を回避することができます。

やってみた

事前準備

サービスアカウントに設定するカスタムロールを追加しておきます。必要な権限が明記されているわけではないので、AWS インテグレーションに関連するものを付与する形にします。

サービスアカウントの作成

[Organization Settings] - [Service Accounts] の画面から以下のようにサービスアカウントを追加します。

先ほど作成したカスタムロールをアタッチします。

サービスアカウントを作成しても指定したメールアドレスにメールは送信されず、メールアドレスの検証といった操作も特にありませんでした。作成されたサービスアカウントを選択すると、アプリケーションキーを作成することができます。

New Keyからアプリケーションキーを作成します。

作成されたアプリケーションキーはこのタイミングでしか取得できないため控えておく必要があります。

アプリケーションキーを作成すると、サービスアカウントで指定したメールアドレスにメールが送信されます。

アプリケーションキーの一覧画面でも作成されたことが確認できます。

対象のアプリケーションキーを選択しても、先ほどの注意表示のとおりキー自体は再取得できません。

なお、Datadog ユーザーに紐づくアプリケーションキーなら自身が発行したものについては再取得可能です。

AWS インテグレーションの設定

AWS インテグレーション設定のガイドページからCloudFormation スタックを作成します。API キーについてはDatadog Forwarder での使用などを想定すると、実際に設定する場合は対象のAWS アカウントごとに新規作成するのがベターかと思います。

スタック作成画面で、アプリケーションキーを先ほどサービスアカウントで作成したキーに置き換えます。

スタックの作成が完了すると、以下のようにDatadog 上でのステータスが更新されます。View Integrationボタンから作成されたAWS インテグレーション設定を確認できます。

補足：Datadog ユーザーを無効化すると対象ユーザーが作成したアプリケーションキーは削除されます

実際にDatadog ユーザーの無効化/有効化の操作をしてアプリケーションキー失効の挙動を確認してみます。

アプリケーションキーを準備します。

ユーザーが有効な状態では、curl コマンドによって以下のようにダッシュボード一覧を取得するAPI を実行可能です。ダッシュボードを作成していなければ{"dashboards":[]}という応答があります。

export DD_API_KEY="<your-api-key>"
export DD_APP_KEY="<your-app-key>"
export DD_SITE="datadoghq.com"

curl -s -X GET "https://api.${DD_SITE}/api/v1/dashboard" \
-H "DD-API-KEY: ${DD_API_KEY}" \
-H "DD-APPLICATION-KEY: ${DD_APP_KEY}"

ユーザーを無効化します。アプリケーションキーが失効することは注意書きとしても表示されていることが分かります。

ユーザーを無効化すると、アプリケーションキーはリストに表示されなくなりました。

上記の状態で先ほどのコマンドを実行すると{"errors":["Forbidden"]}という応答がありました。

ユーザーを有効化します。

アプリケーションキーの表示は復活せず、先ほどのcurl コマンドの応答も{"errors":["Forbidden"]}となりました。したがって、ドキュメントやUIでの警告表示にあるRevokeという記載については、挙動としてはユーザーの無効化と同時にアプリケーションキーは削除となりますのでご注意ください。

まとめ

直近でDatadog の組織運用を検討する必要があり、API キー/アプリケーションキーの役割やサービスアカウントの使い所に関して整理するにあたって今回の内容をまとめてみました。個人での検証や一時的な利用目的でない限り、アプリケーションキーを発行する際はサービスアカウントを使用する方が良さそうと感じました。

本記事がどなたかのお役に立てれば幸いです。