Skip to content

Latest commit

 

History

History
60 lines (51 loc) · 5.99 KB

threat-modeling.md

File metadata and controls

60 lines (51 loc) · 5.99 KB

Threat Model Analysis for knative/community

Threat: Malicious Code Injection via Compromised Serving Controller (from Community Repository)

  • Description: An attacker compromises the Knative Serving controller within the community repository (e.g., through a compromised contributor account or a supply chain attack on a Knative dependency) and injects malicious code. If we pull this compromised version, our deployments will be compromised.
    • Impact: Complete compromise of Knative Services, potential data exfiltration, lateral movement within the Kubernetes cluster, denial of service.
    • Affected Component: Knative Serving Controller (controller component, specifically, as distributed by the community).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Keep Knative Serving updated to the latest verified patched version (verify checksums/signatures if available).
      • Implement strict Kubernetes RBAC to limit the Serving controller's permissions (even if compromised, limit the blast radius).
      • Use network policies to restrict network access to the Serving controller.
      • Employ runtime security monitoring to detect anomalous behavior within the controller.
      • Regularly audit the Serving controller's configuration and dependencies after pulling from the community.
      • Use a software composition analysis (SCA) tool before deploying any community-provided code.
      • Pin dependencies to specific, verified commits, and audit those commits.

Threat: Denial of Service via Autoscaler Manipulation (Vulnerability in Community Code)

  • Description: An attacker exploits a vulnerability within the Knative Pod Autoscaler (KPA) code itself, as distributed by the community. This vulnerability could allow for excessive scaling, resource exhaustion, or prevention of scaling, leading to a denial of service. This is distinct from misconfiguration; it's a flaw in the community-provided code.
    • Impact: Denial of service for Knative Services, increased infrastructure costs, potential cluster instability.
    • Affected Component: Knative Serving Autoscaler (KPA, autoscaler component, as distributed by the community).
    • Risk Severity: High
    • Mitigation Strategies:
      • Keep Knative Serving updated to the latest verified patched version.
      • Carefully configure KPA parameters (minScale, maxScale, concurrency targets) with appropriate limits (this mitigates the impact of a vulnerability, but doesn't prevent it).
      • Implement monitoring and alerting for KPA metrics.
      • Use Kubernetes resource quotas (again, mitigates impact).
      • Regularly review and audit KPA configurations and source code if building from source.
      • Actively monitor Knative security advisories and community discussions for vulnerability disclosures.

Threat: Event Spoofing in Eventing Broker (Vulnerability in Community Code)

  • Description: An attacker exploits a vulnerability within the Knative Eventing Broker code itself (as provided by the community) to inject forged events. This is distinct from misconfiguration; it's a flaw in the community-provided code that allows for event spoofing.
    • Impact: Data corruption, unauthorized actions triggered by events, potential for privilege escalation, denial of service.
    • Affected Component: Knative Eventing Broker (specific broker implementation, e.g., InMemoryChannel, Kafka Broker, as distributed by the community).
    • Risk Severity: High
    • Mitigation Strategies:
      • Keep Knative Eventing updated to the latest verified patched version.
      • Implement authentication and authorization for event producers and consumers (this helps, but a vulnerability in the broker itself could bypass this).
      • Use event filtering and validation (again, helps mitigate the impact).
      • Consider using a secure eventing broker implementation (e.g., Kafka with TLS and authentication).
      • Monitor eventing logs for suspicious activity.
      • Implement input validation in event consumers (defense in depth).
      • Actively monitor Knative security advisories.

Threat: Dependency Confusion Attack on Knative Build Templates (Community-Provided Templates)

  • Description: An attacker publishes a malicious package with the same name as a private dependency used in a Knative build template provided by the community. If we use this template and our build system is misconfigured, it might pull the malicious package. This directly targets the community-provided build resources.
    • Impact: Execution of malicious code during the build process, potential compromise of built Knative components.
    • Affected Component: Knative build templates (any template using external dependencies, as provided by the community), our build system configuration (but the vulnerability originates in the community template).
    • Risk Severity: High
    • Mitigation Strategies:
      • Use a private package registry for all internal dependencies.
      • Configure the build system to only pull dependencies from the private registry.
      • Use explicit version pinning for all dependencies within the community-provided templates.
      • Implement dependency verification (e.g., checksums, signatures) for all dependencies pulled during the build.
      • Regularly audit build templates and dependencies before using them.
      • Use a software composition analysis (SCA) tool on the build templates themselves.