Once your roles are created, assign or remove permission to this role directly by updating the role in the Datadog application, or through the Datadog Permission API. Find below a list of available permissions.
General permissions provide the base level of access for your role. Advanced Permissions are explicitly defined permissions that augment the base permissions.
Name | Description | Scopable |
---|---|---|
admin | This permission gives you the ability to view and edit everything in your Datadog organization that does not have an explicitly defined permission. This includes billing and usage, key, and organization management. This permission is inclusive of all Standard access permissions. | false |
standard | This permission gives you the ability to view and edit components in your Datadog organization that do not have explicitly defined permissions. This includes APM, Events, and other non-Account Management functionality. | false |
Note: There is no read-only
permission as it is defined by the lack of both the admin
and standard
permissions for a role.
By default, existing users are already associated with one of the three out-of-the-box Datadog Admin, Standard, or Read-Only Roles, so all users already have permissions to read all data types, and Admin or Standard users already have write permissions on assets.
Note: When adding a new custom role to a user, make sure to remove the out-of-the-box Datadog role associated with that user in order to enforce the new role permissions.
In addition of the general permissions, it is possible to define more granular permissions for specific assets or data types. Permissions can be either global or scoped to a subset of elements. Find below the details of these options and the impact they have on each available permission.
Find below the list of permissions for the api and application keys assets:
Name | Description | Scopable |
---|---|---|
user_app_keys | The ability to view and manage Application Keys owned by the user. | false |
org_app_keys_read | The ability to view Application Keys owned by all users in the organization. | false |
org_app_keys_write | The ability to manage Application Keys owned by all users in the organization. | false |
api_keys_read | The ability to list and retrive the key values of all API Keys in your organization. | false |
api_keys_write | The ability to create, rename, and revoke API Keys for your organization. | false |
Find below the list of permissions for the apm assets:
Name | Description | Scopable |
---|---|---|
apm_read | The ability to read and query APM and Trace Analytics. | false |
apm_retention_filter_read | The ability to read trace retention filters. A user with this permission can view the retention filters page, list of filters, their statistics, and creation info. | false |
apm_retention_filter_write | The ability to create, edit and delete trace retention filters. A user with this permission can create new retention filters, and update or delete to existing retention filters. | false |
apm_service_ingest_read | The ability to access Service Ingestion pages. A user with this permission can view the service ingestion page, list of root service, their statistics, and creation info. | false |
apm_service_ingest_write | The ability to edit Service Ingestion pages root services. A user with this permission can edit the root service ingestion and generate a code snippet to increase ingestion per service. | false |
apm_apdex_manage_write | The ability to set Apdex T value on any service. A user with this permission can set the T value from the Apdex graph on the service page. | false |
apm_tag_management_write | The ability to edit second primary tag selection. A user with this permission can modify the second primary tag dropdown in the APM settings page. | false |
apm_primary_operation_write | The ability to edit the operation name value selection. A user with this permission can modify the operation name list in the APM settings page and can modify the operation name controller on the service page. | false |
Find below the list of permissions for the dashboards assets:
Name | Description | Scopable |
---|---|---|
dashboards_read | The ability to view dashboards. | false |
dashboards_write | The ability to create and change dashboards. | false |
dashboards_public_share | The ability to share dashboards externally. | false |
Find below the list of permissions for the integrations assets:
Name | Description | Scopable |
---|---|---|
integrations_api | The ability to use the Integrations APIs to configure Integrations that the user has access to. This permission does not restrict or grant access to Integrations. | false |
Find below the list of permissions for the metrics assets:
Name | Description | Scopable |
---|---|---|
metric_tags_write | The ability to edit and save tag configurations for custom metrics. | false |
Find below the list of permissions for the monitors assets:
Name | Description | Scopable |
---|---|---|
monitors_read | The ability to view monitors. | false |
monitors_write | The ability to change, mute, and delete individual monitors. | false |
monitors_downtime | The ability to set downtimes for your organization. A user with this permission can suppress alerts from any monitor using a downtime, even if they do not have permission to edit those monitors explicitly. | false |
Find below the list of permissions for the real user monitoring assets:
Name | Description | Scopable |
---|---|---|
rum_apps_write | The ability to create, edit, and delete RUM Applications. | false |
Find below the list of permissions for the security monitoring assets:
Name | Description | Scopable |
---|---|---|
security_monitoring_rules_read | The ability to read Detection rules. | false |
security_monitoring_rules_write | The ability to create and edit Detection rules. | false |
security_monitoring_signals_read | The ability to view Security signals. | false |
Find below the list of permissions for the user access assets:
Name | Description | Scopable |
---|---|---|
user_access_invite | Allows users to invite other users to your organization. | false |
user_access_manage | Grants the permission to disable users, manage user roles and SAML-to-role mappings. | false |
Find below the list of permissions for the log configuration assets and log data, along with the typical category of user you’d assign this permission to. See the recommendations on how to assign permissions to team members in the Logs RBAC guide.
Name | Description | Scopable |
---|---|---|
logs_modify_indexes | The ability to read and modify all indexes in your account. This includes the ability to grant the Logs Read Index Data and Logs Write Exclusion Filter permission to other roles, for some or all indexes. This permission also grants global Log Index Read and Log Exclusion Filter Write implicitly. | false |
logs_write_exclusion_filters | The ability to add and change exclusion filters for all or some log indexes. Can be granted in a limited capacity per index to specific roles via the Logs interface or API. If granted from the Roles interface or API, the permission has global scope. | true |
logs_write_pipelines | The ability to add and change log pipeline configurations, including the ability to grant the Logs Write Processors permission to other roles, for some or all pipelines. This permission also grants global Log Processor Write implicitly. | false |
logs_write_processors | The ability to add and change some or all log processor configurations. Can be granted in a limited capacity per pipeline to specific roles via the Logs interface or API. If granted via the Roles interface or API the permission has global scope. | true |
logs_write_archives | The ability to add and edit log archive locations. | false |
logs_public_config_api | The ability to access and edit logs configurations via the API. | false |
logs_generate_metrics | The ability to create custom metrics from logs. | false |
logs_read_data | The ability to read log data. Can be restricted with restriction queries. | true |
logs_read_archives | The ability to read logs archives location and use it for rehydration. | true |
logs_write_historical_view | The capability to rehydrate logs from Archives. | false |
logs_write_facets | The capability to create or edit logs facets. | false |
Log Management RBAC also includes two legacy permissions, superseded by finer-grained and more extensive logs_read_data
permission:
Name | Description | Scopable |
---|---|---|
logs_live_tail | Access the live tail feature | false |
logs_read_index_data | Read a subset log data (index based) | true |
Once your roles are created, assign or remove permission to this role directly by updating the role in the Datadog application.
Once your roles are created, assign or remove permission to this role directly through the Datadog Permission API.
More details about these permissions below.
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.
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.
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.
Note: This permission also grants Logs Read Index Data and Logs Write Exlcusion Filters permissions behind the scenes.
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.
Grants a role the ability to create and modify log processing pipelines. This includes:
Note: This permission also grants Logs Write Processors (for all processors on all pipelines) permissions behind the scenes.
Grants a role the ability to create, edit or delete processors and nested pipelines12.
This permission can be assigned either globally or restricted to a subset of pipelines.
Assign the role(s) in the modal of a specific pipeline.
Preliminary,
logs_write_processors
permission API for your region.curl -X POST \
https://app.datadoghq.com/api/v1/role/<ROLE_UUID>/permission/<PERMISSION_UUID> \
-H "Content-Type: application/json" \
-H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>" \
-d '{
"scope": {
"pipelines": [ "<PIPELINE-X_ID>", "<PIPELINE-Y_ID>"]
}
}'
Grants the ability to create, edit or delete Log Archives. This includes:
This permission is global and enables the creation of new archives, and the edition and deletion of existing ones.
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
.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.Grants the ability to create or modify log configuration through the Datadog API:
The Log Public Configuration API permission only grants the permission to operate actions through API. For instance, a user without Log Write Exclusion Filter Permission cannot update sampling rate through API, even if granted The Log Public Configuration API permission.
Grant the following permissions to manage read access on subsets of log 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 in the Datadog App to:
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.
This page won’t display more than 50 restriction queries at once, and more than 50 roles per section. In case you have hundreds if not thousands of roles and restriction queries, use the filters to scope this view down:
Revoke or grant this permission from a role via 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.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/v1/role/<ROLE_UUID>/permission/<PERMISSION_UUID> \
-H "Content-Type: application/json" \
-H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>" \
-d '{
"scope": {
"indexes": ["<INDEX-1_ID>",["<INDEX-2_ID>"]
}
}'
Grants a role the ability to use the Live Tail feature.
This permission is global, and grants access to the livetail irregardless of Log Read Index Data permission.
Additional helpful documentation, links, and articles: