Kubernetes Security Special Interest Group (SIG Security)

The Vulnerability Management track covers the Kubernetes-wide processes, policies, and workflows used to tackle known vulnerabilities in Kubernetes artifacts (code, images, and binaries) that are detectable via automation.

Key objectives include:

• Periodically scanning Kubernetes artifacts to identify known vulnerabilities.
• Using existing GitHub issues and PRs to document and resolve vulnerabilities impacting Kubernetes.
• Creating community awareness and documentation regarding known CVEs in Kubernetes-related artifacts.

The SIG Security External Audit subproject coordinates regular, comprehensive, third-party security audits for the Kubernetes project. The subproject is responsible for defining the audit scope, managing the Request for Proposal (RFP) process, reviewing vendor proposals, and publishing audit deliverables.

All audit activities and deliverables are subject to the Security Release Process and the embargo policy. Information gathered during audits must not be shared outside the vendor or the subproject without explicit consent from the subproject and SIG Security chairs.

The Security Special Interest Group (SIG) manages horizontal security initiatives for the Kubernetes project. Its responsibilities include:

• Security Audits: Managing regular security audits.
• Vulnerability Management: Overseeing the vulnerability management process.
• Security Documentation: Creating and maintaining cross-cutting security documentation.
• Community Management: Managing the security community.

The scope and governance of the group are formally defined in the SIG Security Charter.

The Kubernetes Admission Control Threat Model identifies risks faced by designers and operators of admission controllers. Admission control is a critical security mechanism used to ensure consistent security of workloads and resources. This model helps identify ways an attacker might bypass controls, reduce their efficacy, or misuse them to attack the cluster.

Target Audiences:

• Admission Controller Authors: To identify design and implementation risks during development.
• Organizations/Operators: To review configurations and identify common attacks against their deployed controllers.
• Security Assessors: To evaluate the security posture of existing or new clusters using admission controllers.
• Kubernetes Developers: To understand attack vectors and proactively avoid them in future updates.

The Kubernetes Working Group prioritizes the following attack vectors during security audits:

1. Unauthenticated Access: Gaining unauthenticated access to a cluster that results in the compromise of in-scope components.
2. Namespace Boundary Crossing: An authenticated attacker being able to affect resources that their credentials do not directly allow (privilege escalation/lateral movement across namespaces).
3. General Component Vulnerabilities: Any other attack vector targeting the components defined in the project scope.

Understanding the trust boundaries for kube-proxy:

• Trust Boundary: There is an implicit trust boundary between Worker components and Container components (pods) on the node.
• Multi-tenancy: kube-proxy does not currently segment clients from one another. Clients on the same pod/host share the same iptables/ipvs configuration.
• Authorization: kube-proxy does not handle authorization itself; the arbiters of authorization are kubelet and kube-apiserver (via the watch mechanism).
• Secrets/Cryptography: kube-proxy does not manage secrets or handle application-level cryptography; it only uses TLS for its connection to the kube-apiserver and consumes credentials via command-line arguments.

Cluster API relies on several specialized controllers to automate cluster lifecycle:

• Cluster API Core Controller: Provides high-level management of basic primitives (machine deployment, machineset, and machines) which act as blueprints for infrastructure providers.
• Cluster API Bootstrap Kubeadm Controller: A provider that converts a machine into a Kubernetes node using kubeadm. It handles initializing control plane nodes and attaching nodes to the cluster.
• Cluster API Kubeadm Control Plane Controller: Manages the control plane lifecycle (bootstrapping, scaling, deletion) without disrupting cluster quorum. It manages kubeconfig secrets used to access workload clusters.
• Cluster API Provider AWS Controller: An infrastructure provider that manages AWS-specific resources (network, compute, ELB) to run the cluster.

Shift-Down Security is a strategy for embedding security and governance directly into the operational aspects of cloud-native platforms (like Kubernetes) rather than relying solely on developer-centric 'Shift-Left' practices. This approach aims to balance developer agility (via Platform Engineering and self-service) with robust security by making the platform itself secure by default.

To implement a Shift-Down security model, focus on these three pillars:

1. Security Automation via Policy as Code (PaC): Use automated policies to enforce security boundaries within the platform infrastructure.
2. Cross-Functional Collaboration: Foster continuous alignment between Developers, Operations, and Security teams.
3. Continuous Tuning: Regularly refine platform security controls to ensure the resilience of Kubernetes environments as they evolve.