The Snyk Kubernetes Workload Scanning feature, when deployed, actually operates in two distinct modes: Manifest Scanning and Runtime Scanning. Understanding the difference is key to getting the most out of it.
Let’s see it in action, starting with Manifest Scanning. Imagine you’ve just defined a new Kubernetes Deployment. Before it even gets to the cluster, Snyk can tell you if it’s introducing vulnerabilities.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-vulnerable-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app-container
image: vulnerable/ubuntu:latest # This image has known CVEs
ports:
- containerPort: 80
When you run snyk test --file=my-vulnerable-app.yaml, Snyk will analyze this manifest. It doesn’t need to talk to the Kubernetes API server or know about your running cluster. It’s purely a static analysis of the workload definition. It will output something like:
Testing /path/to/my-vulnerable-app.yaml...
✗ High severity vulnerability found in vulnerable/ubuntu:latest
CVE-2023-12345
Description: A buffer overflow vulnerability in the xyz library...
Info: https://snyk.io/vuln/SNYK-UBUNTU-XYZ-12345
From: vulnerable/ubuntu:latest
[SNYK-CC-VULNUBUNTU-XYZ]
This is invaluable for shifting security left – catching issues before they’re deployed.
Now, let’s look at Runtime Scanning. This is where Snyk becomes aware of what’s actually running in your Kubernetes cluster. It achieves this by integrating with the Kubernetes API server and, for more advanced insights, by deploying a small agent (a DaemonSet) to your nodes.
When Snyk Runtime Scanning is enabled, it continuously monitors your running workloads. If you deploy that my-vulnerable-app without catching it in the manifest scan, Snyk Runtime Scanning will detect it once it’s running. It might show up in the Snyk UI like this:
Workload: my-vulnerable-app
Namespace: default
Image: vulnerable/ubuntu:latest
Vulnerabilities:
- CVE-2023-12345 (High)
- CVE-2023-67890 (Medium)
The core problem Runtime Scanning solves is the gap between what’s defined in your manifests and what’s actually running. Misconfigurations, manual changes to running pods, or even images that get updated outside of your CI/CD pipeline can introduce new risks. Snyk Runtime Scanning bridges this gap.
Internally, the Runtime Scanner component (often a Deployment itself) watches Kubernetes API events for Pods and Deployments. It queries the API server for details about running containers, including their images. If the Snyk agent (DaemonSet) is deployed, it can also inspect the running processes and network connections within pods for deeper runtime threat detection.
The key levers you control are:
- Resource Scope: Which namespaces or cluster-wide you want Snyk to monitor.
- Policy Enforcement: Defining rules for what constitutes a critical vulnerability that should trigger alerts or block deployments.
- Integration: Connecting Snyk to your Kubernetes cluster via its integration mechanism (often involving RBAC roles and service accounts).
The most surprising thing about the runtime scanner is how it uses Kubernetes events to build its picture of the running environment. It doesn’t just poll; it reacts to changes. This event-driven nature allows it to be highly responsive to the dynamic nature of Kubernetes. For example, if a pod is restarted with a new image tag, Snyk will pick up that change rapidly because it’s subscribed to the Pod update event stream.
The true power of Snyk’s Kubernetes integration lies in its ability to correlate runtime findings with your IaC. If Snyk detects a vulnerability in a running pod, it can often trace that back to the specific manifest that defined it, allowing for a direct remediation path.
The next step after setting up both manifest and runtime scanning is often exploring Snyk’s capabilities for IaC drift detection.