Skip to content

Latest commit

 

History

History
79 lines (66 loc) · 10.5 KB

threat-modeling.md

File metadata and controls

79 lines (66 loc) · 10.5 KB

Threat Model Analysis for openfaas/faas

Threat: Function Code Injection via Unvalidated Input (FaaS Context)

  • Description: An attacker provides malicious input to a function that is not properly sanitized. This input is used in a way that allows code execution within the function's runtime environment, leveraging FaaS-specific execution contexts (e.g., exploiting how the FaaS platform handles input/output or interacts with the underlying container). This is not a general web injection, but one exploiting the FaaS execution model.
    • Impact: Complete compromise of the function; arbitrary code execution; access to sensitive data the function handles; potential lateral movement to other functions or FaaS components if permissions allow.
    • Affected Component: The specific vulnerable function.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strict Input Validation: Rigorous input validation and sanitization, specifically tailored to the expected data format and function logic. Whitelisting is strongly preferred.
      • Avoid Dangerous Functions/Patterns: Prohibit or severely restrict the use of functions like eval(), exec(), system(), or any dynamic code execution based on user input. Identify and mitigate FaaS-specific patterns that could be abused.
      • Principle of Least Privilege (Function Context): Ensure the function's runtime environment has the absolute minimum necessary permissions. Avoid running as root within the container.
      • Code Review (FaaS-Specific): Code reviews must focus on how the function interacts with the FaaS platform and its input/output handling, looking for FaaS-specific injection vectors.
      • Static Analysis (FaaS-Aware): Use static analysis tools that understand FaaS execution models and can detect injection vulnerabilities specific to the chosen FaaS platform.

Threat: Denial of Service via Function Resource Exhaustion (FaaS-Specific)

  • Description: An attacker crafts input that causes a function to consume excessive resources (CPU, memory, network) within the constraints of the FaaS platform. This exploits the scaling and resource management mechanisms of OpenFaaS itself. The attacker repeatedly invokes the function, aiming to exhaust resources allocated to the function or the underlying FaaS infrastructure.
    • Impact: Unresponsive function; potential cascading failures affecting other functions; possible denial of service for the entire OpenFaaS deployment if scaling limits are not properly configured or if the underlying infrastructure is overwhelmed.
    • Affected Component: The targeted function, OpenFaaS Gateway, and potentially worker nodes (faas-netes if using Kubernetes).
    • Risk Severity: High
    • Mitigation Strategies:
      • FaaS-Specific Resource Limits: Configure strict resource limits (CPU, memory, execution time, concurrent invocations) for each function using OpenFaaS's configuration options.
      • Input Validation (Size/Complexity): Validate input size and complexity to prevent excessively large or computationally expensive inputs that could bypass resource limits.
      • Rate Limiting (at Gateway): Implement rate limiting at the OpenFaaS API Gateway to control the invocation rate per user, IP, or other criteria. This is a critical FaaS-level control.
      • Timeout Configuration (FaaS Level): Set appropriate function execution timeouts within OpenFaaS to prevent long-running or hung processes from consuming resources indefinitely.
      • Circuit Breakers (FaaS Integration): Integrate circuit breakers with OpenFaaS to automatically stop invoking a failing function, preventing cascading failures.

Threat: Unauthorized Function Deployment (to OpenFaaS)

  • Description: An attacker gains unauthorized access to the OpenFaaS deployment environment (e.g., Kubernetes cluster credentials, OpenFaaS CLI access) and deploys a malicious function or modifies an existing function's code or configuration through the OpenFaaS deployment mechanisms.
    • Impact: Complete control over the deployed malicious function; ability to execute arbitrary code with the function's privileges; access to any data the function handles; potential to compromise the entire OpenFaaS deployment or connected services.
    • Affected Component: OpenFaaS Gateway, faas-netes (if using Kubernetes), and the deployed function.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strong Authentication/Authorization (for OpenFaaS): Implement robust authentication and authorization for all access to the OpenFaaS deployment environment (Kubernetes RBAC, OpenFaaS CLI authentication).
      • Principle of Least Privilege (Deployment Permissions): Grant only the minimum necessary permissions to users and service accounts that interact with OpenFaaS for deployments.
      • Image Signing (for Function Images): Enforce the use of signed function container images (e.g., Docker Content Trust, Notary) to verify the integrity and origin of deployed functions. OpenFaaS should reject unsigned images.
      • Audit Logging (OpenFaaS Actions): Enable comprehensive audit logging for all OpenFaaS deployment-related actions (function creation, updates, deletion).
      • Regular Security Audits (OpenFaaS Deployment): Conduct regular security audits of the OpenFaaS deployment environment, including access controls, network policies, and configuration.

Threat: OpenFaaS Gateway Bypass (Direct Function Access)

  • Description: An attacker directly accesses functions or internal OpenFaaS components, bypassing the OpenFaaS API Gateway and its security controls (authentication, authorization, rate limiting). This is often due to misconfigured network policies or exposed internal services within the FaaS deployment.
    • Impact: Bypass of all Gateway-level security; unauthorized function invocation; potential access to internal OpenFaaS components and their data; ability to launch attacks without being subject to rate limits or other Gateway protections.
    • Affected Component: OpenFaaS Gateway, individual functions, and potentially other OpenFaaS components (e.g., queue-worker, Prometheus).
    • Risk Severity: High
    • Mitigation Strategies:
      • Network Policies (Strict Enforcement): Implement strict network policies (e.g., Kubernetes Network Policies) to isolate functions and internal OpenFaaS components. Only allow traffic from the OpenFaaS Gateway to functions. Deny all other direct access.
      • Service Mesh (for Advanced Control): Consider using a service mesh (Istio, Linkerd) for more granular network control, mutual TLS authentication between services, and enhanced observability within the OpenFaaS deployment.
      • Regular Security Audits (Network Configuration): Regularly audit network configurations and access controls to ensure that the Gateway cannot be bypassed.
      • Internal Authentication (Between Components): Even for internal communication within the OpenFaaS deployment, consider using authentication mechanisms (e.g., mTLS) between components to prevent unauthorized access.

Threat: Dependency Vulnerabilities in Functions (FaaS-Specific Impact)

  • Description: A function uses vulnerable third-party libraries. While this is a general issue, the impact within a FaaS environment is heightened due to the potential for rapid scaling and the shared infrastructure. An attacker exploits these vulnerabilities, and the compromised function is rapidly scaled, amplifying the attack.
    • Impact: Code execution within the function's container, data breaches, potential privilege escalation within the FaaS environment, and potentially a wider impact due to the rapid scaling of the compromised function.
    • Affected Component: The specific function.
    • Risk Severity: High
    • Mitigation Strategies:
      • Dependency Management: Use a dependency management tool (npm, pip, etc.) to track dependencies.
      • Vulnerability Scanning: Regularly scan dependencies for known vulnerabilities using automated tools. Integrate this into the CI/CD pipeline.
      • Update Dependencies: Keep dependencies up to date.
      • Software Composition Analysis (SCA): Use SCA tools to identify and manage open-source components and their risks.
      • Minimal Base Images: Use minimal base images for your function containers to reduce the attack surface.

Threat: Misconfigured Function Secrets (FaaS Integration)

  • Description: Secrets (API keys, etc.) required by a function are stored insecurely. This is particularly relevant in a FaaS context because secrets are often managed through the FaaS platform (e.g., Kubernetes Secrets, OpenFaaS secrets). Misconfiguration of these platform-level secret mechanisms is the threat.
    • Impact: Exposure of sensitive credentials, leading to unauthorized access to external services or data. The FaaS platform's secret management is compromised.
    • Affected Component: The specific function and the OpenFaaS secrets management mechanism (e.g., faas-netes secrets).
    • Risk Severity: High
    • Mitigation Strategies:
      • Proper Use of FaaS Secrets Management: Use the OpenFaaS-provided secrets management solution (e.g., Kubernetes Secrets) correctly. Understand its security properties and limitations.
      • Avoid Hardcoding: Never hardcode secrets in function code.
      • Principle of Least Privilege (Secret Access): Grant functions access only to the specific secrets they require. Don't provide overly broad access.
      • Regular Audits of Secret Configuration: Regularly audit how secrets are configured and accessed within OpenFaaS.
      • External Secret Stores (Optional): For enhanced security, consider integrating with external secret stores like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, and configure OpenFaaS to use them.