How do I secure the connection that carries Datadog monitors into Tares?

On a secured Tares instance, you secure the Datadog connection with an ingest-scoped API key that Datadog sends as an Authorization Bearer header. Datadog monitors reach Tares through the webhook connector and a Datadog webhook setup. Tares has no connector of its own for Datadog today.

How it works

The credential you use depends on how data reaches Tares.

• Polled sources. Tares reaches out to the system. A Prometheus source, for example, holds the credentials in its own config: bearer_token, or username and password.
• Pushed sources. The sender reaches Tares. The source has an ingest URL, and on a secured instance the sender must prove who it is. It does this with an ingest-scoped API key sent as Authorization: Bearer <key>. Some senders sign their requests instead, which is the signature option.

Datadog monitors are pushed. A Datadog webhook posts to a Tares webhook source ingest URL, and the Authorization Bearer header is the credential on a secured instance. Datadog authenticates with a header, so you do not configure a signature for it.

Because the credential is a key scoped to ingest, it is for sending events into that connection.

The Alertmanager connector uses the same pattern for a different sender. It adds an ingest-scoped key to the receiver’s http_config. The same kind of key secures both.

Set it up

1. Create the webhook source in Tares. Go to Sources → Add source → webhook. Declare a label for each payload field you want to correlate on, and mark one as primary. On a secured instance, creating a push source in the console mints an ingest-scoped API key for it and shows it once. Copy it then.

   - name: ci-events
     connector: webhook
     config:
       event_type_field: action
       text_template: '{action} by {sender}'
       labels:
         - { name: pipeline, field: pipeline, primary: true }

   Use your own source name and your own payload field names. Keep the Datadog payload flat, because event_type_field and text_template read top-level fields only.

2. Copy the ingest endpoint. The source page shows the ingest URL, which has the form /ingest/ followed by your ingest key.

3. Add the webhook in Datadog. Open the Webhooks integration and add a webhook whose URL is the Tares ingest URL.

4. Write the payload. Build a flat JSON object in the webhook Payload field from Datadog variables such as $ALERT_ID, $EVENT_MSG and $LINK. The shape is yours.

5. Add the credential. In the webhook’s custom headers, written as JSON, add an Authorization header with the value Bearer followed by the ingest-scoped API key from step 1.

6. Call the webhook from a monitor. Put @webhook- followed by your webhook name in the monitor message.

7. Verify. Post a test payload to the ingest URL, then check Recent events. Fields shows which payload fields arrive and how often, so you can pick a reliable key.

   curl -X POST http://localhost:8787/ingest/<ingest_key> \
     -H 'Content-Type: application/json' \
     -d '{"action": "deploy", "sender": "ci", "pipeline": "web"}'

   On a secured instance, a producer sends the ingest-scoped key as Authorization: Bearer <key>, which is the same header Datadog sends.

What you get

• A Datadog webhook that authenticates to Tares with an ingest-scoped API key in the Authorization Bearer header.
• A webhook source whose labels carry the fields from your Datadog payload, with one primary label for the entity.
• Monitor events stored lossless, so the full payload is kept alongside the labels you mapped.
• A clear split of credentials. Polled sources such as Prometheus keep bearer_token or username and password in their config. Pushed sources such as Datadog use an ingest-scoped key or a signature.

When something else fits

• Your alerts already flow through Alertmanager. Use the alertmanager connector. It makes one event per alert and has its own ingest URL. You secure it with the same kind of ingest-scoped key.
• You want Tares to pull from Prometheus. Use a polled Prometheus source and put its credentials in the source config.
• A sender signs its requests. Use a signature instead of a header. Sentry is an example, and Datadog is not.
• Another system posts JSON to Tares. The webhook connector takes any JSON or NDJSON payload from anything that can send an HTTP request.

Related