Datadog Permissions

There are four different permission models in Datadog:

• Role Access - users are assigned roles (without one, they have no permissions), and roles have permissions to an entire class of entity (e.g. Read Users, Write Users, Read Dashboards, Write Dashboards). No resource level permissions can be assigned here.
• Restriction Policies - many, and a growing list, of resources can have restriction policies applied. These granular policies can target specific permissions to very specific groups (offering a resource-specific deny policy). There are precursors for this called "restricted_roles" on some resources (like dashboards and monitors) that should no longer be used.
• Logs Data Access Restriction Queries - logs can be restricted to only be visible to, and their processing rules restricted to certain roles and teams
• Organization Data Access Controls - logs, APM, and RUM data can be restricted to only be visible to, and their processing rules restricted to certain roles and teams

There are four different permission targets in Datadog for Restriction Policies:

• User - all users in Datadog have one or more Roles (and inherit the additive permissions of that role). There is no Deny ability in Datadog roles, but you can manage specific resource permissions (viewer and editor are the most common) using Restriction Policies to grant individual users access to specific resources even though many users have broad permissions through their role
• Role - the most common permission target, a role is configured with a set of permissions to specific functions (not specific resources) and any user assigned this role will have all of the attached permissions
• Team - a user can belong to one or more teams, and restriction policies can target these teams. A common use case might be that all users can read all dashboards, but team members can edit the dashboards belonging to the team.
• Organization - in the event your permission strategy has given all users write access to dashboards, to restrict access to edit a particular dashboard, you must first declare that all organization members are only viewers of this dashboard, and then declare the editor permission for the specific role(s), team(s), or user(s).

Datadog provides three built-in roles (Read, Standard, Admin) but allows you to create your own roles. I highly recommend building your own roles and never using Read or Standard, but your Admin users can just use Admin. A key reason is that when Datadog rolls out new features or permission structures, they will automatically modify the Read and Standard roles without you knowing. By making your own roles, you will explicitly manage when new permissions are given to your users. A few other notes:

• Least Privilege - start with the minimum number of permissions required for your business. No need to allow read access to features that you are not going to use, or if used would incur costs you are not willing to pay for. Users will be less tempted to start shipping data they will never see (although you should still be vigilant about checking Cost and Usage).
• Lockout Prevention - Datadog has an optional mechanism (enabled by default) in place to prevent locking out Admins. If you are sure you know what you're doing, you can allow Admins to lock themselves out of certain resource access.
• Limited Options - Datadog only has the concept of read or edit/manage for most resources (with "run" being the rarely-used 3rd-most common), which encompasses created, edit, and delete functions
• Built-in Profile Edit - Every user can edit their profile, which includes their name and email address. You cannot stop this. This can potentially break observability-as-code functionality if you look up users by email. Tell people not to touch.