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:
Remove the global permission on the role.
Grant this permission to the role in the Index page on the Datadog site by editing an index and adding a role to the “Grant editing Exclusion Filters of this index to” field.
This configuration is only supported through the UI.
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:
Staging is accessible to all users, except users that only belong to the Guest role.
Prod is accessible to all users belonging to Customer Support.
Security-Audit is not accessible to users who belong to Customer Support, unless they also belong to Audit & Security.
Proceed to archive creation, or update at any moment while editing the archive.
Use the Logs Archive API either to assign or revoke a role from a given Archive.
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:auditlogs 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:
If you do not use the Log Read Index Data legacy permission, these logs are accessible for CI-CD role members.
If you do use the Log Read Index Data legacy permission, these logs are not accessible for CI-CD role members, as the resulting historical view is restricted to PROD and ADMIN role members.
Removed: 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 (Recommended) offers finer grained access control by restricting a role’s access to logs matching a log restriction queries.
Logs Read Index Data is the legacy approach to restrict data access to indexed log data on a per-index basis (it is still required to have this permission enabled to access indexed 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:
If a user belongs to a role with log read data and also belongs to a role without log read data, then they have the permission to read data.
If a user is restricted to 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:
Assign one or multiple roles to that restriction query.
Check what roles and users are assigned to which restriction queries.
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 restriction query
Create a new restriction query defining its query filter. The new query appears in the list of restrictions with no role attached to it.
Assign a role to a restriction query
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.
Check restriction queries
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:
with the restriction query filter:
with the role filter:
with the user filter, which is a convenient way to see what a specific user belonging to multiple roles actually has access to:
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.
Legacy permissions
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.
If this user has scoped Read Index Data permission on audit and errors indexes, this user only sees service:api logs within these indexes.
If this user has livetail permission, this user only sees 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:
