28. Kubernetes Threat Model
28
User Compromise and Insider Threats
• Cluster admin account compromise
• Rogue Employee
• Build system compromised
Application Vulnerabilities
• Lack of authentication and authorization, both k8s internal and external
• Weak or incorrect usage of cryptography
• Application and API vulnerabilities - remote code execution (RCE), web
vulnerabilities (XSS, CSRF, SSRF, SQL Injection etc.)
• Insecure third-party components
29. Kubernetes Threat Model
29
Network and Infrastructure
• Network snooping, ARP spoof attacks
• Compromising infrastructure services (etc. NTP, DNS, SSH)
• Kernel and other operating system vulnerabilities
Application Containers
• Container breakout and unauthorized access control plane and other
containers
• Denial of Service - resource hogging, eating up CPU/Mem/Disk/IO to
impact or even crash other containers
• Compromised or malicious image or pipeline
30. Kubernetes Threat Model
30
Misconfiguration
• Insecure default configurations - unused open ports,
services, not enforcing system/application limits, failing to
implement security features
• Misuse of passwords, passphrases, TLS private keys
(*cough* checking them into git *cough*. Bad handling
include key reuse, insecure handling of keys, no key
rotation, weak passwords, not using MFA etc.
• Lack of network segmentation - exposing critical systems to
various network attacks
42. Dynamic Admission Control allows
teams to build custom security
checks by intercepting requests to
the Kubernetes API server prior to
scheduling the object.
46. Gatekeeper Examples
46
Require Specific Labels upon object creation
Audit Cluster for violations of policy
Namespace must have “Owner” label
Containers must have resource limits defined
47. Always ensure images come
from a known-good source
and the integrity has been
verified.
48. Tools such as gVisor and Kata
Containers can help further isolate
and sandbox containers that are
running untrusted workloads
inside of Kubernetes.
49. Remember, Kubernetes is just
running servers under the hood.
Our regular old OS hardening and
network protections apply.
52. 52
• Can containers run as root?
• Can containers mount sensitive volumes / directories? Read or Read / Write?
• Can Pods run in “Privileged” mode?
• What policies (PSP, custom, OPA) are in place and for who?
• How is authentication handled?
• Is RBAC enforcing the principle of least privilege?
• How are secrets being stored and retrieved? Rotated? Revoked?
• Where do container images come from? Are images being validated?
• How is network security being enforced? Can you audit these rules?
• Are your hosts hardened? Monitoring in place?
• Are you using Kubernetes Audit? Where are logs sent?
• Ingress / LB inventory in place? What external IP addresses are available?
• What happens if / when your application has an SSRF bug?
• Have you performed a proper threat model of Kubernetes environments?
• Third party products, tools, helpers? Are they secure?
58. 58
• Flexibility > Security will be our reality
• Choose your Own Security Adventure
• More tooling
• Tighter Cloud integrations
• Overall Kubernetes maturity
• Increasing target for attack
The Future?
From the fallout 4 video game
This game is published by the Don't Be Bored Games Company in the years before the Great War and is for ages 5 to 29. A text blurb describes the game as "an exciting new board game that brings friends, family, and nuclear explosions together. The first player to make it to a safe distance will survive. The rest will perish. Do you have what it takes?"