September 18, 2026 路 #2
A log shipper with the keys to the node
This pod ships logs from the node. What makes it unsafe to run as written?
apiVersion: v1
kind: Pod
metadata:
name: log-shipper
spec:
containers:
- name: shipper
image: fluent/fluent-bit:3.1.9
securityContext:
privileged: true
volumeMounts:
- name: varlog
mountPath: /var/log
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/logNext puzzle in UTC
One try. The first answer sticks.
How to fix it
privileged true is not required to read /var/log. It grants host-level capabilities and device access that a log shipper should never have.
privileged: true is close to "turn off the container." The process gets access to host devices, can change network configuration, and is a short step from controlling the node. Reading /var/log does not require that. The hostPath volume is already enough to see the files, and readOnly: true is the right instinct.
Treat privileged as a break-glass exception with a ticket, a time limit, and an admission policy that rejects it everywhere else.
Fix
Drop the privileged flag. If the shipper still cannot read a specific file, grant only the capability or the mount it needs.
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
Keep the hostPath mount read-only. Add a Pod Security restricted profile on the namespace so the next copy-paste of this manifest fails admission instead of reaching production.