Securing Kubernetes: An OSI Layer-by-Layer Breakdown
A practical take on how the classic OSI model still maps to Kubernetes security, and how to secure each layer, from app to node, based on insights from my CKS journey.
Introduction
Kubernetes has redefined infrastructure and application delivery, but security remains a multi-layered challenge. While the OSI model was initially designed to standardise networking, it can still guide us in building layered security defences in the cloud-native world.
In this article, weâll walk through the OSI model from Layer 7 to Layer 1, illustrating how each layer corresponds to Kubernetes, the risks that arise, and the controls that can help mitigate them.
As a Certified Kubernetes Security Specialist (CKS), I utilise this model not only to secure clusters but also to communicate risk across Dev, Ops, and Security teams.
OSI Model Mapped to Kubernetes Security
Below is a visual representation of the OSI model layered over the components and risks of Kubernetes:
Related Resource: The Kubernetes Threat Matrix
While this article uses the OSI model to frame Kubernetes security risks from infrastructure to application, itâs also helpful to explore how attackers operate tactically within Kubernetes.
The Kubernetes Threat Matrix, inspired by MITRE ATT&CK, outlines real-world attack techniques used to exploit Kubernetes environments.
It covers:
Initial access (exposed dashboards, insecure kubelet ports)
Credential access (secrets from environment variables)
Privilege escalation (mounted host paths, container breakout)
Lateral movement (using service accounts to reach the API server)
Impact (crypto mining or cluster shutdown)
Many of these techniques correlate directly to the OSI layers discussed above, making the two models complementary for security architects and practitioners.
Layer 7 â Application Layer
Refresher: The Application layer provides the interface that users interact with, whether through APIs, dashboards, or web applications.
In Kubernetes:
Kube API server
Web UIs like Kubernetes Dashboard
Apps in pods
Admission controllers
Case Study:
Teslaâs exposed dashboard (2018) allowed unauthenticated pod deployments, leading to cryptocurrency mining and theft of AWS metadata.
Hackers Enlisted Tesla's Cloud to Mine Cryptocurrency
The recent rash of cryptojacking attacks has hit a Tesla database that contained potentially sensitive information.
How to mitigate it:
Use RBAC with least privilege.
Disable the dashboard or enforce strong auth
Scan code and containers (Trivy, ZAP, Bandit)
Audit API calls and deny risky admission requests (OPA/Kyverno)
Layer 6 â Presentation Layer
Refresher: This layer handles data formatting and encryption â think of protocols such as TLS, JSON, YAML, or gRPC.
In Kubernetes:
YAML configs
gRPC between control plane components
Webhooks for admission or mutation
Risk:
Unencrypted traffic or secret leaks via misconfigured gRPC services, webhook responses, or logs.
How to Secure It:
Enforce TLS/mTLS everywhere
Enable KMS-backed secret encryption
Scan YAMLs for hardcoded secrets (TruffleHog, GitLeaks)
đ gRPC Security Best Practices
Layer 5 â Session Layer
Refresher: A session handles how long and how securely two entities communicate, such as TLS sessions and token-based identities.
In Kubernetes:
ServiceAccount tokens
x509 certificates for kubelet/kube-apiserver
Istio or SPIFFE/SPIRE identities
Risk:
Attackers use stolen tokens from pods to escalate privileges or persist.
How to Secure It:
Use short-lived credentials (IRSA, SPIRE)
Rotate all tokens and certificates regularly
Monitor session misuse via audit logs
đ Kubernetes Authentication
Layer 4 â Transport Layer
Refresher: This layer ensures reliable data transmission between systems using TCP or UDP.
In Kubernetes:
TCP/UDP communication between pods and services
Ingress traffic via NodePort or LoadBalancer
Control plane traffic over HTTPS (e.g., API server)
Risk:
Open or misconfigured ports (e.g., unauthenticated NodePorts or dashboards) enable external access, port scanning, or Man-in-the-Middle (MITM) attacks, as seen in the Tesla breach.
How to Secure It:
Define strict NetworkPolicies with defaultDeny mode.
Avoid using NodePort unless necessary.
Use mutual TLS (mTLS) via service mesh (Istio, Linkerd)
Whitelist source IPs on LoadBalancers and API endpoints
đ Kubernetes Network Policies
Layer 3 â Network Layer
Refresher: This layer manages IP-based routing and service discovery â essentially, how packets determine their destination.
In Kubernetes:
Pod-to-pod communication using CNI (e.g., Calico, Cilium)
Internal DNS resolution via CoreDNS
Inter-node routing across subnets
Risk:
Attackers who gain access to a pod can move laterally to other workloads or scan the network for services across namespaces.
How to Secure It:
Use Cilium or Calico to enforce namespace and pod-level isolation.
Monitor and restrict egress DNS queries.
Encrypt pod network traffic with IPSec or WireGuard
Log DNS activity and block known-malicious destinations
Layer 2 â Data Link Layer
Refresher: This layer governs how machines on the same local network communicate, including MAC addressing and the Address Resolution Protocol (ARP).
In Kubernetes:
Virtual Ethernet pairs (veth) connect pods to the host.
Bridge networks, such as cni0, manage packet forwarding.
Host network interfaces (NICs)
Risk:
Privileged pods may exploit Layer 2 to sniff traffic, spoof MAC addresses, or poison ARP caches, a hazardous practice in self-managed environments.
How to Secure It:
Block hostNetwork: true and privileged: true by default
Drop container capabilities like NET_ADMIN
Apply AppArmor, SELinux, and Seccomp to constrain kernel access
Use eBPF-based tools (e.g., Tracee, Cilium Hubble) to detect misuse
Layer 1 â Physical Layer
Where It Shows Up
Bare-metal or cloud VM nodes
RPi clusters (K3S)
Underlying hypervisors and BIOS
Risks
Physical node access
Hardware-level vulnerabilities
Crypto mining or firmware implants
Security Best Practices
Use trusted compute nodes (AWS Nitro, Secure Boot)
Run hardened OSes like Talos, Bottlerocket, or Flatcar.
Enforce IAM isolation per node group.
Use physical access controls for on-prem hardware
đ CIS Kubernetes Node Hardening Benchmark
Why This Model Works
The OSI model is more than theory; itâs a practical way to approach defence in depth. Kubernetes operates across all seven layers. By understanding which risks appear where, we can:
Design better runtime security.
Catch misconfigurations earlier.
Select the appropriate open-source or proprietary tools.
Map threats to mitigation faster.
Whether youâre preparing for the CKS, securing a production cluster, or teaching your team how to think securely, this model brings clarity.
Final Thoughts
In Kubernetes, security is layered, and so should our thinking be.
Understanding how Layer 7 vulnerabilities differ from Layer 2 attack vectors is critical in building resilient cloud-native systems. The OSI model remains a timeless mental framework, even in a world of containers and declarative infrastructure.