Skip to content
Docs menu

Recipes

Ready-to-adapt rules for common needs. Each is a complete fragment for the rules array of your policy file; for the full vocabulary, see Policy authoring.

Allow one package to reach one host

{
  "id": "my-app.allow-dd-trace-apm",
  "subject": { "package": "dd-trace" },
  "target": { "kind": "network", "host": "intake.datadoghq.com" },
  "effect": { "action": "allow" }
}

The standard override for the built-in exposed-outflow rule (Sensitivity and data classes): pin both subject.package and target.host; the user rule wins by specificity.

Allow a package to download in postinstall

Prebuilt-binary fetchers like puppeteer make network calls during their install script, which the built-in lifecycle-network rule blocks. Permit a specific one:

{
  "id": "my-app.allow-puppeteer-install",
  "subject": { "source": "third-party", "package": "puppeteer" },
  "target": { "kind": "network" },
  "when": { "phase": "install" },
  "effect": { "action": "allow" }
}

Take inventory before enforcing

{
  "version": 1,
  "mode": "audit",
  "rules": []
}

Start with an empty rule list in audit mode. Every operation proceeds, every event is recorded. Read the output to learn what your dependencies actually do, then add rules.

Block all outbound network except an allowlist

{
  "version": 1,
  "mode": "enforce",
  "groups": {
    "hosts": {
      "allowed-hosts": { "include": ["api.stripe.com", "db.internal", "*.sentry.io"] }
    }
  },
  "rules": [
    {
      "id": "my-app.allow-known-hosts",
      "subject": { "source": "any" },
      "target": { "kind": "network", "operation": "connect", "hostGroup": "allowed-hosts" },
      "effect": { "action": "allow" }
    },
    {
      "id": "my-app.block-all-other-network",
      "subject": { "source": "any" },
      "target": { "kind": "network", "operation": "connect" },
      "effect": { "action": "block", "severity": "high" }
    }
  ]
}

The more-specific rule (with hostGroup) wins for the allowed hosts; the broader block catches everything else.

CI-only rule

{
  "id": "my-app.audit-env-in-ci",
  "subject": { "source": "any" },
  "target": { "kind": "env" },
  "when": { "ci": true },
  "effect": { "action": "audit", "severity": "medium" }
}

For recipes built on data classes, such as auditing every credential read or blocking exfiltration after a credential is touched, see Sensitivity and data classes.