Skip to content

Latest commit

 

History

History
100 lines (81 loc) · 11.1 KB

threat-modeling.md

File metadata and controls

100 lines (81 loc) · 11.1 KB

Threat Model Analysis for kubernetes/kubernetes

Threat: Unauthorized API Server Access

  • 1. Threat: Unauthorized API Server Access

    • Description: An attacker gains unauthorized access to the Kubernetes API server (kube-apiserver) by exploiting weak authentication (e.g., stolen service account token, default credentials, no TLS) or bypassing authorization controls. The attacker can then issue commands to create, modify, or delete any resource within the cluster, including deploying malicious pods, stealing secrets, and deleting deployments.
    • Impact: Complete cluster compromise. The attacker has full control over the cluster and can perform any action, leading to data exfiltration, service disruption, and potential control of the underlying infrastructure.
    • Affected Kubernetes Component: kube-apiserver (the primary control plane component).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strong Authentication: Enforce strong authentication using client certificates, OIDC, or service account tokens with short lifetimes. Disable anonymous access.
      • TLS Encryption: Ensure all API server communication is encrypted with TLS using valid certificates.
      • RBAC: Implement strict RBAC policies to limit access to the API server based on the principle of least privilege. Regularly audit and refine these policies.
      • Network Policies: Restrict network access to the API server to only authorized clients (control plane components, authorized management tools). Use firewalls and network segmentation.
      • Audit Logging: Enable detailed audit logging for the API server and actively monitor for suspicious requests and anomalies.
      • Regular Credential Rotation: Rotate API server credentials and service account tokens regularly, following a defined schedule.
      • API Rate Limiting: Implement rate limiting on the API server to prevent brute-force attacks and denial-of-service attempts.

Threat: Privileged Container Escape

  • 2. Threat: Privileged Container Escape

    • Description: An attacker exploits a vulnerability in a privileged container (running with privileged: true or excessive capabilities) or a vulnerability in the container runtime itself to escape the container's isolation and gain root access to the host node.
    • Impact: Complete compromise of the host node. The attacker gains full control of the node, can access all other containers running on it, and can potentially compromise the entire cluster by attacking other nodes or the control plane.
    • Affected Kubernetes Component: Container Runtime (e.g., Docker, containerd), kubelet (the node agent).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Avoid Privileged Containers: Strictly avoid running containers in privileged mode. Most applications do not require this.
      • Least Privilege: If privileged access is absolutely unavoidable, grant only the absolute minimum required capabilities. Use capabilities.add and capabilities.drop in the Pod spec for fine-grained control.
      • Security Context Constraints (SCCs) / Pod Security Admission: Use SCCs (OpenShift) or Pod Security Admission (Kubernetes) to enforce strict restrictions on the use of privileged containers and capabilities.
      • AppArmor/SELinux: Enable and configure AppArmor or SELinux on the host nodes to provide an additional layer of security, limiting what even privileged containers can do.
      • Runtime Security Tools: Employ runtime security tools (e.g., Falco, Sysdig Secure) to detect and prevent container escapes and other malicious activity at runtime.
      • Container Runtime Hardening: Ensure the container runtime is configured securely and kept up-to-date with the latest security patches.

Threat: etcd Data Manipulation

  • 3. Threat: etcd Data Manipulation

    • Description: An attacker gains unauthorized access to the etcd cluster (either directly or through a compromised control plane component) and modifies or deletes cluster configuration data. This includes secrets, deployments, RBAC policies, and other critical information.
    • Impact: Complete cluster compromise, data loss, service disruption, and potential for irreversible damage. The attacker can manipulate the cluster's state, potentially deleting all resources or injecting malicious configurations.
    • Affected Kubernetes Component: etcd (the key-value store).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • TLS Encryption: Enforce TLS encryption for all etcd communication, including client-to-server and peer-to-peer traffic. Use strong, valid certificates.
      • Strong Authentication: Use strong authentication for etcd access (e.g., client certificates). Do not allow anonymous access.
      • Network Isolation: Strictly restrict network access to etcd to only the Kubernetes control plane components. Use firewalls and network segmentation.
      • Regular Backups: Implement a robust backup and recovery strategy for etcd data. Regularly test the restoration process.
      • Audit Logging: Enable etcd audit logging and actively monitor for suspicious activity.
      • RBAC for etcd: If using a separate, dedicated etcd cluster (not managed by Kubernetes), implement RBAC to control access to etcd data.

Threat: Lateral Movement via Unrestricted Network Policies

  • 4. Threat: Lateral Movement via Unrestricted Network Policies

    • Description: An attacker compromises a single pod and, due to the absence of network policies or overly permissive policies, is able to communicate with other pods and services within the cluster. They can then attempt to exploit vulnerabilities in those other services or access sensitive data, moving laterally across the cluster.
    • Impact: Compromise of multiple pods and services. Data breaches, service disruption, and potential escalation to cluster-wide compromise if the attacker can reach critical components.
    • Affected Kubernetes Component: Network Plugin (e.g., Calico, Flannel, Weave Net), kube-proxy.
    • Risk Severity: High
    • Mitigation Strategies:
      • Default Deny: Implement a "default deny" network policy for each namespace, blocking all inter-pod communication by default.
      • Explicit Allow Rules: Create specific network policies to explicitly allow only necessary communication between pods and services. Use labels and selectors for precise targeting.
      • Namespace Isolation: Use namespaces to logically isolate different applications, environments, and teams.
      • Regular Policy Review: Regularly review and update network policies to ensure they remain effective and aligned with the application's evolving needs.
      • Service Mesh: Consider using a service mesh (e.g., Istio, Linkerd) for more advanced traffic management, security (including mTLS), and observability.

Threat: Secrets Exposure via Misconfiguration

  • 5. Threat: Secrets Exposure via Misconfiguration

    • Description: An attacker gains access to sensitive data (API keys, passwords, database credentials) due to insecure storage or handling of secrets within Kubernetes. This could be through improperly configured Kubernetes Secrets (e.g., not encrypted at rest), secrets exposed in environment variables, or secrets leaked through compromised pods.
    • Impact: Data breaches, unauthorized access to external services (databases, cloud providers), and potential for further cluster compromise by leveraging the stolen credentials.
    • Affected Kubernetes Component: kube-apiserver (for Kubernetes Secrets), potentially any pod that consumes the secrets.
    • Risk Severity: High
    • Mitigation Strategies:
      • Secrets Management Solutions: Use a dedicated secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for robust secret storage, encryption, and access control. This is the preferred approach.
      • Integration with Kubernetes: Integrate the secrets management solution with Kubernetes using mechanisms like sidecar containers, CSI drivers, or mutating admission webhooks.
      • Encryption at Rest: Encrypt Kubernetes Secrets at rest using a KMS provider (e.g., AWS KMS, Azure Key Vault, GCP KMS).
      • Least Privilege Access: Grant pods only access to the specific secrets they absolutely require. Use RBAC to enforce this.
      • Secret Rotation: Implement a process for regularly rotating secrets, both within Kubernetes and in external systems.
      • Avoid Hardcoding: Never hardcode secrets in application code, configuration files, or container images.
      • Kubernetes Secrets (with limitations): If using Kubernetes Secrets directly, understand their limitations (base64 encoded, not encrypted at rest by default) and take appropriate precautions.

Threat: Compromised Kubernetes Add-on

  • 6. Threat: Compromised Kubernetes Add-on

    • Description: An attacker exploits a vulnerability in a third-party Kubernetes add-on (e.g., a dashboard, ingress controller, monitoring tool, or CNI plugin) to gain access to the cluster or disrupt services. The attacker leverages the add-on's privileges to perform malicious actions.
    • Impact: Varies depending on the add-on and its privileges, but could range from access to sensitive data to complete cluster compromise if the add-on has extensive permissions.
    • Affected Kubernetes Component: The specific vulnerable add-on.
    • Risk Severity: High to Critical (depending on the add-on and vulnerability)
    • Mitigation Strategies:
      • Regular Updates: Keep all Kubernetes add-ons up to date with the latest security patches. Prioritize updates for add-ons with known vulnerabilities.
      • Vulnerability Scanning: Scan add-on container images for vulnerabilities as part of your CI/CD pipeline.
      • Vendor Security Advisories: Actively monitor for security advisories related to the add-ons you are using. Subscribe to vendor mailing lists or security feeds.
      • Least Privilege: Grant add-ons only the minimum necessary permissions. Review and restrict their RBAC roles and bindings.
      • Managed Kubernetes: Consider using a managed Kubernetes service that handles add-on updates and security for you.
      • Careful Selection: Thoroughly vet any third-party add-ons before deploying them. Evaluate their security posture and community support.
      • Network Policies for Add-ons: Apply network policies to restrict the network access of add-ons, limiting their ability to communicate with other parts of the cluster.