Keeping Sensitive Data Out of Kloudfuse

Telemetry is written by application code, and application code occasionally logs a card number, an access token, or a customer’s email address. The reliable way to keep that data out of your observability platform is to remove it at the point of collection, before it leaves your network. Kloudfuse then lets you authenticate what is sent, restrict who can query it, and record who did.

This page describes the five layers and points to the configuration for each. The collector and query steps apply to any deployment; the default_rbac_policy and audit-log settings are Helm values, so on a Kloudfuse-operated SaaS tenant ask Kloudfuse support to set them.

The Five Layers

Layer What it does Where it runs

Redact at collection

Masks sensitive values before telemetry is transmitted. The original never reaches Kloudfuse.

Datadog Agent or OpenTelemetry Collector, in your network

Detect what got through

A scheduled query applies the Luhn checksum to anything card-shaped in log bodies.

Kloudfuse, as a scheduled search

Authenticate ingest

Only sources holding a valid API key can send data; each key can label the data it admits.

Kloudfuse ingest endpoint

Restrict access

Policies control which streams each user, team, or service account can query, down to the label.

Kloudfuse query layer

Audit access

Audit logs record logins and changes to users, policies, and permissions; performance logs record every query.

Kloudfuse, archivable to object storage

Redact at Collection

Both supported collectors apply regular-expression masking to log lines before batching or transmission. The patterns below are the same in either collector; only the configuration syntax differs.

Add rules under logs_config.processing_rules in datadog.yaml to mask every log source the agent collects:

logs_config:
  processing_rules:
    - type: mask_sequences
      name: mask_credentials
      replace_placeholder: "$1$2[SECRET REDACTED]"
      pattern: "(?i)\\b(password|passwd|secret(?:_?key)?|api[_-]?key|x-api-key|auth(?:oriz(?:ation|ed))?_?token|access_?token|bearer)([\"']?\\s*[:=]\\s*[\"']?)[^\\s,;\"'&}]+"
    - type: mask_sequences
      name: mask_card_numbers
      replace_placeholder: "[CARD REDACTED]"
      pattern: "\\b(?:4\\d{3}|5[1-5]\\d{2}|2(?:22[1-9]|2[3-9]\\d|[3-6]\\d\\d|7[01]\\d|720)|3[47]\\d{2}|30[0-5]\\d|3(?:09|[689]\\d)\\d|6(?:011|5\\d\\d|4[4-9]\\d|22\\d)|35(?:2[89]|[3-8]\\d)|62\\d\\d)(?:[ -]?\\d){9,15}\\b"
yaml

The full rule set, including card security codes and the APM replace_tags companion rules, is in Datadog Agent Log Processing.

Two things to know before you rely on either:

  • Validate patterns against the collector’s own engine. Both collectors compile rules with Go RE2, which has no lookahead or lookbehind. In the Datadog Agent an invalid global rule stops the logs agent from starting, so no logs leave that host until it is fixed.

  • Card-number patterns over-match by design. Any 13–19-digit identifier beginning with a valid card prefix — trace IDs, order numbers — is masked too. That is the right trade-off for cardholder data; scope the rule to payment services if trace correlation matters elsewhere.

Coverage differs by collector for metrics. The OpenTelemetry Collector can rewrite or drop metric attributes with metric_statements in context: datapoint; the Datadog Agent has no equivalent for metric tags or StatsD, so constrain those at the source with a label allowlist. Where you control the application, the OpenTelemetry SDK redacts in-process, before anything is emitted, and covers every signal.

Detect What Got Through

Collection-time masking matches the shape of a card number, so a rule scoped too narrowly lets real cards past. FuseQL’s luhn predicate strips spaces and dashes and validates the checksum, so it returns true only for a number that could be a real card.

Extract anything card-shaped from the log body of the services that handle payments, keep only values that pass the check, and count by service:

source="checkout" OR source="payments"
| parse regex "(?P<candidate>[0-9](?:[ -]?[0-9]){12,18})"
| where luhn(candidate)
| count by service

Save it as a scheduled search with a threshold of zero. Any result names a service whose masking rule needs attention.

The Luhn checksum accepts roughly one in ten random digit strings of card length, and the query only inspects log bodies, not span or metric attributes. Treat a hit as a lead to investigate. With the collector rules in place the expected result is zero.

Authenticate Ingest

Enable API-key authentication so that only sources you have issued a key to can send data to your tenant or cluster. Keys are stored as a SHA-256 hash, can expire, and can be rotated without downtime.

Each key can also attach labels to the data it admits. Issue a dedicated key to the environment that handles regulated data, label its telemetry with it, and the access policies in the next layer can restrict that label to the people who need it.

See Ingestion Authentication with API Key.

Restrict Access

A policy sets, per stream, whether an identity sees all data, none, or only data matching a label filter. The filter is applied before the query reaches the data layer. The Admin role is evaluated first and receives full data access regardless of policy, so keep Admin assignments to the few people who administer the platform and give everyone else Editor or Viewer with a policy.

For environments with strict data isolation, set default_rbac_policy: rbac_allow_none so that a user with no policy sees nothing until one is assigned. Folder permissions separately control which dashboards and alerts each team can view or edit.

See RBAC Policy Management and RBAC Policy Best Practices.

Audit Access

Audit logs record authentication events and changes to users, groups, service accounts, policies, and folder permissions. Performance logs record every query, the query service that served it, and its duration; user_email identifies the user for queries from the UI and from service accounts, and is empty for internal service-to-service calls and alert evaluations. Both are log streams in their own right: query them in the Logs interface, alert on them, and archive them to object storage with an archive rule on their source so a retained copy exists outside the query store.

See Enable Audit and Performance Logs and Configuring Log Archives.

Compliance Frameworks

Under PCI DSS, HIPAA, GDPR, and similar frameworks, an observability platform that holds no regulated data sits outside the set of systems those frameworks govern, and access to what it does hold is expected to follow least privilege and be auditable. Collection-time masking can reduce regulated data reaching the platform, but scope under each framework depends on the complete deployment and should be validated with the appropriate compliance owner. The scheduled luhn search is a limited check for card-shaped values in log bodies; ingest keys, policies, and audit logs provide additional access controls.

Masking is a safety net, not a substitute for not logging the data in the first place. Card security codes and other authentication data must never be retained after authorization; the application must not emit them.