Datadog Hardening Guide

Security Last updated: 2025-02-05

Observability platform hardening for Datadog including SAML SSO, role-based access control, and organization security settings

Product Docs API Docs Hardening Guide

Code Packs: Terraform

Overview

Datadog is a leading observability and security platform used by thousands of organizations for infrastructure monitoring, APM, log management, and security monitoring. As a platform with access to sensitive operational data and infrastructure metrics, Datadog security configurations directly impact data protection and operational security.

Intended Audience

Security engineers managing observability platforms
IT administrators configuring Datadog
DevOps teams securing monitoring infrastructure
GRC professionals assessing observability security

How to Use This Guide

L1 (Baseline): Essential controls for all organizations
L2 (Hardened): Enhanced controls for security-sensitive environments
L3 (Maximum Security): Strictest controls for regulated industries

Scope

This guide covers Datadog organization security including SAML SSO, role-based access control, API key management, and session security.

Authentication & SSO
Access Controls
API & Key Security
Monitoring & Compliance
Compliance Quick Reference

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	6.3, 12.5
NIST 800-53	IA-2, IA-8

Description

Configure SAML SSO to centralize authentication for Datadog users.

Rationale

Why This Matters:

Centralizes identity management
Enables enforcement of organizational MFA policies
Simplifies user lifecycle management
Required for SAML strict mode

Prerequisites

Datadog Administrator access
SAML 2.0 compatible identity provider
IdP admin credentials

ClickOps Implementation

Step 1: Access SAML Configuration

Navigate to: Organization Settings → Login Methods
Click on SAML settings
Enable SAML configuration

Step 2: Configure Identity Provider

Create SAML application in IdP:
- Active Directory
- Auth0
- Google
- LastPass
- Microsoft Entra ID
- Okta
- SafeNet
Configure required attributes

Step 3: Upload IdP Metadata

Download IdP metadata XML
Upload to Datadog SAML settings
Verify configuration

Step 4: Configure Datadog Settings

Datadog supports HTTP-POST binding
NameIDPolicy format: emailAddress
Assertions must be signed

Time to Complete: ~1 hour

Code Pack: Terraform

hth-datadog-1.01-configure-saml-sso.tf View source on GitHub ↗

# Enable SAML SSO for the Datadog organization
resource "datadog_organization_settings" "saml_sso" {
  name = "HTH Hardened Organization"

  settings {
    saml {
      enabled = true
    }

    saml_autocreate_users_domains {
      enabled = length(var.saml_autocreate_users_domains) > 0
      domains = var.saml_autocreate_users_domains
    }

    saml_idp_initiated_login {
      enabled = true
    }
  }
}

1.2 Enable SAML Strict Mode

Profile Level: L2 (Hardened)

Framework	Control
CIS Controls	6.3
NIST 800-53	IA-2

Description

Require SAML authentication for all users.

ClickOps Implementation

Step 1: Navigate to Login Methods

Navigate to: Organization Settings → Login Methods
Review enabled authentication methods

Step 2: Configure Strict Mode

Set Password login: Disabled
Set Google login: Disabled
Set SAML login: Enabled by Default

Step 3: Configure User Overrides

Allow per-user overrides if needed
Configure individual exceptions carefully

Code Pack: Terraform

hth-datadog-1.02-enable-saml-strict-mode.tf View source on GitHub ↗

# Enforce SAML strict mode -- disables password and Google login
# Only applied at profile level 2 (Hardened) and above
resource "datadog_organization_settings" "saml_strict" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "HTH Hardened Organization"

  settings {
    saml {
      enabled = true
    }

    saml_strict_mode {
      enabled = var.saml_strict_mode_enabled
    }

    saml_autocreate_users_domains {
      enabled = length(var.saml_autocreate_users_domains) > 0
      domains = var.saml_autocreate_users_domains
    }

    saml_idp_initiated_login {
      enabled = true
    }
  }
}

1.3 Configure Session Security

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	6.2
NIST 800-53	AC-12

Description

Configure session timeout and security settings.

ClickOps Implementation

Step 1: Configure Session Duration

Navigate to: Organization Settings → Security
Set Maximum session duration
Applies to all new web sessions

Step 2: Configure Idle Timeout

Enable Idle time session timeout
Users signed out after 30 minutes inactivity

Code Pack: Terraform

hth-datadog-1.03-configure-session-security.tf View source on GitHub ↗

# Configure session security via security monitoring rule that detects
# sessions exceeding the configured idle timeout.
#
# NOTE: Datadog does not expose session timeout as a direct Terraform resource.
# Session duration is configured via Organization Settings in the UI.
# This rule monitors for sessions that exceed the idle timeout threshold
# and alerts the security team for investigation.
resource "datadog_security_monitoring_rule" "session_idle_timeout_violation" {
  name    = "[HTH] Session Idle Timeout Violation Detected"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Session Idle Timeout Violation

    A user session has been active beyond the configured idle timeout
    of ${var.session_idle_timeout_minutes} minutes.

    **Recommended Action:**
    - Review session in Organization Settings > Security
    - Verify idle timeout is set to ${var.session_idle_timeout_minutes} minutes
    - Investigate if the session was legitimately active

    **HTH Control:** 1.3 Configure Session Security
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "session_violation"
    query           = "source:audit @evt.name:session @duration:>${var.session_idle_timeout_minutes}m"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Session idle timeout exceeded"
    status    = "medium"
    condition = "session_violation > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 900
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:1.3", "level:L1"]
}

2. Access Controls

2.1 Configure Role-Based Access Control

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	5.4
NIST 800-53	AC-6

Description

Implement least privilege using Datadog’s RBAC model.

ClickOps Implementation

Step 1: Review Managed Roles

Navigate to: Organization Settings → Roles
Review default managed roles:
- Admin: Full access
- Standard: Read/write on assets
- Read Only: Read data only

Step 2: Create Custom Roles

Click Create Role
Configure specific permissions
Pay attention to sensitive permissions

Step 3: Review Sensitive Permissions

Sensitive permissions are flagged in UI
Review carefully before assigning

Code Pack: Terraform

hth-datadog-2.01-configure-rbac.tf View source on GitHub ↗

# Look up the built-in Datadog Read Only role for reference
data "datadog_role" "read_only" {
  filter = "Datadog Read Only Role"
}

# Look up the built-in Datadog Standard role for reference
data "datadog_role" "standard" {
  filter = "Datadog Standard Role"
}

# Look up the built-in Datadog Admin role for reference
data "datadog_role" "admin" {
  filter = "Datadog Admin Role"
}

# Create custom least-privilege roles from variable definitions
resource "datadog_role" "custom" {
  for_each = var.custom_roles

  name = each.value.name

  dynamic "permission" {
    for_each = each.value.permissions
    content {
      id = permission.value
    }
  }
}

# Security monitoring rule: detect admin role assignments
resource "datadog_security_monitoring_rule" "admin_role_assignment" {
  name    = "[HTH] Admin Role Assigned to User"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Admin Role Assignment Detected

    A user has been assigned the Datadog Admin role. Admin access should
    be limited to 2-3 users per the principle of least privilege.

    **Recommended Action:**
    - Verify the assignment was authorized
    - Confirm the user requires full admin access
    - Consider using a custom role with fewer permissions

    **HTH Control:** 2.1 Configure Role-Based Access Control / 2.2 Limit Admin Access
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "admin_assignment"
    query           = "source:audit @evt.name:role @action:modified @role.name:\"Datadog Admin Role\""
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Admin role assigned"
    status    = "high"
    condition = "admin_assignment > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:2.1", "control:2.2", "level:L1"]
}

2.2 Limit Admin Access

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	5.4
NIST 800-53	AC-6(1)

Description

Minimize and protect administrator accounts.

ClickOps Implementation

Step 1: Inventory Admin Users

Navigate to: Organization Settings → Users
Filter by Admin role
Document all admin accounts

Step 2: Apply Least Privilege

Limit Admin to 2-3 users
Remove unnecessary admin access
Use custom roles for specific needs

3. API & Key Security

3.1 Secure API Keys

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	3.11
NIST 800-53	SC-12

Description

Secure Datadog API keys used for data ingestion.

ClickOps Implementation

Step 1: Review API Keys

Navigate to: Organization Settings → API Keys
Review all existing keys
Identify purpose of each key

Step 2: Implement Key Management

Create purpose-specific keys
Name keys descriptively
Remove unused keys

Step 3: Secure Key Storage

Store keys in secret manager
Use environment variables
Never commit to code

Code Pack: Terraform

hth-datadog-3.01-secure-api-keys.tf View source on GitHub ↗

# Create purpose-specific API keys with descriptive names.
# Each key should map to a single use case (e.g., prod-agent, staging-agent).
resource "datadog_api_key" "managed" {
  for_each = toset(var.api_key_names)

  name = each.value
}

# Security monitoring rule: detect API key creation or deletion
resource "datadog_security_monitoring_rule" "api_key_lifecycle" {
  name    = "[HTH] API Key Created or Deleted"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## API Key Lifecycle Event

    An API key was created or deleted. All API key changes should be
    authorized and documented per key management policy.

    **Recommended Action:**
    - Verify the change was authorized
    - Confirm the key name follows naming conventions
    - Update key inventory documentation
    - Ensure unused keys are revoked

    **HTH Control:** 3.1 Secure API Keys
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "api_key_change"
    query           = "source:audit @evt.name:api_key @action:(created OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "API key lifecycle event"
    status    = "medium"
    condition = "api_key_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:3.1", "level:L1"]
}

3.2 Secure Application Keys

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	3.11
NIST 800-53	SC-12

Description

Secure application keys used for API access.

ClickOps Implementation

Step 1: Review Application Keys

Navigate to: Organization Settings → Application Keys
Application keys inherit user permissions

Step 2: Configure Key Scopes

Create keys with limited scopes
Grant minimum required permissions

Step 3: Rotate Keys Regularly

Establish rotation schedule (90 days)
Update integrations before deleting

Code Pack: Terraform

hth-datadog-3.02-secure-application-keys.tf View source on GitHub ↗

# Create purpose-specific application keys with descriptive names.
# Application keys inherit the permissions of the user who creates them.
# Use service accounts with limited roles for automation keys.
resource "datadog_application_key" "managed" {
  for_each = toset(var.app_key_names)

  name = each.value
}

# Security monitoring rule: detect application key creation or deletion
resource "datadog_security_monitoring_rule" "app_key_lifecycle" {
  name    = "[HTH] Application Key Created or Deleted"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Application Key Lifecycle Event

    An application key was created or deleted. Application keys inherit
    the permissions of the creating user, so changes must be carefully
    controlled. Keys should be rotated every 90 days.

    **Recommended Action:**
    - Verify the change was authorized
    - Confirm the key is tied to an appropriate service account
    - Check that the owning user has minimal required permissions
    - Update key rotation schedule

    **HTH Control:** 3.2 Secure Application Keys
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "app_key_change"
    query           = "source:audit @evt.name:application_key @action:(created OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Application key lifecycle event"
    status    = "medium"
    condition = "app_key_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:3.2", "level:L1"]
}

4. Monitoring & Compliance

4.1 Configure Audit Logs

Profile Level: L1 (Baseline)

Framework	Control
CIS Controls	8.2
NIST 800-53	AU-2

Description

Monitor administrative and security events.

ClickOps Implementation

Step 1: Access Audit Trail

Navigate to: Organization Settings → Audit Trail
Review logged events

Step 2: Configure Alerts

Create monitors for audit events
Alert on sensitive operations

Step 3: Export Logs

Export audit logs for retention
Integrate with SIEM

Code Pack: Terraform

hth-datadog-4.01-configure-audit-logs.tf View source on GitHub ↗

# Monitor for organization settings changes (security-critical events)
resource "datadog_security_monitoring_rule" "org_settings_changed" {
  name    = "[HTH] Organization Settings Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## Organization Settings Modified

    A change was detected to Datadog organization settings. This includes
    changes to authentication methods, security settings, and access controls.

    **Recommended Action:**
    - Review the specific setting that was changed
    - Verify the change was authorized via change management
    - Check if the change impacts security posture
    - Document in change log

    **HTH Control:** 4.1 Configure Audit Logs
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "org_change"
    query           = "source:audit @evt.name:org_settings @action:modified"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "Organization settings modified"
    status    = "high"
    condition = "org_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L1"]
}

# Monitor for user access changes (invitation, role change, removal)
resource "datadog_security_monitoring_rule" "user_access_changed" {
  name    = "[HTH] User Access Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## User Access Modified

    A user was invited, had their role changed, or was removed from the
    Datadog organization. User access changes should follow the principle
    of least privilege.

    **Recommended Action:**
    - Verify the user access change was authorized
    - Confirm the assigned role follows least privilege
    - Update user access inventory
    - Review if the user needs a custom role instead

    **HTH Control:** 4.1 Configure Audit Logs
    **Profile Level:** L1 (Baseline)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "user_change"
    query           = "source:audit @evt.name:user @action:(created OR modified OR deleted)"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "User access modified"
    status    = "medium"
    condition = "user_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L1"]
}

# L2: Monitor for SAML configuration changes
resource "datadog_security_monitoring_rule" "saml_config_changed" {
  count   = var.profile_level >= 2 ? 1 : 0
  name    = "[HTH] SAML Configuration Modified"
  enabled = true
  type    = "log_detection"

  message = <<-EOT
    ## SAML Configuration Modified

    A change was detected to the SAML/SSO configuration. Unauthorized
    changes to SAML settings can enable authentication bypass attacks.

    **Recommended Action:**
    - Immediately verify the change was authorized
    - Check if SAML strict mode is still enabled
    - Verify IdP metadata has not been tampered with
    - Review login methods for unauthorized additions

    **HTH Control:** 4.1 Configure Audit Logs (SAML monitoring)
    **Profile Level:** L2 (Hardened)

    ${length(var.audit_alert_recipients) > 0 ? join(" ", var.audit_alert_recipients) : ""}
  EOT

  query {
    name            = "saml_change"
    query           = "source:audit @evt.name:saml @action:modified"
    aggregation     = "count"
    group_by_fields = ["@usr.email"]
  }

  case {
    name      = "SAML configuration modified"
    status    = "critical"
    condition = "saml_change > 0"
  }

  options {
    detection_method       = "threshold"
    evaluation_window      = 300
    keep_alive             = 3600
    max_signal_duration    = 86400
    decrease_criticality_based_on_env = false
  }

  tags = ["source:hth", "control:4.1", "level:L2"]
}

5. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID	Datadog Control	Guide Section
CC6.1	SSO/SAML	1.1
CC6.2	RBAC	2.1
CC6.6	Session security	1.3
CC6.7	Key security	3.1
CC7.2	Audit logging	4.1

NIST 800-53 Rev 5 Mapping

Control	Datadog Control	Guide Section
IA-2	SSO	1.1
AC-6	Least privilege	2.1
SC-12	Key management	3.1
AU-2	Audit logging	4.1

Appendix A: References

Official Datadog Documentation:

API & Developer Documentation:

Compliance Frameworks:

SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, ISO 27701 — via Trust Center
HIPAA-compliant Log Management available
CSA Security, Trust & Assurance Registry (STAR) registered
Annual penetration testing by NCC Group

Security Incidents:

No major public security incidents identified affecting the Datadog platform directly.

Changelog

Date	Version	Maturity	Changes	Author
2025-02-05	0.1.0	draft	Initial guide with SSO, RBAC, and key security	Claude Code (Opus 4.5)

Contributing

Found an issue or want to improve this guide?

Report outdated information: Open an issue with tag content-outdated
Propose new controls: Open an issue with tag new-control
Submit improvements: See Contributing Guide

Datadog Hardening Guide

Overview

Intended Audience

How to Use This Guide

Scope

Table of Contents

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Description

Rationale

Prerequisites

ClickOps Implementation

1.2 Enable SAML Strict Mode

Description

ClickOps Implementation

1.3 Configure Session Security

Description

ClickOps Implementation

2. Access Controls

2.1 Configure Role-Based Access Control

Description

ClickOps Implementation

2.2 Limit Admin Access

Description

ClickOps Implementation

3. API & Key Security

3.1 Secure API Keys

Description

ClickOps Implementation

3.2 Secure Application Keys

Description

ClickOps Implementation

4. Monitoring & Compliance

4.1 Configure Audit Logs

Description

ClickOps Implementation

5. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

NIST 800-53 Rev 5 Mapping

Appendix A: References

Changelog

Contributing