Skip to main content
In this guide, we’ll cover critical Kubernetes security concepts, highlight common vulnerabilities in deployments and container images, and show you how to enforce policies using industry-standard tools like OPA Conftest, Kubesec, and Trivy. By the end, you’ll have actionable steps to harden your clusters and CI/CD pipelines.

​
Table of Contents

  1. Common Kubernetes Vulnerabilities
  2. Scanning and Policy Enforcement
  3. Defining and Applying securityContext
  4. Additional Kubernetes Security Features
  5. Demo: Validating Deployments with OPA Conftest
  6. Links & References

​
Common Kubernetes Vulnerabilities

Attackers often exploit misconfigurations or unpatched components. Typical risks include:
  • Privileged Containers
  • Images with Known CVEs
  • Excessive RBAC Permissions
  • Unrestricted Network Access
  • Improper Secret Management
Addressing these early in your development lifecycle prevents costly incidents later on.

​
Scanning and Policy Enforcement

Leverage automated scanners and policy-as-code to detect risks before deployment. Below is a comparison:
ToolUse CaseExample Command
TrivyImage & filesystem CVE scanningtrivy image my-app:latest
KubesecStatic manifest analysiskubesec scan deployment.yaml
OPA ConftestCustom policy checks against YAMLconftest test deployment.yaml --policy policies/
Integrate these tools into your CI pipelines for continuous assessment. For example, add a GitHub Action step to run trivy on every push.

​
Defining and Applying securityContext

A securityContext sets Linux privileges and filesystem controls for Pods and containers. Enforcing non-root users and read-only filesystems significantly reduces attack surface.
FieldDescription
runAsUserNumeric UID the container must run as
runAsNonRootEnsures the container UID is non-zero
readOnlyRootFilesystemMounts the root filesystem read-only
allowPrivilegeEscalationDefaults to false to block setuid binaries and escalations
Running containers as root (UID 0) may allow privilege escalation and lateral movement within your cluster. Always set runAsNonRoot: true unless absolutely necessary.

​
Example securityContext

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
    readOnlyRootFilesystem: true
  containers:
    - name: app
      image: your-registry/secure-app:latest
      securityContext:
        allowPrivilegeEscalation: false
      volumeMounts:
        - name: tmp-volume
          mountPath: /tmp
  volumes:
    - name: tmp-volume
      emptyDir: {}

​
Additional Kubernetes Security Features

Beyond securityContext, Kubernetes offers:
  • AppArmor & SELinux policies for Mandatory Access Control
  • Pod Security Admission & legacy PodSecurityPolicy
  • NetworkPolicies to isolate traffic at the pod level
  • Audit Logging for forensic analysis
  • Air-gapped Cluster Deployments for sensitive environments
  • TLS Encryption for API and etcd communication

​
Demo: Validating Deployments with OPA Conftest

  1. Write a Rego Policy
    Create policies/run_as_non_root.rego:     
    package k8s.security

deny[msg] {
  input.kind == "Pod"
  not input.spec.securityContext.runAsNonRoot
  msg = "Pods must set securityContext.runAsNonRoot = true"
}
  2. Create a Sample Deployment
    Save as deployment.yaml:     
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: insecure-deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: insecure
    spec:
      containers:
        - name: app
          image: busybox
  3. Run Conftest 
    conftest test deployment.yaml --policy policies/
    You should see an error indicating the missing runAsNonRoot setting.

Watch Video