You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document provides a security assurance case for the Jaeger project, demonstrating how security requirements are met through the application of secure design principles and mitigation of common implementation weaknesses.
Jaeger is a distributed tracing system that collects, stores, and visualizes trace data from instrumented applications. The primary security concerns are:
Data Confidentiality: Trace data may contain sensitive information (service names, endpoints, timing data)
Data Integrity: Trace data should not be tampered with
Availability: The tracing infrastructure should not become a DoS vector
Access Control: Only authorized users should access trace data
Implementation: Jaeger leverages established protocols (OTLP, gRPC) rather than custom implementations
Evidence: Uses OpenTelemetry Collector framework for core functionality
Fail-Safe Defaults
Implementation: TLS certificate verification is enabled by default when TLS is configured
Evidence: insecure_skip_verify must be explicitly set to disable verification
Note: TLS itself is opt-in to simplify initial testing and non-production deployments; for all production deployments, TLS (preferably mTLS where supported) MUST be enabled on all external and inter-service connections.
Complete Mediation
Implementation: All API endpoints require passing through authentication when configured
Evidence: Bearer token and RBAC support at Query service level
Open Design
Implementation: All source code is publicly available on GitHub
Evidence: Apache 2.0 license, public security documentation
Separation of Privilege
Implementation: Different components (Collector, Query) can be deployed with different access levels
Evidence: Collector only writes, Query only reads from storage
Least Privilege
Implementation: Storage credentials can be scoped to minimum required permissions
Evidence: Separate read/write keyspaces supported for Cassandra
Least Common Mechanism
Implementation: Admin endpoints separated from data endpoints
Evidence: Separate ports for admin, metrics, and data APIs
Psychological Acceptability
Implementation: Security is configurable via standard YAML configuration
Evidence: Consistent TLS configuration across all components
Common Weakness Mitigations
OWASP Top 10 / CWE Top 25 Coverage
Weakness
Mitigation
Injection (CWE-89, CWE-79)
Structured data formats (protobuf/OTLP), parameterized storage queries
Broken Authentication (CWE-287)
Bearer tokens, OAuth2, mTLS support
Sensitive Data Exposure (CWE-200)
TLS for all communications, no credentials in traces
XML External Entities
Not applicable - uses protobuf/JSON
Broken Access Control (CWE-284)
RBAC support in Query service
Security Misconfiguration
Secure defaults where possible, configuration validation