Monoscope -- Security¶

Identity and access control, data protection, network security, and threat model considerations for Monoscope (the open-source observability platform with BYOS storage).

Identity & Access¶

RBAC (Role-Based Access Control)¶

Monoscope provides project-level RBAC. Each project acts as a tenant boundary with its own API key, S3 partitioning, and access controls.

Role	Permissions
Owner	Full project control: manage members, configure alerts, modify retention, delete data
Admin	Manage dashboards, monitors, alert channels; cannot delete the project or manage billing
Member	View dashboards, query telemetry, acknowledge alerts; cannot modify project settings
Viewer	Read-only access to dashboards and queries; no alert management

Roles are assigned at the project level. A user can hold different roles across different projects within the same workspace.

Multi-Tenancy¶

Tenant isolation is enforced at the project level:

Each project has a unique API key used for OTLP ingestion authentication
TimeFusion partitions telemetry data by project_id in the S3 bucket
PostgreSQL metadata tables are scoped by project ID
Cross-project data access is not possible through the query engine

Workspace-level multi-tenancy

Multi-tenant workspace support (organizational accounts with centralized user management across projects) is on the roadmap but not yet available in v0.5.0. Currently, each project manages its own member list.

API Authentication¶

All API and ingestion endpoints require Bearer token authentication:

OTLP ingestion: Authorization: Bearer <PROJECT_API_KEY> header on gRPC calls to port 4317
Web UI: Session-based authentication (email + password) with CSRF protection via HTMX morphing
TimeFusion queries: PostgreSQL wire protocol on port 5432; access is restricted by network-level controls (no built-in user authentication in TimeFusion itself)

TimeFusion has no built-in auth

TimeFusion exposes a PostgreSQL wire protocol without user authentication. In production deployments, restrict access to TimeFusion's port 5432 using network policies (Kubernetes NetworkPolicy, security groups, or firewall rules). Only the Monoscope backend and authorized operators should be able to reach TimeFusion directly.

Data Protection¶

Encryption at Rest¶

Telemetry data is stored as Parquet files in S3 via Delta Lake. Encryption at rest depends on the S3 bucket configuration:

Storage Backend	Encryption Method
AWS S3	SSE-S3 (default), SSE-KMS (recommended for audit trails), or SSE-C
MinIO	Server-side encryption with KMS integration or MinIO's built-in encryption
Self-hosted S3-compatible	Depends on the storage backend; configure per vendor documentation

PostgreSQL metadata is encrypted at rest if the underlying storage volume supports it (e.g., EBS encryption for RDS, LUKS for self-hosted PostgreSQL).

Enable SSE-KMS for compliance

For regulated environments, configure the BYOS S3 bucket with SSE-KMS using a customer-managed key. This provides key audit trails via CloudTrail and the ability to revoke access by disabling the key.

Encryption in Transit¶

Path	Encryption
Client apps to OTel Collector	TLS (configure in OTel Collector)
OTel Collector to Monoscope API	TLS on gRPC (port 4317 with TLS termination at load balancer or Monoscope)
Monoscope to S3	HTTPS (S3 API calls use TLS by default)
Monoscope to PostgreSQL	TLS (configure `sslmode=require` in `DATABASE_URL`)
Monoscope to Kafka	TLS + SASL (configure in Kafka broker and Monoscope env vars)
Web browser to Monoscope UI	HTTPS (TLS termination at reverse proxy / load balancer)

Data Retention Policies¶

Retention is configurable at the project level:

S3 telemetry data: No automatic expiration by default. Configure S3 lifecycle rules on the BYOS bucket to transition old data to Glacier or expire it after a defined period (e.g., 90 days for hot, 365 days for archive).
PostgreSQL metadata: Retention follows the application lifecycle. Alert history and audit logs grow over time; implement periodic cleanup or archival.
Delta Lake time travel: TimeFusion's Delta Lake format supports versioned data. Use VACUUM operations to reclaim space from old versions while maintaining the desired retention window.

Network Security¶

Ingestion Endpoint Security¶

The OTLP ingestion endpoint (gRPC port 4317) is the primary attack surface because it is Internet-facing in most deployments.

Hardening measures:

TLS termination: Terminate TLS at the load balancer or reverse proxy (NGINX, Envoy) in front of Monoscope
Bearer token validation: Every OTLP request must include a valid project API key; requests without a valid token are rejected
Rate limiting: Configure rate limiting at the load balancer or reverse proxy to prevent ingestion flooding
IP allowlisting: If the set of ingesting services is known, restrict ingress to those IP ranges at the security group / firewall level
Network segmentation: Place the ingestion endpoint in a DMZ subnet; backend components (TimeFusion, PostgreSQL, Kafka) should not be directly accessible from the Internet

Query Authorization¶

Access to telemetry data through the web UI is mediated by the Monoscope backend, which enforces project-level RBAC. Direct access to TimeFusion bypasses RBAC, so it must be network-restricted.

For Kubernetes deployments, use a NetworkPolicy to restrict access to TimeFusion's pod:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: timefusion-access
  namespace: observability
spec:
  podSelector:
    matchLabels:
      app: timefusion
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: monoscope
      ports:
        - protocol: TCP
          port: 5432

Threat Model¶

Data Exfiltration Risks¶

Monoscope stores full-fidelity telemetry including HTTP request/response bodies, user IDs, and potentially PII that flows through OTel attributes. Exfiltration risks include:

Compromised API key: An attacker with a valid project API key can query all telemetry for that project via the web UI or API. Mitigate by rotating API keys regularly and monitoring for unusual query patterns.
S3 bucket misconfiguration: If the BYOS bucket is publicly accessible or has overly permissive IAM policies, all telemetry data is exposed. Mitigate with S3 Block Public Access, bucket policies restricting to specific IAM roles, and S3 access logging.
TimeFusion direct access: If an attacker gains network access to TimeFusion's port 5432, they can query all data without authentication. Mitigate with strict network segmentation.

BYOS Bucket Security¶

The BYOS model means the customer controls the S3 bucket. Recommended bucket hardening:

Enable S3 Block Public Access (all four settings)
Enable S3 Versioning for data integrity and recovery
Configure bucket policy restricting access to the Monoscope service IAM role and authorized operators only
Enable S3 Access Logging or CloudTrail S3 data events for audit
Enable SSE-KMS with a customer-managed key for encryption
Configure S3 Lifecycle Rules for cost-effective retention tiers
Consider S3 Object Lock (compliance mode) for regulatory requirements that mandate immutable storage

LLM Query Injection¶

Monoscope's natural language query engine translates user input into SQL via an LLM. This introduces a prompt injection risk where a malicious user could craft input to manipulate the generated SQL.

Potential attack vectors:

SQL injection via LLM: Crafted natural language input that causes the LLM to generate malicious SQL (e.g., DROP TABLE, cross-project queries). Monoscope mitigates this by executing queries through TimeFusion with read-only access and project-scoped table views.
Data exfiltration via LLM: Input designed to extract data from other projects or system tables. Mitigated by the project_id partitioning in TimeFusion and restricted query scope.
LLM prompt leakage: Input designed to make the LLM reveal its system prompt or internal instructions. This is a low-severity risk since the system prompt contains query templates, not secrets.

LLM query engine is pre-1.0

The LLM query engine is actively evolving. Review Monoscope release notes for security patches related to query injection. Consider restricting LLM query access to trusted roles in sensitive environments until the feature stabilizes.

Recommendations¶

Rotate API keys on a regular schedule and immediately after team member departures
Audit S3 bucket policies quarterly; use AWS Config rules like s3-bucket-public-read-prohibited and s3-bucket-ssl-requests-only
Network-segment TimeFusion so only the Monoscope backend can reach it
Enable TLS everywhere: ingestion, database connections, and the web UI
Restrict LLM query access to Admin and Owner roles in projects containing sensitive data
Monitor for PII in telemetry: Use OTel Collector processors (e.g., attributes/delete, transform) to strip sensitive attributes before ingestion