Datadog Role permissions
New announcements from Dash: Incident Management, Continuous Profiler, and more! New announcements from Dash!

Datadog Role permissions

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.

Overview

General Permissions

General permissions provide the base level of access for your role. Advanced Permissions are explicitly defined permissions that augment the base permissions.

Permission NameDescription
adminThis permission gives to the role the ability to view and edit everything in your Datadog organization that does not have an explicitly defined permission. This includes billing and usage, user, key, roles, permissions and organization management. This permission is inclusive of all Standard Access permissions.
standardThis permission gives to the role 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.

Note: There is no read-only permission as it is defined by the lack of both the admin and standard permissions for a role.

Advanced Permissions

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.

Dashboards

Find below the list of permissions for the dashboard assets:

NameDescriptionScopable
dashboards_readAbility to view dashboardsfalse
dashboards_writeAbility to create and change dashboardsfalse
dashboards_public_shareAbility to share dashboards externallyfalse

Monitors

Find below the list of permissions for the monitor assets:

NameDescriptionScopable
monitors_readAbility to view monitorsfalse
monitors_writeAbility to change, mute, and delete monitorsfalse
monitors_downtimeAbility to set downtimes for your monitorsfalse

Security Monitoring

Find below the list of permissions for the Security Monitoring assets:

NameDescriptionScopable
security_monitoring_rules_readAbility to view detection rulesfalse
security_monitoring_rules_writeAbility to create, edit, and delete detection rulesfalse
security_monitoring_signals_readAbility to view security signalsfalse

Log Management

Find below the list of permissions for the log configuration assets and log data:

NameDescriptionScopable
logs_read_dataRead access to log datatrue
logs_modify_indexesUpdate the definition of log indexesfalse
logs_write_exclusion_filtersUpdate indexes exclusion filterstrue
logs_write_pipelinesUpdate log pipelinesfalse
logs_write_processorsUpdate the log processors in a pipelinetrue
logs_write_archivesUpdate the external archives configurationfalse
logs_read_archivesSee archive configuration details, access content from the archivetrue
logs_write_historical_viewsRehydrate data from Archivesfalse
logs_public_config_apiAccess the Logs Public Config API (r/w)false
logs_generate_metricsAccess the Generate Metrics featurefalse

Log Management RBAC also includes two legacy permissions, superseded by finer-grained and more extensive logs_read_data permission:

NameDescriptionScopable
logs_live_tailAccess the live tail featurefalse
logs_read_index_dataRead 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.

Log configuration access

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_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.

Note: This permission also grants Logs Read Index Data and Logs Write Exlcusion Filters permissions behind the scenes.

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:

  1. Remove the global permission on the role.
  2. Grant this permission to the role in [the Index page of the Datadog app][2] by editing an index and adding a role to the “Grant editing Exclusion Filters of this index to” field (screenshot below).

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:

  • Setting the name of the pipeline
  • Setting pipelines filters for what logs should enter the processing pipeline
  • Reorder pipelines
  • Granting another role the Logs Write Processors permission, scoped for that pipeline

Note: This permission also grants Logs Write Processors (for all processors on all pipelines) permissions behind the scenes.

logs_write_processors

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,

  • Get the Roles ID of the role you want to assign to specific pipelines.
  • Get the Permission ID for the logs_write_processors permission API for your region.
  • Get the Pipeline ID(s) of the pipeline(s) you want to assign this role on.
  • Grant permission to that role with the following call:

    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>"]
                }
            }'

logs_write_archives

Grants the ability to create, edit or delete Log Archives. This includes:

  • Setting archives filters for what logs should be routed to the archive
  • Setting the name of the archive
  • Reordering archives
  • Restricting the Logs Read Archives permission to a subset of roles.

This permission is global and enables the creation of new archives, and the edition and deletion of 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_view

Grants the ability to write historical views, meaning to trigger a Log Rehydration*.

This permission is global, but only enables to trigger a rehydration for Archives users have Logs Read Archive permission.

logs_public_config_api

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.

Log Data Access

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.

Restrict read access to a subset of logs

This configuration is only supported through the API.

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.

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 users sees 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

Grant this role access to the index in Configuration page.

  • Get the Roles ID of the role you want to assign to specific pipelines.
  • Get the Permission ID for the logs_write_processors permission API for your region.
  • Get the Index ID(s) of the pipeline(s) you want to assign this role on.
  • Grant permission to that role with the following call:

    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>"]
                }
            }'

logs_live_tail

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.

Further Reading


*Log Rehydration is a trademark of Datadog, Inc.