Pod with Security Context and Resource Quotas

Hardened Pod Security

Running containers as root with full capabilities is a security anti-pattern. A hardened pod configuration reduces the attack surface by dropping unnecessary privileges and enforcing resource boundaries.

Key Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  labels:
    app: "secure-app"
spec:
  replicas: 2
  template:
    spec:
      serviceAccountName: secure-app-sa
      containers:
        - name: app
          image: my-app:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Security Context (applied in YAML manually)

While the builder generates the base manifest, you should add these security settings:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Why Each Setting Matters

• runAsNonRoot: Prevents the container from running as UID 0 (root)
• readOnlyRootFilesystem: Prevents writes to the container filesystem (use emptyDir for temp files)
• drop ALL capabilities: Removes all Linux capabilities; add back only what is needed
• allowPrivilegeEscalation: false: Prevents processes from gaining more privileges than their parent
• seccompProfile: Applies the default syscall filter to restrict dangerous system calls

Resource Quotas

Setting both requests and limits is essential:

• Requests: Guarantee the pod gets these resources; used for scheduling
• Limits: Hard cap that triggers OOM kill (memory) or throttling (CPU)

Without limits, a compromised or buggy container can consume all node resources, affecting other pods (noisy neighbor problem).