
Image Security and Scanning
Master the supply chain. Learn to identify vulnerabilities in your container images, enforce signed image policies, and ensure that only trusted code ever runs in your production environment.
Image Security: Protecting the Supply Chain
You can have the most perfect RBAC and the strictest Pod Security Standards, but if your container image contains a "Trojan Horse"—a vulnerable library with a known exploit—all your other defenses are useless. Once a container starts, a hacker can use that vulnerability to execute code inside your cluster.
In the world of Kubernetes, security starts before the pod is created. It starts in your CI/CD Pipeline (Module 11) and your Container Registry.
In this lesson, we will master the art of Image Hardening. We will learn why latest tags are a security nightmare, how to use tools like Trivy to scan for vulnerabilities, and how to implement an Admission Controller that serves as a "Bouncer," blocking any image that doesn't meet your security requirements.
1. The Dangers of Untrusted Images
The internet is full of "Public" images. But how do you know if python:latest on Docker Hub hasn't been tampered with? Or, more likely, how do you know it doesn't contain a critical security flaw (CVE) that was discovered yesterday?
The "Latest" Trap:
Never use the latest tag in production.
- Unpredictability: You don't know exactly what version you are running.
- Rollback Failure: If you update to a broken
latest, and you try to "Rollback," Kubernetes will just pull the samelatestagain. - Security:
latestmight point to a version that hasn't been scanned yet. Solution: Always use a specific version tag (e.g.,python:3.11-slim) or, even better, an Immutable Digest (SHA).
2. Scanning for Vulnerabilities (CVEs)
The industry standard tool for scanning images is Trivy. It is fast, lightweight, and can be run inside your local terminal or your CI/CD pipeline.
# Scan an image for 'High' and 'Critical' vulnerabilities
trivy image --severity HIGH,CRITICAL my-ai-app:v1.2.3
Trivy will check the operating system packages (like openssl) and the language dependencies (like requests in Python or next in Javascript) against a massive database of known exploits.
3. Trusted Registries and ImagePullSecrets
You should never pull images from random locations. Professional teams use a Private Registry (like AWS ECR, Google Artifact Registry, or a self-hosted Harbor).
To pull from these registries, Kubernetes needs a "Pass": an ImagePullSecret.
apiVersion: v1
kind: Pod
metadata:
name: private-pod
spec:
containers:
- name: my-app
image: <aws-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-app:v1
imagePullSecrets:
- name: ecr-registry-credentials
4. Visualizing the Secure Image Pipeline
graph LR
Code["Developer Code"] -- "Push" --> Git["Git Repo"]
Git -- "Trigger" --> CI["CI Pipeline (GitHub Actions)"]
subgraph "The Security Gate"
CI -- "Build" --> Img["Container Image"]
Img -- "Scan" --> Trivy["Trivy / Snyk"]
Trivy -- "Passed?" --> ECR["Private Registry (ECR)"]
end
ECR -- "Pull Request" --> K8s["Kubernetes Cluster"]
K8s -- "Validate Digest" --> Runtime["Running Pod"]
5. Image Signing (Cosign)
Even a private registry can be hacked. How do you guarantee that the image K8s is pulling from ECR is exactly the same image that was built by your CI pipeline?
The solution is Image Signing. Tools like Sigstore Cosign allow you to "Sign" an image after a successful scan. You then install an Admission Controller in your cluster (like Kyverno) that says: "Only allow pods to start if their image has a valid digital signature from our company's key."
6. Practical Example: Blocking Vulnerable Images
You can use Kyverno (a policy engine) to automate your security rules.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-trusted-registries
spec:
rules:
- name: validate-registry
match:
resources:
kinds:
- Pod
validate:
message: "Images must come from an approved internal registry."
pattern:
spec:
containers:
- image: "mycompany.registry.io/*"
7. AI Implementation: Scanning Model Weights
AI models often come in large binary files (like .bin or .safetensors). While these aren't "Images" themselves, they are often bundled into a container image.
The AI Security Risk:
A malicious AI model can perform a "Pickle Injection" attack, where loading the model file executes Python code on the host machine.
The Strategy:
- Scan for Malware: Use scanners that understand the structure of model files (like Checkmarx or specialized AI scanners).
- Use Safetensors: Always prefer the
.safetensorsformat, which is designed to be "Inert" and prevents code execution during loading. - Hash Verification: After downloading your AI weights into a volume (Module 6.1), run a checksum validation in your Init Container to ensure the model hasn't been tampered with.
8. Summary and Key Takeaways
- Supply Chain: Security starts with the image build.
- No Latest: Use specific tags or digests to ensure predictability and security.
- Vulnerability Scanning: Use Trivy to find CVEs before they reach production.
- Private Registry: Control where your images live.
- Admission Controllers: Block insecure or unsigned images from ever running.
- AI Specifics: Be wary of loading untrusted model files.
In the final lesson of this module, we will look at the ultimate defense: Secrets Encryption at Rest.
9. SEO Metadata & Keywords
Focus Keywords: Kubernetes image security best practices, using Trivy for K8s image scanning, Kyverno block untrusted registry, Sigstore Cosign Kubernetes tutorial, CVE scanning for container images, AI model security pickle injection.
Meta Description: Secure the supply chain of your Kubernetes cluster. Learn how to verify container images, implement automated vulnerability scanning with Trivy, and use admission controllers to ensure only trusted, signed code ever runs in your production environment.