Security

Security across the telemetry lifecycle, inside your cloud.

The Kloudfuse data plane runs in your VPC. Control what enters the platform, authenticate and encrypt ingest, protect data at rest, enforce fine-grained access policies, audit activity, and selectively delete data when required.

Your VPCCollectredact · drop · shapeIngestauthenticated, encryptedStoreyour object storage, your keysAccessSSO · RBAC · policy filtersAudit and deletelogged, and scrubbableKloudfusecontrol planeoptionalDeployment health only

Security starts with the architecture.

Kloudfuse runs a split architecture. The data plane, meaning ingest, storage, the query engine and the AI runtime, deploys entirely within your own cloud account, reading and writing your object storage under your keys, across multiple availability zones.

Because the platform runs where your data already is, questions about residency, sub-processors and cross-border transfer are answered by your own controls rather than by our attestations.

  • The data plane stays in your environment Ingest, storage, query and the AI runtime all deploy inside your VPC. There is no copy of your telemetry held on our side.
  • Deployment-health monitoring is optional Kloudfuse can optionally monitor the health of your Kloudfuse deployment remotely. It is a choice you make, not a default, and the telemetry data plane remains in your environment either way.
Your cloud accountIngestStorageQuery engineAI runtimeKloudfusecontrol planeoptionalDeployment health only,off unless you enable it
Agent / collectorDatadog agent or OpenTelemetry collectorRedact · Drop · Shape · Relabelwhere supported, before anything is sentAuthenticated ingestAPI key or OAuth2Kloudfuse data planeinside your VPCBrowser telemetry (RUM)Privacy controls are configurable and can be appliedto the browser content and events you need to protect.

Control what enters the platform.

Apply collection-time controls before telemetry is ingested. Redact or drop sensitive fields where supported, shape and relabel telemetry, and authenticate ingestion using scoped credentials.

Handling a field at collection changes what is in scope rather than what is protected, which is a materially different conversation with an auditor.

  • Redaction at collection, where supported log_processing_rules of type mask_sequences on the Datadog agent; OTTL statements such as replace_pattern() and delete_key() in the collector's transform processor.
  • Drop rules exclude_at_match and include_at_match drop or keep whole log sources on the agent. The collector's filter processor drops by severity or pattern.
  • Shaping and relabelling Telemetry can be reshaped and relabelled before it is sent, using agent configuration or the collector's processors.
  • Authenticated ingest A scoped credential, either an API key or an OAuth2 credential token, rather than accepting anything that reaches the address.
Datadog agent · mask a value before it is sent
# conf.d/<source>.d/conf.yaml, or globally under logs_config
log_processing_rules:
  - type: mask_sequences
    name: mask_card_numbers
    replace_placeholder: "[REDACTED]"
    pattern: "\d{13,19}"
OpenTelemetry collector · the same idea, in OTTL
processors:
  transform/mask:
    log_statements:
      - context: log
        statements:
          - replace_pattern(body,
              "password=[^\s&]+", "password=***")

Protected in transit and at rest.

Every endpoint that accepts telemetry encrypts the connection and authenticates the sender. Because the ingest tier runs inside your own VPC, that connection is typically a hop within your own network rather than a crossing of the public internet.

  • TLS on collection endpoints Collection endpoints are configured for HTTPS and TLS.
  • Ingest authentication Incoming telemetry is authenticated and authorised using an API key or an OAuth2 credential token. Those credentials authorise the ingestion pipeline, not people: a compromised agent credential does not become a login.
  • At rest, in your account Data is written to your object storage, under your keys, across multiple availability zones inside your own cloud account.
  • Optional PVC encryption Data-at-rest encryption is available for stateful components. FedRAMP-targeted installations additionally run with EBS encryption.
Agentor collectorTLSCollection endpointAPI key or OAuth2Your object storageyour keys, multi-AZStateful componentsoptional PVC encryption
Access policy · Payments team
Policy filter service =~ "payments-.*" Allow
Assigned to team:payments · svc:billing-etl 2 principals
Role Editor Scoped
Folders Payments dashboards Edit
Everything else default_rbac_policy = rbac_allow_none No access

Representative of the policy screen. Every change here is written to the audit log.

Control who can see what.

Access control answers two separate questions for every request: what telemetry this identity can query, and what content it can see and edit. They are enforced on different paths, so a team can be given dashboards without being given the data behind them.

  • Identity SAML, plus direct integrations with Google OAuth2, Okta and JumpCloud. Local login can be disabled outright so single sign-on is the only route in. Roles can be assigned by hand or synchronised from SSO groups.
  • Roles Three roles, Admin, Editor and Viewer, set platform capability: what an identity can create, edit, delete and administer. Editors and Viewers are governed by policy.
  • Data access, by label filter A Policy resolves to a label filter, and that filter restricts which telemetry streams a Team or Service Account can query. Service accounts are covered by the same mechanism, so an automated pipeline is scoped the same way a person is.
  • Default deny, if you want it The cluster-wide default_rbac_policy decides what happens to an Editor or Viewer with no explicit policy. Set it to rbac_allow_none and access is denied on all streams until a policy grants it, which makes least privilege the default rather than the exception.
  • Content access, by folder Users, Teams, Roles and Service Accounts are granted View, Edit, Admin or No Access on individual folders holding dashboards, alerts and sub-folders, independently of the system role.
  • Auditability Configuration changes and queries are logged, so least privilege is auditable rather than assumed.

Audit activity, and delete what should not be there.

Configuration changes and queries are recorded and queryable alongside everything else, with the same tooling as the rest of your telemetry rather than through a separate export path.

When something sensitive does land, deletion is a supported operation rather than a support ticket.

  • Audit logs Configuration changes and authentication are captured in the audit log. Query activity is recorded separately, with its origin, so security teams have a record of who changed what and who accessed which data.
  • Selective deletion Data scrubbing permanently deletes metrics, events, logs and traces matching a filter, without deleting the dataset around them. It is the right instrument for a subject-access erasure request or for cleaning up after a logging mistake.
  • How scrubbing behaves Scrubbing operates on sealed segments, so it applies to historical data up to the last sealed segment timestamp rather than to a live stream. Deletion is irreversible, which makes filter review the important step.
  • Detect unexpected sensitive data Use FuseQL searches to identify patterns that should not be present, and to validate that your collection-time controls are working. Run as a scheduled search, it turns an annual assumption into a continuous check.
Audit log
Policy updated  payments-read
a.kumar · 14:02
Query  logs, last 14 days
svc:billing · 13:58
Role assigned  Editor → team:payments
a.kumar · 13:41
Dashboard edited  Checkout latency
r.shah · 13:20
Scrub job  filter matched 1,284 records
a.kumar · 11:07

Configuration changes and queries land in the same store as your telemetry, queryable with the same tooling.

BuildSigncosign · KMSVerifypublic keyAdmitor refusePrivate key never leaves KMSSignatures are OCI artifacts stored beside the image

Platform integrity.

Every Kloudfuse container image in ECR is cryptographically signed, and you can verify the signature yourself before anything is deployed into your cluster.

  • Signed images Images are signed with cosign using an AWS KMS key, with signatures stored as OCI artifacts alongside the image. The signing key is asymmetric and the private half never leaves KMS.
  • Verification needs no secret You verify against the public key, derived from the KMS key with read-only access. No credentials are required, so verification can run anywhere, including in a pipeline that holds nothing of ours.
  • Enforced in the cluster Signature verification can be made an admission requirement, so an unsigned or altered image cannot run. The documentation includes a Kyverno policy for exactly that.
  • Patching Regular release cycles address CVEs and apply security patches, with the contents documented in the release notes.

Compliance and assurance.

Because deployment happens inside your own VPC, residency and data-handling requirements are governed by your controls rather than ours. These three groups are deliberately distinct: an independent attestation, a cryptographic validation and a framework we help you meet are not the same kind of claim.

Independent assurance

SOC 2 Type IICurrent
ISO/IEC 27001:2022Current
Penetration testUnder NDA

Cryptographic validation

FIPS 140-3Validated

CMVP certificates #5186 and #5209

Compliance support

GDPRSupported

Erasure via scrubbing; data stays in your region

PCI DSSIn progress

Collection-time controls and detection

HIPAAIn progress

Questions security teams ask.

Does Kloudfuse ever hold our telemetry?
The data plane, meaning ingest, storage, query and the AI runtime, runs inside your own cloud account, writing to your object storage under your keys. Separately, and only if you enable it, Kloudfuse can monitor the health of your Kloudfuse deployment remotely. The telemetry data plane stays in your environment either way.
Where should we handle sensitive data?
As early as you can. Redacting or dropping a field at collection changes what is in scope rather than what is protected, which is a materially different conversation with an auditor. Use scrubbing for what gets through, and a scheduled FuseQL search to tell you whether anything is getting through at all.
Can we disable password login entirely?
Yes. Local authentication can be turned off so SSO is the only route in. SAML is supported generically, with direct integrations for Google OAuth2, Okta and JumpCloud.
How do we handle an erasure request?
Data scrubbing permanently deletes matching telemetry by filter. It operates on sealed segments, so it covers historical data rather than a live stream, and it cannot be undone, so review the filter before running it.
Can a team be limited to only its own services?
Yes. Policy filters constrain which telemetry a user or team can query, on top of role-based permissions and folder-level access, so a team sees the data it is responsible for rather than everything in the platform.
What happens to our data if we stop using Kloudfuse?
It is already in your bucket. The platform is built on OpenTelemetry, so your instrumentation is portable and your history stays where it is written. There is no export step because there was never an export.
Can we get the SOC 2 report and the penetration test?
Under NDA. Ask your account contact, or start from the Trust Center for current certificate status.

Bring your security review. We'll bring the architecture.

Run Kloudfuse against your own telemetry, in your own cloud, and walk your security team through where the data sits and who can reach it.