Skip to content

Latest commit

 

History

History
115 lines (87 loc) · 9.27 KB

mitigations.md

File metadata and controls

115 lines (87 loc) · 9.27 KB

Mitigation Strategies Analysis for openfaas/faas

Mitigation Strategy: Resource Limits Enforcement (FaaS-Specific)

  • Mitigation Strategy: Enforce strict resource limits (CPU, memory, execution time) on each function.

  • Description:

    1. FaaS Context: In FaaS, functions are often short-lived and execute in response to events. Resource limits are crucial because a single runaway function can impact the entire platform, affecting other users/functions.
    2. stack.yml Configuration: Use OpenFaaS's stack.yml to define limits (maximum) and requests (guaranteed) for CPU and memory, and exec_timeout for execution time. This leverages the underlying container orchestration (usually Kubernetes). 
      functions:
  my-function:
    limits:
      memory: 128Mi
      cpu: 0.5
    requests:
      memory: 64Mi
      cpu: 0.2
    exec_timeout: 30s
    3. FaaS-Specific Monitoring: Monitor function resource usage per invocation and per function. OpenFaaS integrations with Prometheus/Grafana are designed for this. Set alerts for functions exceeding limits or exhibiting anomalous behavior. This is different from monitoring a traditional long-running application.

  • Threats Mitigated:

    • FaaS-Specific Denial of Service (DoS) (High Severity): A single function consuming excessive resources can prevent other functions from running, a key concern in a multi-tenant FaaS environment.
    • Cost Overruns in Pay-per-Use FaaS (Medium Severity): Uncontrolled resource consumption directly translates to higher costs in cloud-based FaaS offerings.

  • Impact:

    • FaaS-Specific DoS: Directly prevents resource exhaustion DoS attacks targeting the FaaS platform. Risk reduction: High.
    • Cost Overruns: Controls costs by preventing runaway function resource usage. Risk reduction: High.

  • Currently Implemented:

    • Example: image-processor function has limits in stack.yml. Prometheus/Grafana dashboards are used.

  • Missing Implementation:

    • Example: notification-sender lacks limits. Alerts for overconsumption are not configured.

Mitigation Strategy: Function Isolation Enforcement (FaaS-Specific)

  • Mitigation Strategy: Ensure strong isolation between functions, even within the same cluster.

  • Description:

    1. FaaS Context: Functions are often deployed by different teams or even different users. Strong isolation is essential to prevent one compromised function from affecting others.
    2. Containerization: OpenFaaS uses containers (Docker, containerd) for isolation. This is the baseline, but further steps are needed.
    3. Network Policies (Kubernetes): If using Kubernetes, implement Network Policies to restrict network access between functions. A compromised function should only be able to communicate with the resources it absolutely needs. This is crucially important in FaaS.
    4. Security-Enhanced Runtimes (Optional): Consider using runtimes like gVisor or Kata Containers for stronger isolation than standard runc. This adds overhead, so evaluate the performance impact. This is a FaaS-specific consideration due to the multi-tenancy and short-lived nature of functions.
    5. Namespaces (Kubernetes): Use Kubernetes namespaces to logically separate functions belonging to different teams or applications. This provides an additional layer of isolation and access control.

  • Threats Mitigated:

    • Lateral Movement between Functions (High Severity): A compromised function should not be able to attack other functions on the same platform. This is a primary concern in FaaS.
    • Container Escape (Medium Severity): Stronger isolation (e.g., with gVisor) reduces the impact of a container escape vulnerability.

  • Impact:

    • Lateral Movement: Significantly reduces the risk of cross-function attacks. Risk reduction: High.
    • Container Escape: Provides an additional layer of defense. Risk reduction: Medium.

  • Currently Implemented:

    • Example: Basic Kubernetes Network Policies isolate the openfaas-fn namespace.

  • Missing Implementation:

    • Example: Fine-grained Network Policies between functions are missing. gVisor/Kata are not used. Namespace separation is not fully utilized.

Mitigation Strategy: Event Source Authentication and Authorization (FaaS-Specific)

  • Mitigation Strategy: Securely authenticate and authorize the sources of events that trigger functions.

  • Description:

    1. FaaS Context: Functions are event-driven. The security of the event source is directly tied to the security of the function.
    2. Authentication: Ensure that only authorized event sources can trigger your functions. The method depends on the event source:
      • Message Queues (Kafka, NATS, etc.): Use credentials and access control lists (ACLs) to restrict who can publish messages to the topics that trigger your functions.
      • HTTP Webhooks: Validate the authenticity of webhook requests using techniques like HMAC signatures (shared secret) or mutual TLS authentication.
      • Cloud Provider Events (AWS S3, Azure Event Grid, etc.): Use IAM roles and policies to control access to the event sources.
    3. Authorization: Even after authentication, verify that the event source has the permission to trigger the specific function. This can be done within the function itself or using platform-level mechanisms (e.g., IAM policies).
    4. Event Validation: After authenticating the source, validate the content of the event itself. Check for expected structure and data types to prevent injection attacks via the event payload. This is input validation, but it's specifically important in the context of FaaS event triggers.

  • Threats Mitigated:

    • Unauthorized Function Invocation (High Severity): Prevents attackers from triggering functions with malicious or unexpected inputs. This is a direct threat to FaaS.
    • Injection Attacks via Event Payloads (High Severity): Malicious data injected into the event payload can be used to exploit vulnerabilities in the function.
    • Denial of Service (DoS) via Event Flooding (Medium Severity): While resource limits help, securing the event source prevents an attacker from overwhelming the system with events.

  • Impact:

    • Unauthorized Invocation: Eliminates the risk of unauthorized function execution. Risk reduction: High.
    • Injection via Events: Prevents injection attacks that leverage the event payload. Risk reduction: High.
    • DoS via Events: Reduces the risk of DoS attacks originating from the event source. Risk reduction: Medium.

  • Currently Implemented:

    • Example: HMAC signatures are used to validate webhooks from GitHub.

  • Missing Implementation:

    • Example: Authentication and authorization for message queue triggers are not fully implemented. Event payload validation is basic.

Mitigation Strategy: Cold Start Mitigation (Performance and Security)

  • Mitigation Strategy: Minimize function cold starts.

  • Description:

    1. FaaS Context: Cold starts (the time it takes to initialize a function instance) are inherent to FaaS. While primarily a performance issue, they have security implications.
    2. Keep Functions Warm: Use techniques like "function warming" (periodically invoking functions to keep them in memory) to reduce cold starts. OpenFaaS provides mechanisms for this.
    3. Optimize Function Code: Minimize dependencies and code size to reduce the time it takes to load the function.
    4. Choose Appropriate Runtimes: Some language runtimes (e.g., Go, compiled languages) have faster startup times than others (e.g., Python, Node.js with many dependencies).
    5. Provisioned Concurrency (Cloud-Specific): Some cloud providers (like AWS Lambda) offer "provisioned concurrency" to keep a specified number of function instances warm, eliminating cold starts (at a cost).

  • Threats Mitigated:

    • Timing Attacks (Low Severity): While not a primary concern, consistent cold start times can make timing attacks slightly more difficult.
    • Denial of Service (DoS) Amplification (Low Severity): If an attacker can trigger many cold starts, it could potentially amplify a DoS attack by consuming more resources.

  • Impact:

    • Timing Attacks: Minor reduction in risk. Risk reduction: Low.
    • DoS Amplification: Minor reduction in risk. Risk reduction: Low.
    • Performance: Significant improvement in function response times. (Primary benefit)

  • Currently Implemented:

    • Example: Basic function warming is enabled for frequently used functions.

  • Missing Implementation:

    • Example: Code optimization for cold starts is not a priority. Provisioned concurrency is not used.