Kubernetes Security
Survival Guide
By Paul-Emmanuel Raoul / skyper@skyplabs.net / @Skyper@fosstodon.org
Kubernetes Architecture
API Servers
Entry point for managing the cluster
One per master node
Official client: kubectl
etcd
Store cluster's configuration and state
Service discovery
Write access = root access on the whole cluster
Kubelet
Bridge between worker nodes and the cluster logic
One per worker node
Takes care of managing the pods
Has its own API
Configuration Hardening
The default configuration is generally not secure
Large number of parameters
Easy to make a mistake
Kube API
Referred as "API server" on the diagram
RBAC
Role-Based Access Control
Since v1.8 released on 29th September 2017
Entity - Role - Resource
Least privilege
Insecure Port
Port 8080 by default
Bypass authentication and authorisation checks
Deprecated in v1.10 released on 27th March 2018
Anonymous Access
Bypass authentication and authorisation checks
RBAC enabled = read-only access by default
Deprecated in v1.10 as well
Keep Your Certificates Safe
Passphrase
Kubernetes doesn't support revocation lists
Remediation: external authentication provider
etcd
Restrict the Access to its API
Enable client authentication
Secure peer-to-peer communications
Disable self-signed certificates
Restrict network communications
Protect its Storage Unit
Kubernetes secrets are stored in etcd by default
Kubelet
Restrict the Access to its API
Disable anonymous authentication
Disable the read-only port
Restrict Kubelet's Privileges
One Kubelet instance per worker node
Consequently, subdivision of each instance's permissions
Only each instance's own pods
Only each instance's own node
Secure the Communications with the Kube API
HTTPS enabled by default
Bootstrapped with one-year-expiration certificates
Kubelet certificate rotation since v1.8 (beta)
Security Tools
Check the security of your cluster automatically
kube-bench
Checks your configuration files
Based on the CIS Kubernetes Benchmark
kube-bench
kube-hunter
Vulnerability scanner
Scan a remote cluster or from a pod
kube-hunter
Helm
Package manager for Kubernetes
Package = Chart
YAML files + template engine
Massively used
Helm Architecture
Security Issues
The default configuration is completely unsecure
Cluster admin by default
No authentication by default
Possibility to use Tiller from the inside of the cluster
Tiller is not RBAC-friendly
One role per Tiller instance
Single whole-cluster-admin-privileged Tiller instances are pretty common
Some Remediation Techniques
One Tiller instance per namespace / team / ...
Bind to localhost only (Helm CLI tool port forwards to the remote pod)
Helm 3
Tillerless
More RBAC-aware
No release date at the moment
In the meantime: helm template
Image Hardening
Most Docker images run as root
Too many useless (and dangerous) packages installed
Presence of known vulnerabilities
Docker Images Vulnerability Scanning
List of known vulnerabilities (CVEs)
Static Analysis
Should be integrated to your CI/CD pipelines
Security Scanning Tools
Dockerfile Good Practices
Never Hard-code Secrets
Privilege passing secrets in files than via environment variables
Protect Your VCS Repository
Secrets can be exposed via your VCS repository (Git, ...)
Use private repositories
Encrypt the sensitive files (ex: git-crypt)
Remove Unnecessary Software
Keep only the strict minimum in your final image
If you need to build something: multi-stage builds
Use FROM scratch when possible
Version correctly your images
Add a label with the version number
Add tags (linked with Git tags)
Runtime Hardening
Security Context
Used to define privileges and access control at runtime
Example: run as non-root
Linux Capabilities
Breaks up root privileges into smaller groups of privileges
Example: bind to a port lower than 1024
Limit Resources
Define a CPU and memory limit
Lower the impact of potentiel (D)DOS