Overview
The previous sections covered the building blocks of your access strategy: permissions, roles, teams, resource protections, data restrictions, and key management. This section ties them together as a reference for choosing the right enforcement mechanism for a given access need.
Choosing the right mechanism
Use this decision table to determine which access control mechanism to use:
| What you want to control | Example | Mechanism | How it works |
|---|
| Whether a user can use a feature at all | Contractors cannot see any Logs | Permissions and RBAC | Remove the relevant read or write permission from the user’s role. This is an all-or-nothing control per feature. |
| Who can edit or view a specific resource | Only Team A can edit this Dashboard | Granular Access Control | Set Edit, View, or No Access per resource, targeted at Roles, Teams, or individual users. Applied per resource with UI, API, or Terraform. |
| Which telemetry data a user can see | Only the Payments team can see data from service:payment-processor | Data Access Control | Create a restricted dataset defined by tag values and telemetry type. Assign access to specific Roles or Teams. Enforced across the platform wherever that data appears. |
| What an application key can do | This key should only manage monitors, not read logs | Application Key Scoping | Scope the application key to specific API endpoints. The key cannot exceed its creator’s permissions, but can be restricted further. |
| Which networks can access your Datadog org | Only corporate network IPs | IP Allowlist | Restrict access to your Datadog org to specific IP ranges, for both the API and UI. Useful for organizations that require network-level access controls as part of their security posture. |
How the mechanisms layer together
These mechanisms are complementary, not mutually exclusive. A typical enterprise uses several in combination:
- Permissions (RBAC) set the outermost boundary: what features and data types a user can access at all.
- Granular Access Control restricts specific resources: a user may be able to view a Dashboard, but only the owning team can edit it.
- Data Access Control restricts within an allowed data type: a user may have permission to see Logs, but only Logs tagged with their team’s services.
- Application Key Scoping restricts programmatic access: even if a user has broad permissions, their automation key may be scoped to a narrow set of API operations.
- IP Allowlist restricts where access can come from, regardless of who the user is.
Think of these as concentric rings: each layer narrows the access surface further.
Governance and auditing
After your access policies are in place, you need visibility into how they are being used and whether they are working as intended.
Governance Console
The Governance Console provides a centralized view of your organization’s access posture. Use it to identify misconfigurations, track policy coverage, and monitor compliance with your access strategy.
Audit Trail
The Audit Trail records changes to your organization’s configuration, including role assignments, permission changes, resource access modifications, and key management events. Use it to:
- Investigate who changed an access policy and when
- Verify compliance with internal access reviews
- Detect unexpected changes to sensitive configurations
For organizations with external compliance requirements (SOC 2, ISO 27001, HIPAA), Audit Trail provides the evidence trail needed for access reviews and audit processes.
Recommendations
- Use Permissions (RBAC) for broad, feature-level controls. Don’t use RBAC to solve problems that are better handled by Granular Access Control or Data Access Control.
- Use Granular Access Control for resource-level restrictions. If the question is “who can edit this Dashboard?”, granular access is the answer.
- Use Data Access Control for data-level restrictions. If the question is “which data can this user see?”, Data Access Control is the answer.
- Layer mechanisms. A user’s effective access is the intersection of all applicable controls. Design your policies with this in mind.
- Enable Audit Trail and review it periodically, particularly around access-sensitive configurations.
Further reading
Additional helpful documentation, links, and articles:
