Surviving Day2: Picking the right tool to secure your kubernetes habitat
SlidesPremise: The CNCF landscape includes a huuuge number (80+) of security(related) projects. Analogy: Animal kingdom (includes simmilar-ish animals that might do some of the same stuff but not entirely the same)
Build Phase
- How can i scan my container for vulnerabilities? -> Well you probably mean your image
- The image itself is just a bunch of static layerns and we kinda have to trust the layers you didn’t build yourself
- The main tool used is still trivy with some easy steps
- Extract layers
- Build FS
- Identify OS and Non-OS Packages
- Compare with vuln-db
- The animal in our analogy: Racoon
Deploy Phase
- Kubernetes Native: Admission Controller
- Tool used: Kyverno (integrates as an admission controller with yaml/crd based configuration)
- Modify (e.g. add default resource limits)
- Validate (check policies)
- The animal is actually a human: The forrest guard
Start Phase
- Before the pod itself is running CSI, CNI and secret related processes (the once we want to look into) happen
- Problems: Secrets have no rotation or versioning mechanism, there is no default integration for external kms
- Project: External Secrets -> Get secrets from external kms, automaticly sync (e.g. new versions)
- The chosen animal: Capricorn
Run Phase
- Goal: Runtime scannning without including specialized instrumentation in each application
- Tool: Falco utilizing eBPF to check system calls against rules
- Idea: Detect dangerous behaviour (e.g. check for someone trying to exploit a fresh CVE)
- The analogy: Falcon
TL;DR
- Scan images (trivy)
- Enforce best pracices (kyverno)
- Use an external kms (external secrets)
- Scan at runtime (falco)