- 필수 기능
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- 디지털 경험
- 소프트웨어 제공
- 보안
- 로그 관리
- 관리
- 인프라스트럭처
- ci
- containers
- csm
- ndm
- otel_guides
- overview
- slos
- synthetics
- tests
- 워크플로
Once you’ve created RBAC roles for logs, assign or remove permissions to the role.
Assign or remove permission to a role directly by updating the role on the Datadog site.
Assign or remove permission to a role directly through the Datadog Permission API.
More details about individual permissions below.
logs_generate_metrics
Grants a role the ability to use the Generate Metrics feature.
This permission is global and enables both the creation of new metrics, and the edition or deletion of existing ones.
logs_write_facets
Grants a role the ability to use the Create, Edit, and Delete facets.
This permission is global and enables both the creation of new facets, and the edition or deletion of existing ones.
logs_modify_indexes
Grants a role the ability to create and modify log indexes. This includes:
This permission is global and enables both the creation of new indexes, and the edition of existing ones.
logs_write_exclusion_filters
Grants a role the ability to create or modify exclusion filters within an index.
This permission can be assigned either globally or restricted to a subset of indexes.
Subset of indexes:
This configuration is only supported through the UI.
logs_write_pipelines
Grants a role the ability to create and modify log processing pipelines. This includes:
logs_write_processors
Grants a role the ability to create, edit, or delete processors and nested pipelines.
This permission can be assigned either globally or restricted to a subset of pipelines.
Assign the role(s) in the Edit
modal of a specific pipeline.
logs_write_processors
permission API for your region.curl -X POST \
https://app.datadoghq.com/api/v2/roles/<ROLE_UUID>/permissions \
-H "Content-Type: application/json" \
-H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>" \
-d '{
"id": "<PERMISSION_UUID>",
"type": "permissions"
}'
logs_write_archives
Grants the ability to create, edit, or delete Log Archives. This includes:
This permission is global and enables creating new archives, and editing and deleting existing ones.
logs_read_archives
Grants the ability to access the details of the archive configuration. In conjunction with Logs Write Historical Views, this permission also grants the ability to trigger a Rehydration from Archives.
This permission can be scoped to a subset of archives. An archive with no restrictions is accessible to anyone who belongs to a role with the logs_read_archives
permission. An archive with restrictions is only accessible to the users who belong to one of the registered roles, provided theses roles have the logs_read_archives
permission.
In the following example, assuming all roles but Guest
have the logs_read_archive
permission:
Guest
role.Customer Support
.Customer Support
, unless they also belong to Audit & Security
.logs_write_historical_views
Grants the ability to write historical views, meaning to trigger a Log Rehydration*.
This permission is global. It enables users to trigger a rehydration for archives on which they have Logs Read Archive permission.
In the example above:
ADMIN
Role members can rehydrate from the Audit Archive
, as they have the Write Historical View (Rehydrate) permission, as well as the Read Archive permission on that archive.AUDIT
Role members cannot rehydrate from the Audit Archive
, as they do not have the Write Historical View (Rehydrate) permission.PROD
Role members cannot rehydrate from the Audit Archive
, as they do not have the Read Archive permission.When assigning team:audit
tags on all logs rehydrated from the Audit Archive
, make sure that Audit
role members who are restricted to read team:audit
logs can only access rehydrated content. For more details on how to add tags and rehydration, see the Log Archive Setup section.
For service:ci-cd
logs that are rehydrated from the Prod Archive
, note the following:
CI-CD
role members.CI-CD
role members, as the resulting historical view is restricted to PROD
and ADMIN
role members.logs_public_config_api
Datadog has removed the logs_public_config_api
permission.
Five separate permissions control the ability to view, create, or modify log configuration through the Datadog API:
Grant the following permissions to manage read access on subsets of log data:
logs_read_data
Read access to log data. If granted, other restrictions then apply such as logs_read_index_data
or with restriction query.
Roles are additive. If a user belongs to multiple roles, the data they have access to is the union of all the permissions from each of the roles.
Example:
service:sandbox
through one role, and is restricted to env:prod
through another role, then the user can access all env:prod
and service:sandbox
logs.To restrict users so they see no more than logs matching a restriction query, use the Data Access page:
This view lists:
Restricted Access
section: all the restriction queries, and what role(s) are attached to them,Unrestricted Access
section: all roles that have log_read_data
permission with no further restrictions,No Access
section: all roles that does not have the log_read_data
permission.Create a new restriction query defining its query filter. The new query appears in the list of restrictions with no role attached to it.
Pick the role wherever it stands, and assign it to the intended restriction query.
Note: Keep in mind that a role can be assigned no more than one restriction query. Meaning, when you assign a role to a restriction query, it loses connection to the restriction query it was already attached to.
Likewise, use the same “Move” interaction to grant Unrestricted Access
to a Role, or conversely to turn it into a No Access
role.
The Data Access page displays a maximum of 50 restriction queries, and 50 roles per section. If you have more roles and restriction queries than the page can display, use the filters to scope this view down:
Revoke or grant this permission from a role with the Roles API. Use Restriction Queries to scope the permission to a subset of Log Data.
These permissions are globally enabled by default for all users.
Logs Read Data permission comes on top of these legacy permissions. For instance, say a user is restricted to the query service:api
.
audit
and errors
indexes, this user only sees service:api
logs within these indexes.service:api
logs in the livetail.logs_read_index_data
Grants a role read access on some number of log indexes. Can be set either globally or limited to a subset of log indexes.
To scope this permission to a subset of indexes, first remove the logs_read_index_data
and logs_modify_indexes
permissions on the role. Then:
Grant this role access to the index in Configuration page.
logs_write_processors
permission API for your region.curl -X POST \
https://app.datadoghq.com/api/v2/roles/<ROLE_UUID>/permissions \
-H "Content-Type: application/json" \
-H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>" \
-d '{
"id": "<PERMISSION_UUID>",
"type": "permissions"
}'
logs_live_tail
Grants a role the ability to use the Live Tail feature.
This permission is global, and grants access to the livetail regardless of Log Read Index Data permission.
Additional helpful documentation, links, and articles: