Skip to content

Latest commit

 

History

History
171 lines (131 loc) · 12.2 KB

mitigations.md

File metadata and controls

171 lines (131 loc) · 12.2 KB

Mitigation Strategies Analysis for envoyproxy/envoy

Mitigation Strategy: Configuration Validation (Pre-Deployment, Envoy-Centric)

1. Configuration Validation (Pre-Deployment, Envoy-Centric)

  • Mitigation Strategy: Configuration Validation (Pre-Deployment, Envoy-Centric)

  • Description:

    1. Envoy Validation Mode: Utilize Envoy's built-in validation mode: envoy --mode validate -c envoy.yaml. This checks for syntax errors, schema violations (against Envoy's internal schema), and some semantic errors.
    2. xDS Validation (if applicable): If using xDS (dynamic configuration), ensure your control plane (e.g., Istio) performs validation before pushing configurations to Envoy. The control plane should reject invalid configurations.
    3. Custom Validation (with Envoy API): For advanced validation, use Envoy's Admin API (if enabled and secured!) to programmatically check configuration consistency and potentially perform more complex checks that go beyond basic schema validation. This is less common but powerful.
    4. CI/CD Integration: Integrate the envoy --mode validate command (and any control plane validation) into your CI/CD pipeline. Make this a mandatory step before any deployment.
    5. Regular Updates to Validation Logic: As Envoy evolves, ensure your validation logic (especially if you have custom scripts) is updated to handle new configuration options and deprecations.

  • Threats Mitigated:

    • Misconfigured Listeners (Envoy-Specific): (Severity: High) - Prevents exposing internal services due to Envoy-specific listener misconfigurations.
    • Misconfigured Routes (Envoy-Specific): (Severity: High) - Prevents incorrect routing due to Envoy-specific routing rule errors.
    • Misconfigured Clusters (Envoy-Specific): (Severity: High) - Prevents connection errors or communication with incorrect backends due to Envoy cluster misconfigurations.
    • Misconfigured Filters (Envoy-Specific): (Severity: Medium-High) - Prevents filter-specific vulnerabilities or unexpected behavior due to incorrect Envoy filter settings.
    • Invalid Configuration Syntax (Envoy-Specific): (Severity: Medium) - Catches Envoy-specific syntax errors.
    • Typographical Errors (Envoy-Specific): (Severity: Low-Medium) - Catches typos in Envoy configuration parameters.

  • Impact:

    • Misconfigured Listeners (Envoy-Specific): Risk reduced by 90-95%.
    • Misconfigured Routes (Envoy-Specific): Risk reduced by 85-90%.
    • Misconfigured Clusters (Envoy-Specific): Risk reduced by 85-90%.
    • Misconfigured Filters (Envoy-Specific): Risk reduced by 70-80%.
    • Invalid Configuration Syntax (Envoy-Specific): Risk reduced by 100%.
    • Typographical Errors (Envoy-Specific): Risk reduced by 95-100%.

  • Currently Implemented:

    • Basic envoy --mode validate check is present in the CI/CD pipeline for the production environment.

  • Missing Implementation:

    • No xDS validation in the control plane (assuming Istio is used).
    • No custom validation using the Envoy Admin API.
    • Validation logic is not regularly updated.

Mitigation Strategy: Principle of Least Privilege (Envoy RBAC Filter)

2. Principle of Least Privilege (Envoy RBAC Filter)

  • Mitigation Strategy: Principle of Least Privilege (Envoy RBAC Filter)

  • Description:

    1. Role Definition: Define granular roles based on the source of the request (e.g., specific service identities, IP ranges, JWT claims).
    2. Permission Mapping: Map each role to specific Envoy routes and clusters. Use path prefixes, headers, and other request attributes to define fine-grained access control.
    3. Envoy RBAC Filter Configuration: Use Envoy's RBAC filter (or ext_authz for external authorization). Configure the filter with the defined roles and permissions. Use the policies field to define the rules.
    4. Principal Identification: Use another Envoy filter (e.g., JWT filter, envoy.filters.http.header_to_metadata) before the RBAC filter to extract the necessary information (e.g., JWT claims, client IP) to identify the principal (the "who") for the request.
    5. Shadow Rules (Testing): Use Envoy's "shadow rules" feature (if available in your Envoy version) to test RBAC rules without actually enforcing them. This allows you to monitor the impact of new rules before putting them into production.
    6. Regular Review: Periodically review and update the RBAC rules, especially as your application's architecture and security requirements change.

  • Threats Mitigated:

    • Unauthorized Access (Envoy-Specific): (Severity: High) - Prevents unauthorized access to specific routes and clusters managed by Envoy.
    • Privilege Escalation (Envoy-Specific): (Severity: High) - Limits the impact if a client interacting with Envoy is compromised.
    • Lateral Movement (Envoy-Specific): (Severity: High) - Restricts the ability of an attacker to move between services via Envoy.
    • Configuration Errors (Indirectly, Envoy-Specific): (Severity: Medium) - Reduces the impact of some Envoy configuration errors by limiting access.

  • Impact:

    • Unauthorized Access (Envoy-Specific): Risk reduced by 80-90%.
    • Privilege Escalation (Envoy-Specific): Risk reduced by 75-85%.
    • Lateral Movement (Envoy-Specific): Risk reduced by 70-80%.
    • Configuration Errors (Envoy-Specific): Risk reduced by 20-30%.

  • Currently Implemented:

    • Basic RBAC rules distinguish between "internal" and "external" traffic based on a header.

  • Missing Implementation:

    • No granular roles for different internal services.
    • No use of shadow rules for testing.
    • No regular review process for RBAC rules.
    • Principal identification is not robust (relies on a single header).

Mitigation Strategy: Stay Up-to-Date (Envoy Versioning)

3. Stay Up-to-Date (Envoy Versioning)

  • Mitigation Strategy: Stay Up-to-Date (Envoy Versioning and Patching) - This is inherently Envoy-specific.

  • Description: (Same as before, as it's already Envoy-focused)

    1. Subscribe to Announcements: Subscribe to the Envoy security announcements mailing list.
    2. Monitor CVEs: Regularly check for new CVEs related to Envoy.
    3. Automated Updates (Ideal): Use a container orchestration system for automated, rolling updates of Envoy images.
    4. Manual Updates (If Necessary): Establish a process for manually updating Envoy, prioritizing security releases.
    5. Testing After Updates: Thoroughly test after any Envoy update.
    6. Version Pinning (Short-Term): Temporarily pin to a known-good version if immediate patching is impossible.

  • Threats Mitigated:

    • Known Envoy Vulnerabilities (CVEs): (Severity: Varies, can be Critical) - Addresses vulnerabilities specific to Envoy.
    • Zero-Day Vulnerabilities (Indirectly): (Severity: High) - Reduces the exposure window.

  • Impact:

    • Known Envoy Vulnerabilities: Risk reduced by 95-100% (for patched vulnerabilities).
    • Zero-Day Vulnerabilities: Risk reduced by an estimated 30-50%.

  • Currently Implemented:

    • Manual update process is documented.
    • Team subscribes to the Envoy security announcements list.

  • Missing Implementation:

    • No automated updates.
    • No formal testing procedure after updates.
    • No version pinning strategy.

Mitigation Strategy: Rate Limiting (Envoy Filters)

4. Rate Limiting (Envoy Filters)

  • Mitigation Strategy: Rate Limiting (Envoy Filters)

  • Description:

    1. Identify Rate Limits: Determine appropriate rate limits based on expected traffic, API usage, and abuse scenarios.
    2. Global Rate Limiting (Envoy ratelimit Filter): Use Envoy's ratelimit filter with a rate limiting service (e.g., Redis, Envoy's own RLS). Configure the filter to communicate with the service to enforce global limits. Define descriptors (e.g., based on IP, headers) to identify clients.
    3. Local Rate Limiting (Envoy local_ratelimit Filter): Use Envoy's local_ratelimit filter for per-instance or per-connection limits. This protects individual Envoy instances. Configure the token_bucket settings.
    4. Filter Chain Order: Place rate limiting filters early in the filter chain, before more resource-intensive filters.
    5. Response Customization: Customize the response returned when a rate limit is exceeded (e.g., a 429 status code with a Retry-After header).
    6. Monitoring: Monitor Envoy's rate limiting metrics (exposed via the Admin API or through a metrics collector like Prometheus).

  • Threats Mitigated:

    • Denial-of-Service (DoS) Attacks (Targeting Envoy): (Severity: High) - Protects Envoy itself from being overwhelmed.
    • Brute-Force Attacks (Via Envoy): (Severity: Medium-High) - Limits attempts to guess credentials or API keys through Envoy.
    • Resource Exhaustion (of Envoy): (Severity: Medium) - Prevents Envoy instances from being overloaded.
    • API Abuse (Via Envoy): (Severity: Medium) - Prevents clients from exceeding limits through Envoy.

  • Impact:

    • Denial-of-Service (DoS) Attacks (Targeting Envoy): Risk reduced by 70-80%.
    • Brute-Force Attacks (Via Envoy): Risk reduced by 80-90%.
    • Resource Exhaustion (of Envoy): Risk reduced by 75-85%.
    • API Abuse (Via Envoy): Risk reduced by 80-90%.

  • Currently Implemented:

    • Basic local_ratelimit is configured on some routes.

  • Missing Implementation:

    • No global rate limiting (ratelimit filter with a rate limiting service).
    • Inconsistent application of local_ratelimit.
    • No monitoring of rate limiting metrics.
    • Incorrect filter chain order (rate limiting is after authentication).

Mitigation Strategy: Overload Management (Envoy Overload Manager)

5. Overload Management (Envoy Overload Manager)

  • Mitigation Strategy: Overload Management (Envoy Overload Manager)

  • Description:

    1. Identify Critical Resources: Determine which resources are most critical to monitor for overload (e.g., heap size, active connections, file descriptors).
    2. Configure Triggers: Set thresholds for each resource using Envoy's Overload Manager configuration. These thresholds define when Envoy considers itself overloaded.
    3. Define Actions: Specify actions to take when a threshold is exceeded. Common actions include:
      • Rejecting new requests: Return a 503 Service Unavailable error.
      • Dropping connections: Close existing connections.
      • Reducing request processing rate: Introduce delays or throttle requests.
    4. Prioritize Actions: Configure the order in which actions are taken. Start with less disruptive actions (e.g., rejecting new requests) before resorting to more drastic measures (e.g., dropping connections).
    5. Monitor Overload State: Use Envoy's statistics to monitor the Overload Manager's state and the effectiveness of the configured actions.

  • Threats Mitigated:

    • Denial-of-Service (DoS) Attacks (Targeting Envoy): (Severity: High) - Prevents Envoy from crashing or becoming unresponsive under heavy load.
    • Resource Exhaustion (of Envoy): (Severity: High) - Protects Envoy's resources from being completely depleted.
    • Cascading Failures: (Severity: High) - Prevents Envoy's overload from impacting upstream services.

  • Impact:

    • Denial-of-Service (DoS) Attacks (Targeting Envoy): Risk reduced by 60-70% (graceful degradation).
    • Resource Exhaustion (of Envoy): Risk reduced by 70-80%.
    • Cascading Failures: Risk reduced by 50-60%.

  • Currently Implemented:

    • Not implemented.

  • Missing Implementation:

    • Entire Overload Manager configuration is missing.