Your FastAPI agent is now deployed to Kubernetes (Chapter 3). It's running, scaling, exposed to traffic. But here's the question: who can access what?
In a production cluster, your agent container might handle sensitive data—user conversations, API keys, model weights. A compromised container could leak everything. This lesson builds the security foundations that protect your agent in production: non-root execution, read-only filesystems, network isolation, and vulnerability scanning.
By the end, your agent will run with minimal privileges, reject requests from unauthorized namespaces, and expose zero unnecessary attack surface.
Before we write a single YAML line, let's define what "secure" means for your agent.
Security Intent: AI agent handling sensitive user data must not run as root, must have read-only filesystem, must be isolated from other namespaces, and must reject unauthorized network traffic.
Success Criteria:
Constraints:
Non-Goals:
The first line of defense is SecurityContext—a Kubernetes configuration that controls how a container runs at the OS level.
By default, containers inherit the permissions of the user who created the image. In many base images (Python, Node), that user is root. This means:
Running as non-root doesn't prevent compromise, but it limits what an attacker can do after gaining access.
First, create an image with a non-root user. In your Dockerfile:
Key points:
Build and push this image:
Output:
Even if your image runs as a non-root user, Kubernetes can enforce it with SecurityContext. This prevents accidentally running a container as root.
The second layer: read-only root filesystem. An attacker who gains code execution inside the container can modify files on disk, install backdoors, or change the application logic. A read-only filesystem blocks this attack vector.
When you mount a read-only filesystem, the application can still write to specific locations using emptyDir volumes. These are temporary, per-Pod directories that disappear when the Pod restarts—perfect for logs, temp files, and caches.
The third layer: Network Policies. By default, Kubernetes allows all Pods to communicate with each other. A compromised Pod in one namespace could reach Pods in another.
Network Policies enforce segmentation: your agent only receives traffic from authorized namespaces and services.
First, make sure your namespaces are labeled:
Output:
Apply the Network Policies:
Output:
Test the policy by trying to reach the agent from an unauthorized Pod:
Output:
The connection is denied. But traffic from the authorized gateway succeeds:
Output:
Kubernetes provides Pod Security Standards—three tiers that codify security best practices. This lesson's agent should adhere to the Restricted standard.
Label your namespace to enforce the Restricted standard:
Output:
Now, any Pod in the agents namespace that violates Restricted standards is rejected.
The fourth layer: image security. Before your container runs, scan it for known vulnerabilities in dependencies.
Install Trivy (or use Docker image):
Output:
Upgrading base packages often resolves vulnerabilities.
Add a scanning step to your deployment pipeline:
Here's the complete, security-hardened Deployment combining all layers:
Deploy everything:
Output:
Verify security settings:
Output:
Audit an Existing Deployment for Security
Describe your current agent Deployment:
Help me identify security gaps and prioritize fixes based on impact.