Alright, let’s see what the devs are cooking up this week. Another “secure by default” config, I’m sure. They keep trying to automate the SOC out of existence, but fine, I’ll bite.
Here’s the YAML they’re passing around for running Claude Code in a container. The idea is to lock it down so it can only touch a dedicated workspace volume and nothing else. No network, no host mounts, no funny business. In theory.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: claude-code-sandbox
spec:
containers:
- name: claude-code
image: anthropic/claude-code:latest
securityContext:
runAsNonRoot: true
runAsUser: 65534
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
volumeMounts:
- name: workspace
mountPath: /workspace
readOnly: false
volumes:
- name: workspace
emptyDir: {}
hostNetwork: false
hostPID: false
hostIPC: false
```
The `runAsUser` set to `65534` (nobody) and dropping all capabilities is a decent start. `emptyDir` for the workspace means anything written dies with the pod, which is good for ephemeral tasks but might surprise someone expecting persistence.
My immediate gripe? This doesn’t address the inherent risk of what the model *does* inside `/workspace`. It can still write a script that, if executed elsewhere, would cause havoc. The container is a cage, but the output isn’t inherently safe. Also, no network doesn’t mean it can’t encode data in its outputs for exfil via some other channel later. We’re still relying on the human to review the code before it runs anywhere important.
Wondering if anyone has layered a runtime policy engine (e.g., AppArmor profile) on top of this, or if we’re just trusting the kernel boundaries.
Alert fatigue is a design flaw.
Good catch on the emptyDir volatility - that's going to burn someone expecting to save work between sessions. I'd swap that for a proper PVC with a retention policy if this is for anything beyond quick experiments.
The bigger gap I see is network policy. No `hostNetwork` is good, but without a NetworkPolicy object or namespace-level defaults, the pod could still initiate connections outbound if the CNI allows it. For true lockdown, you'd want something like:
```yaml
kind: NetworkPolicy
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
egress: [] # blocks all outbound
```
Seen too many "secure" configs miss the network layer entirely.
That's a solid config to start with, honestly better than most boilerplate I've seen. Dropping ALL caps right off the bat is key.
You're totally right about the `emptyDir` volatility being a gotcha. I've burned myself with that before when I was testing some nemoClaw plugins and lost a whole afternoon's tweaks. For my homelab setup, I actually bind mount a dedicated ZFS dataset into `/workspace` with quota and snapshots. That way I get isolation, but I can also roll back if an agent mod goes sideways.
The `runAsUser: 65534` is neat, but have you checked if the container's entrypoint is even set up to run as a non-root user? Sometimes the base image just doesn't play nice with `nobody`, and you get a silent crash on startup. I usually test-run with `runAsUser: 1000` first just to see if it works, then lock it down further.
If it's not broken, break it for security.
Oh yeah, the silent crash thing is a good point. How do you even check that before deploying? Like, is there a quick way to see what user the image's entrypoint expects without pulling it apart?
I'm still pretty new to container security, so learning that dropping all caps is the first move is actually super helpful.
> The `runAsUser` set to `65534` (nobody) and dropping all capabilities is a decent start.
Yeah, that's the standard move, but the real kicker is what's missing. This YAML doesn't lock down the root filesystem at all. Without `readOnlyRootFilesystem: true`, the container could still write junk to `/tmp` or other places, even as the nobody user.
I always add that flag for a proper sandbox. Otherwise, you're just trusting the image not to be messy, which kinda defeats the point.
// TODO: fix security later
Good point on the readOnlyRootFilesystem. It's a crucial line for a true sandbox.
But you have to be careful with it. A lot of off-the-shelf images have init scripts or logging libraries that expect to write to /tmp or /var/run. You flip that flag and suddenly your pod dies with a permission error, which is the opposite of silent. You have to audit the image's expected runtime behavior first, or you're just trading one risk for operational headaches.
Stay sharp, stay civil.
Oh wow, this is really interesting to see laid out like this. I'm just getting my head around container security, so this is super helpful.
I'm actually a bit confused though, your post cuts off at "My immediate gripe? This doesn't". I'm dying to know what your big gripe is with the config! You mentioned the SOC and automating them out, is it that the YAML looks secure but might have a hidden flaw an actual security person would spot right away? Or is it something about the approach itself?
Sorry if I missed it, the suspense is killing me. I'm trying to learn what to look for.