概要
ログには、スクラブされるか組織内の権限のあるユーザーのみがアクセスできる機密データが含まれている場合があります。また、コンフィギュレーションと予算管理に関する限り、ユーザーが互いに干渉しないようにユーザーをセグメント化することもできます。
このガイドでは、ユーザーが準拠した方法でログとログ機能にアクセスするための、カスタマイズされた Datadog ロールを開発する方法を紹介します。
複数のチーム
組織が複数のチームで構成されていると想定します。その 1 つが ACME (Applicative Component Making Errors) チームで、そのメンバーはトラブルシューティングと監査の目的で ACME Logs を処理します。
このガイドでは、ACME チームに次の 2 つのカテゴリのユーザーがいることも前提としています。
ACME Admin
: ACME ログ収集、パイプライン、除外フィルターを担当するユーザーのロール。ACME User
: ユーザーが ACME ログにアクセスし、このログからモニターまたはダッシュボードを作成するためのロール。
注: このガイドは、シンプル化のために 1 つの ACME ロール (ACME 管理者と ACME ユーザーの両方からのアクセス許可を集中させる) に適合させることも、より詳細なアクセス許可のためにより多くのロールに適合させることもできます。
このガイドは ACME チームに焦点を当てていますが、セットアップは組織内の他のすべてのチームに複製できます。ACME チームのメンバーは、組織全体の他のチームのメンバーになることも可能です。Datadog ではアクセス許可は付加的であり、マルチチームユーザーは、所属先のすべてのチームから継承されたアクセス許可の結合から利益を得ることができます。
Datadog 管理者のロール
このガイドでは、Datadog 管理者が ACME チームメンバーが (他のチームログに干渉することなく) ログを操作するための安全なプレイグラウンドをセットアップし、これらのログへのアクセスを ACME ユーザーのみに制限する方法について説明します。
注: このガイドを適応させて、ACME 管理者が Datadog 管理者でもあると見なすことができます。
このガイドでは、以下について説明します。
- 管理者の前提条件。
- ACME チームのロールの設定とメンバーの割り当て: ロールを設定する。
- 制限クエリを使用した、Datadog アプリケーション全体のログへのアクセスの制限: ログへのアクセスを制限する。
- ログアセット (つまり、パイプライン、インデックス、アーカイブ) のアクセス許可の構成: ログアセットへのアクセスを制限する。
前提条件
受信ログにタグを付ける
ACME の受信ログに team:acme
タグを付けます。これは、ログが Datadog を通過するときにログをトリアージするのに役立ちます。
たとえば、Docker ログコレクションのコンテキストでは、タグとしての Docker ラベルを持つそのコンテナから流れるログに team:acme
タグをアタッチします。より一般的な概要については、タグ付けセクションを参照してください。
Datadog 管理者としてログインする
このガイドのその他のアクションを実行するには、ユーザーアカウントに Datadog Admin または同等のロールが必要です。以下の権限が必要になります。
Users list で、これらすべてのアクセス許可があることを確認してください。不足しているものがある場合は、Datadog 管理者ユーザーに設定を依頼してください。
API キーとアプリキーを取得する
注: このセクションは、管理者ユーザーからの API キーとアプリケーションキーが必要な Datadog API を使用する場合にのみ必要です。
API キーとアプリキーは、Datadog アカウント API キーページで入手できます。詳細については、ドキュメントの API キーとアプリキーセクションをご覧ください。
使用するアプリキーが、自分のユーザーまたは同様のアクセス許可を持つユーザーにアタッチされていることを確認してください。
このガイドをとおして、<DATADOG_API_KEY>
および <DATADOG_APP_KEY>
はそれぞれご使用中の Datadog API キーおよび Datadog アプリケーションキーに置き換えて進めてください。このガイドでは、CURL
を備えた端末があることも前提としています。
アクセス許可 ID を取得する
注: このセクションは、Datadog API を使用して RBAC をセットアップする場合にのみ必要です。
Permissions API を使用して、既存のすべてのアクセス許可のリストを取得します。答えは、次のような一連のアクセス許可です (logs_read_data
アクセス許可には <PERMISSION_ID>
1af86ce4-7823-11ea-93dc-d7cad1b1c6cb
があり、そのアクセス許可について知っておく必要があるのはこれだけです)。
curl -X GET "https://app.datadoghq.com/api/v2/permissions" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>"
[...]
{
"type": "permissions",
"id": "1af86ce4-7823-11ea-93dc-d7cad1b1c6cb",
"attributes": {
"name": "logs_read_data",
"display_name": "Logs Read Data",
[...]
}
}
[...]
注: アクセス許可 ID は、使用している Datadog サイト (Datadog US、Datadog EU など) によって異なります。
ロールを設定する
このセクションでは、ACME Admin
と ACME User
の 2 つのロールを作成する方法、両方のロールに最小限のログアクセス許可を付与する方法 (このガイドの後半で拡張)、ユーザーにどちらかのロールを割り当てる方法について説明します。
ロールを作成
Datadog オーガニゼーションの設定の Groups Section で、Role タブの Add Role ボタンを使用して、新しい ACME Admin
と ACME User
のロールを作成します。
新しいロールを作成する場合
- 標準アクセスで作成します。
- Read Index Data と Live Tail のアクセス許可を付与します。これらは、安全に有効にできるレガシーアクセス許可です。
ロールの作成の詳細については、アカウントの管理セクションを参照してください。
ACME Admin
と ACME User
のロールについて、次の手順を繰り返します。
- ロールがまだ存在しない場合は、Role Creation API でロールを作成します。次の例では、
dcf7c550-99cb-11ea-93e6-376cebac897c
がロール ID です。
curl -X POST "https://app.datadoghq.com/api/v2/roles" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type": "roles","attributes": {"name": "ACME Admin"}}}'
[...]
"type": "roles",
"id": "dcf7c550-99cb-11ea-93e6-376cebac897c",
"attributes": { "name": "ACME Admin", [...] }
[...]
- または、ロールがすでに存在する場合は、Role List API を使用してそのロール ID を取得します。
curl -X GET "https://app.datadoghq.com/api/v2/roles?page[size]=10&page[number]=0&sort=name&filter=ACME" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>"'
[...]
"type": "roles",
"id": "dcf7c550-99cb-11ea-93e6-376cebac897c",
"attributes": { "name": "ACME Admin", [...] }
[...]
- ロールの既存のアクセス許可を確認します (新しく作成されたロールの Read Monitors と Read Dashboards のみが必要です)。
curl -X GET "https://app.datadoghq.com/api/v2/roles/<ROLE_ID>/permissions" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>"
- Grant Permissions API を使用して、
standard
、logs_read_index_data
、logs_live_tail
アクセス許可をロールに割り当てます。対応する ID を取得するには、アクセス許可 ID を取得するセクションを参照してください。
curl -X POST "https://app.datadoghq.com/api/v2/roles/<ROLE_ID>/permissions" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type":"permissions","id": "<PERMISSION_ID>"}}'
- 必要に応じて、Revoke Permissions API を使用して他のすべてのログアクセス許可を取り消します。
curl -X DELETE "https://app.datadoghq.com/api/v2/roles/<ROLE_ID>/permissions" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type":"permissions","id": "<PERMISSION_ID>"}}'
ユーザーをロールにアタッチする
ロールがアクセス許可で構成されたので、これらのロールをユーザーに割り当てます。
Datadog の Team Section で、User タブに移動します。ユーザーを選択し、すでに割り当てられている可能性のあるロールに加えて、ACME Admin
または ACME User
のロールを割り当てます。ユーザー管理の詳細については、アカウントの管理セクションをご覧ください。
List Users API を使用して、ACME Admin
または ACME User
ロールのいずれかに割り当てるユーザーのユーザー ID を取得します。この API はページ区切りされているため、たとえば、ユーザーの姓をクエリパラメーターとして使用して、結果をフィルタリングする必要がある場合があります。次の例では、ユーザー ID は 1581e993-eba0-11e9-a77a-7b9b056a262c
です。
curl -X GET "https://api.datadoghq.com/api/v2/users?page[size]=10&page[number]=0&sort=name&filter=smith" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>"
[...]
"type": "users",
"id": "1581e993-eba0-11e9-a77a-7b9b056a262c",
"attributes": {
"name": "John Smith",
"handle": "john.smith@company.com",
[...]
},
[...]
ユーザーを ACME ロールにアタッチする
ユーザーごとに、Assign Role API を使用して、これをこのロールに追加します。
curl -X POST "https://api.datadoghq.com/api/v2/roles/<ROLE_ID>/users" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type":"users","id":"<USER_ID>"}}'
デフォルトのロールからユーザーを削除する
ユーザーがすでにロールとその ID を持っているかどうかを確認します。これらのユーザーからデフォルトの Datadog ロールを削除したい場合があります。これは、付与したくないユーザーに追加のアクセス許可を付与する可能性があるためです。
curl -X DELETE "https://api.datadoghq.com/api/v2/roles/<ROLE_ID>/users" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type":"users","id":"<USER_ID>"}}'
ログへのアクセスを制限する
このセクションでは、ACME チームメンバー (ACME Admin
と ACME User
の両方のメンバー) に team:acme
ログへのアクセスを付与する (team:acme
ログのみ) 方法について説明します。制限クエリでスコープされた Log Read Data アクセス許可を使用します。
粒度を最大限に高め、メンテナンスを容易にするために推奨されるのは、アクセスできるログを増やすために ACME ユーザーのアクセスを拡張しないことです。他のロールを同じ team:acme
制限クエリに制限するよりも、各ユーザーが個別にアクセスする必要があるものに基づいて、ユーザーを複数のロールに割り当てることを検討してください。
このセクションでは、次の方法について詳しく説明します。
team:acme
制限クエリを作成する。- その制限クエリを ACME ロールにアタッチする。
注: ロールには、制限クエリを 1 つだけアタッチできます。制限クエリをロールにアタッチすると、このロールにすでにアタッチされている制限クエリがすべて削除されます。
Create Restriction Query API を使用して、新しい制限クエリを作成します。制限クエリ ID (次の例では 76b2c0e6-98fa-11ea-93e6-775bd9258d59
) を追跡します。
curl -X POST "https://app.datadoghq.com/api/v2/logs/config/restriction_queries" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type": "logs_restriction_queries","attributes": {"restriction_query": "team:acme"}}}'
{
"data": {
"type": "logs_restriction_queries",
"id": "76b2c0e6-98fa-11ea-93e6-775bd9258d59",
"attributes": {
"restriction_query": "team:acme",
"created_at": "2020-05-18T11:26:48.887750+00:00",
"modified_at": "2020-05-18T11:26:48.887750+00:00"
}
}
}
次に、Restriction Query API を使用して、前の制限クエリを ACME ロールにアタッチします。ACME Admin
および ACME User
ロール ID を使用してこの操作を繰り返します。
curl -X POST "https://app.datadoghq.com/api/v2/logs/config/restriction_queries/<RESTRICTION_QUERY_ID>/roles" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type": "roles","id": "<ROLE_ID>"}}'
最後に、Grant Permissions API を使用してロールの logs_read_data
アクセス許可を有効にします。アクセス許可 ID を取得するセクションを参照して、このアクセス許可に対応する ID を取得してください。
curl -X POST "https://app.datadoghq.com/api/v2/roles/<ROLE_ID>/permissions" -H "Content-Type: application/json" -H "DD-API-KEY: <DATADOG_API_KEY>" -H "DD-APPLICATION-KEY: <DATADOG_APP_KEY>" -d '{"data": {"type":"permissions","id": "<PERMISSION_ID>"}}'
オプションで、セットアップが適切に行われていることを確認します。
ログアセットへのアクセスを制限する
このセクションでは、ACME Admin
ロールメンバーに ACME ログアセット (つまり、ログパイプライン、ログインデックス、ログアーカイブ) を操作するためのアクセス許可を付与する方法について詳しく説明します。
これにより、次のことが保証されます。
ACME Admin
メンバー (ACME Admin
メンバーのみ) が、ACME ログアセットを操作できる。ACME Admin
と ACME User
のどちらのメンバーも、他のチームのアセットに干渉できない。ACME Admin
と ACME User
のどちらのメンバーも、どのログがアセットに流れ込むか、予算制限、ログアクセス制限ルールなどの上位レベルの「管理者」コンフィギュレーションに干渉できない。
粒度を最大限に高め、メンテナンスを容易にするために推奨されるのは、ACME ログアセットを編集するアクセス許可を他のロールに付与しないことです。代わりに、(一部の) ユーザーを対象の他のロールから ACME Admin
ロールにも追加することを検討してください。
ログパイプライン
team:acme
ログ用に 1 つのパイプラインを作成します。Write Processor アクセス許可を ACME Admin
のメンバーに割り当てますが、そのアクセス許可をこの ACME「ルート」パイプラインにスコープします。
ログインデックス
team:acme
ログ用に 1 つまたは複数のインデックスを作成します。ACME チームがきめ細かい予算管理を必要とする場合、複数のインデックスが役立つ場合があります (たとえば、保持が異なるインデックス、またはクオータが異なるインデックス)。Write Exclusion Filters アクセス許可を ACME Admin
のメンバーに割り当てますが、そのアクセス許可をこれらの ACME インデックスにスコープします。
ログアーカイブ
アーカイブを読み取る
team:acme
ログ用に 1 つまたは複数のアーカイブを作成します。Read Archives アクセス許可を ACME Admin
のメンバーに割り当てますが、その ACME アーカイブにスコープします。
ログに応じてライフサイクルポリシーが異なる場合、複数のアーカイブが役立つ場合があります (たとえば、本番ログとステージングログ)。一度に複数のアーカイブで複数のリハイドレートをトリガーできますが、リハイドレートは一度に 1 つのアーカイブに対してのみ機能することを目的としていることに注意してください。
履歴ビューを書き込む
ACME Admin
のメンバーに Write Historical View アクセス許可を割り当てます。このアクセス許可は、リハイドレートを実行する能力を付与します。
オプションで、ログアーカイブを設定して、そのアーカイブからリハイドレートされたすべてのログに、アーカイブにタグがあるかどうかに関係なく、最終的に team:acme
タグが付けられるようにします。このオプションを使用すると、既存の制限ポリシーとの整合性を確保できるだけでなく、Datadog に流れないログや Datadog でインデックス付けされていないログに対応する非推奨の制限を安全に削除できます。
注: Legacy Read Index Data Permission を使用する場合、ACME Admin
ロールと一緒に ACME User
ロールを ACME アーカイブに追加してください。ACME User
ロールメンバーにはリハイドレートを実行するアクセス許可がないため、これによって機密性の高いアクセス許可が付与されることはありません。ただし、これにより、Read Index Data アクセス許可が結果の履歴ビューに自動的にスコープされるため、コンテンツにアクセスできます。
参考資料