Attack Surface: Unauthorized Data Ingestion
- Description: Attackers inject false or malicious metric data into Cortex.
- Cortex Contribution: Cortex provides the ingestion API endpoints (typically Prometheus remote-write compatible) that are the target of this attack. Its multi-tenancy model, if misconfigured, exacerbates the risk.
- Example: An attacker sends fabricated metrics indicating a healthy service when it's actually down, masking a real outage. Or, a malicious tenant injects data into another tenant's stream.
- Impact: False alerts, incorrect dashboards, flawed automated decisions based on bad data, data corruption, potential data poisoning for machine learning models trained on the data.
- Risk Severity: High (can be Critical if used for critical decision-making).
- Mitigation Strategies:
- Authentication: Implement strong authentication (mTLS, API keys, JWT with tenant claims) for all ingestion endpoints.
- Authorization: Enforce strict tenant-based authorization, ensuring tenants can only write to their own streams. Use RBAC to limit write access.
- Rate Limiting: Implement per-tenant and global rate limits to prevent ingestion floods.
- Data Validation: Validate incoming data (label names, label values, timestamps, sample values) to prevent obviously malicious or nonsensical data. Reject data outside expected ranges.
- Input Sanitization: Sanitize input to prevent injection attacks targeting the underlying storage or processing components.
Attack Surface: Denial of Service (DoS) via Ingestion
- Description: Attackers overwhelm the ingestion pipeline with a high volume of metrics, causing service degradation or unavailability.
- Cortex Contribution: Cortex's distributed architecture, while designed for scalability, can be overwhelmed if not properly configured and protected. The distributor and ingester components are primary targets.
- Example: An attacker sends a massive number of new time series with high-cardinality labels, exhausting resources in the ingesters and storage backend.
- Impact: Loss of monitoring data, inability to ingest new metrics, potential cascading failures in dependent systems.
- Risk Severity: High
- Mitigation Strategies:
- Rate Limiting: Implement strict per-tenant and global rate limits on the number of series, samples, and label cardinality.
- Resource Limits: Configure appropriate resource limits (CPU, memory, network bandwidth) for all Cortex components.
- Horizontal Scaling: Ensure Cortex is deployed with sufficient resources and can scale horizontally to handle increased load.
- Ingress Protection: Use an ingress controller or load balancer with DoS protection capabilities.
- Monitoring and Alerting: Monitor resource utilization and alert on anomalies that could indicate a DoS attack.
Attack Surface: Unauthorized Query Execution
- Description: Attackers execute unauthorized queries against the Cortex query API, potentially accessing sensitive data or causing resource exhaustion.
- Cortex Contribution: Cortex provides the query API (PromQL) and its associated query engine (query-frontend, querier).
- Example: An attacker gains access to the query API and runs a query that retrieves all metrics from all tenants, exposing sensitive data. Or, they run a very complex query that consumes all available resources.
- Impact: Data exfiltration, denial of service, potential exposure of internal infrastructure details.
- Risk Severity: High (can be Critical if sensitive data is exposed).
- Mitigation Strategies:
- Authentication: Implement strong authentication for the query API.
- Authorization: Enforce strict tenant-based authorization and RBAC, limiting query access to authorized data.
- Query Limits: Implement limits on query complexity (length, duration, number of series returned, data range).
- Query Analysis: Use query analysis tools to detect and block potentially malicious or resource-intensive queries.
- Auditing: Log all query activity for auditing and forensic analysis.
Attack Surface: Inter-Component Communication Vulnerabilities
- Description: Attackers exploit vulnerabilities in the communication between Cortex components (e.g., distributor, ingester, querier).
- Cortex Contribution: Cortex's distributed architecture relies on inter-component communication, creating potential attack vectors if not secured.
- Example: An attacker intercepts unencrypted traffic between the distributor and ingester, gaining access to raw metric data. Or, a compromised ingester is used to attack the querier.
- Impact: Data interception, man-in-the-middle attacks, potential compromise of multiple components.
- Risk Severity: High
- Mitigation Strategies:
- mTLS: Enforce mutual TLS (mTLS) for all inter-component communication.
- Network Segmentation: Use network policies to restrict communication between components to only necessary traffic.
- Principle of Least Privilege: Ensure components only have the necessary permissions to communicate with each other.
- Regular Security Audits: Audit network configurations and component interactions.