Container Security on Kubernetes: What a DevOps Engineer Implements to Protect Production in 2026
A default Kubernetes cluster has significant security gaps. Here is the 8-layer security stack a DevOps engineer implements to protect production Kubernetes workloads and what it costs.
Taukir K
As a DevOps Engineer at Acquaint Softtech, a software development partner, one of the first things I check in a new Kubernetes engagement is how many containers run as root. The answer is almost always: all of them. A default Kubernetes cluster has containers running as root, no pod security policies enforced, secrets stored in plain base64, no network policies restricting pod-to-pod traffic, and no image vulnerability scanning. These are not edge cases - they are the default state of most clusters that a DevOps engineer did not explicitly harden. This guide covers the 8-layer security stack a DevOps engineer implements to protect production Kubernetes workloads.
- SaaS CTOs preparing for a SOC 2 or ISO 27001 audit where Kubernetes security controls are explicitly required
- Engineering leads in the UK, Europe, or US who have received a penetration test report identifying Kubernetes security gaps
- Teams going through enterprise sales where security questionnaires ask about container security controls
- Founders hiring a DevOps engineer and wanting Kubernetes security hardening in the engagement brief
Kubernetes security is not a single control. It is a layered stack where each layer protect against a different threat vector. A container that runs as root but has no external network access is partially protected. A container with strong network policies but hardcoded secrets in environment variables has a different risk profile. A DevOps engineer implements all 8 layers because the threat model for production SaaS covers all of them.
For teams setting up their EKS cluster and wanting security hardening as part of the initial setup, the AWS EKS setup and management guide covers the cluster foundation. This article covers the security layer specifically, typically completed in a dedicated security sprint after the cluster is running.
The 8 Kubernetes Security Layers: What a DevOps Engineer Implements
Each layer addresses a different attack surface. A DevOps engineer implements them in priority order based on the platform's threat model, typically completing all 8 within a 2 to 3 week security sprint.
Layer 1: Pod Security Standards (non-root containers) |
Running containers as root is the single most common and most impactful Kubernetes security gap. A container running as root has the same privileges as the host root user if the container escapes its sandbox. Kubernetes Pod Security Standards (PSS) enforce non-root containers cluster-wide. |
A DevOps engineer enables the Restricted Pod Security Standard on production namespaces. This prevents containers from running as root, from requesting host network or host PID access, and from using privileged mode. Most application containers work without modification under the Restricted standard. Those that do not are flagged and updated before the policy is enforced. |
Layer 2: Network Policies (zero-trust pod networking) |
By default, all pods in a Kubernetes cluster can communicate with all other pods. A compromised frontend pod can make direct requests to the database pod. Network Policies are Kubernetes-native firewall rules that restrict which pods can communicate with which other pods. |
A DevOps engineer implements a default-deny network policy for all namespaces, then adds explicit allow rules: frontend pod can reach API pod on port 8080, API pod can reach database pod on port 5432. Nothing else is permitted by default. |
Layer 3: Secrets Management (Vault or Secrets Manager) |
Kubernetes Secrets store values in base64 encoding, not encryption. A developer with kubectl access can decode any Secret in the cluster. For production workloads, secrets belong in a dedicated secrets management system. |
A DevOps engineer integrates either HashiCorp Vault or AWS Secrets Manager via the External Secrets Operator (ESO). ESO runs as a Kubernetes controller that reads secrets from Vault or Secrets Manager and creates Kubernetes Secrets automatically. Rotation is centrally managed. Revocation takes effect immediately. |
Layer 4: RBAC (least-privilege access) |
Every user, service account, and CI/CD system that interacts with the Kubernetes API has permissions defined by RBAC roles. Default service accounts have broad permissions that accumulate over time without review. |
A DevOps engineer audits all RBAC bindings, implements least-privilege role definitions, removes default ClusterAdmin bindings given to CI/CD systems, and configures namespace-scoped roles for development teams. AWS IRSA or Azure Workload Identity grants pods AWS/Azure permissions without static credentials. |
Layer 5: Admission Controllers (Gatekeeper or Kyverno) |
Pod Security Standards cover runtime security constraints. Admission controllers enforce broader policy: approved image registries, required labels, resource limits on every pod, and rejection of pods with dangerous security configurations. |
A DevOps engineer deploys either OPA Gatekeeper or Kyverno and implements: images from approved registries only, required resource requests and limits, required security context on all containers, and mandatory labels for cost attribution. |
Layer 6: Image Vulnerability Scanning |
A container image is built on a base image that may contain known CVEs. Running containers with unpatched CVEs is a direct compliance violation under SOC 2 and ISO 27001. |
A DevOps engineer integrates image scanning into the CI/CD pipeline. Every image pushed to the registry is scanned by Trivy or AWS ECR scanning before it can be deployed. Critical and high CVEs block the deployment. A clean scan (or documented exception) is required before helm upgrade proceeds. |
Layer 7: Runtime Security (Falco) |
Network policies and pod security standards prevent many attacks. Falco detects attacks at runtime: a shell opened inside a container, a file read from a sensitive path, a system call that should never occur in a containerised application. |
A DevOps engineer deploys Falco as a DaemonSet on every node. Falco rules fire alerts to Slack or PagerDuty when a container exhibits runtime behaviour indicating exploitation: unexpected shell execution, unexpected network connection, sensitive file read. |
Layer 8: Audit Logging and Cluster-Level Logging |
Kubernetes API audit logging records every action taken against the cluster API: who created or deleted what resource, when, and from where. Without audit logging, a security incident in the cluster has no forensic trail. |
A DevOps engineer enables Kubernetes audit logging at the API server, ships audit logs to CloudWatch Logs or Azure Monitor, and configures log retention to satisfy the relevant compliance framework (SOC 2 typically requires 1 year). CloudTrail is configured for underlying AWS infrastructure API calls. |
For teams managing multiple Kubernetes environments, the multi-environment Kubernetes setup guide covers how security policies are applied consistently across dev, staging, and production namespaces using the same Gatekeeper or Kyverno policy library.
Kubernetes Cluster Running in Production Without a Security Audit?
UK, European, and US SaaS teams preparing for SOC 2 or ISO 27001: tell Acquaint Softtech your cluster size and which of the 8 security layers you currently have configured. A vetted DevOps engineer will identify your gaps and send a security hardening plan within 48 hours.
Kubernetes Security and SOC 2: What the Auditors Look For
SOC 2 auditors examining a Kubernetes-based SaaS product typically check a specific set of controls. A DevOps engineer who has implemented the 8 layers above have the evidence for each control ready. Here is the mapping between SOC 2 control areas and the Kubernetes security layers.
SOC 2 control area | Kubernetes security layer | Evidence a DevOps engineer provides |
Access control (CC6.1) | RBAC + Workload Identity/IRSA | RBAC policy files in Git. Audit log showing no shared credentials. Service account permission inventory. |
Logical access restrictions (CC6.2) | Network Policies | Network policy YAML files. Default-deny evidence. Ingress/egress rules documented. |
Encryption in transit and at rest (CC6.7) | TLS on all services + Secrets Manager | TLS certificate configuration. Vault or Secrets Manager integration evidence. |
Security monitoring (CC7.2) | Falco + Audit Logging | Falco alert history. CloudWatch audit log retention configuration. |
Change management (CC8.1) | Admission Controllers + Image Scanning | Gatekeeper/Kyverno policy library. CI/CD pipeline scan results. Image registry scan history. |
Vulnerability management (CC7.1) | Image Vulnerability Scanning | Trivy or ECR scan results. CVE remediation log. Critical CVE blocking policy evidence. |
Minimum necessary access (CC6.3) | Pod Security Standards + RBAC | Pod security standard enforcement evidence. Least-privilege RBAC review results. |
For the infrastructure as code that defines security policies in a reproducible, auditable way, the Terraform infrastructure automation guide covers how RBAC, network policies, and admission controller configurations are managed as Terraform or GitOps-managed code.
What UK, European, and US Companies Pay for Kubernetes Security in 2026
The cost of a Kubernetes security engagement has two component: the DevOps engineer time to implement the 8 layers, and the ongoing management to maintain the security posture. Here is the honest 2026 comparison across all regions Acquaint Softtech serves.
Region / hiring model | Senior DevOps (in-house) | Eastern Europe (agency) | Acquaint Softtech (India) |
UK | GBP 80,000-110,000/year fully loaded | GBP 60-80/hour | $22/hour | $3,200/month |
Germany / DACH | EUR 90,000-120,000/year fully loaded | EUR 70-90/hour | $22/hour | $3,200/month |
Netherlands / Benelux | EUR 85,000-115,000/year fully loaded | EUR 65-85/hour | $22/hour | $3,200/month |
France / Southern EU | EUR 70,000-100,000/year fully loaded | EUR 55-75/hour | $22/hour | $3,200/month |
US | $130,000-180,000/year fully loaded | $80-110/hour | $22/hour | $3,200/month |
Security sprint saving (8 layers, 2-3 weeks) | N/A (in-house, always on) | EST 3-4x Acquaint rate | $1,760 to $3,168 total |
Security engagement scope | Cost at $22/hour | What is delivered |
Security audit of existing cluster (gap assessment) | 2 to 3 days: $352 to $528 | Written findings report: which of the 8 layers are missing, risk rating, remediation priority order |
Layers 1 to 3 (Pod Security, Network Policies, Secrets) | 4 to 6 days: $704 to $1,056 | Non-root containers enforced, default-deny network policies, Vault or ESO integration |
Layers 4 to 6 (RBAC, Admission Controllers, Image Scanning) | 4 to 7 days: $704 to $1,232 | Least-privilege RBAC, Gatekeeper or Kyverno policies, Trivy CI/CD integration |
Layers 7 to 8 (Falco, Audit Logging) | 2 to 4 days: $352 to $704 | Falco DaemonSet with alert routing, K8s API audit logging, CloudWatch retention |
Full 8-layer security sprint (SOC 2 ready) | 10 to 18 days: $1,760 to $3,168 | Complete Kubernetes security hardening. SOC 2 control evidence prepared. |
Monthly retainer (security + cluster management) | $3,200/month | Ongoing: policy updates, vulnerability monitoring, quarterly RBAC review, incident response |
UK, Europe, or US SaaS: Preparing for SOC 2 With a Kubernetes Infrastructure?
Acquaint Softtech DevOps engineers have implemented all 8 Kubernetes security layers for SaaS products in the UK, Germany, Netherlands, and US preparing for SOC 2 and ISO 27001. Tell us your timeline and current security posture. Matched profile in 24 hours.
Acquaint Softtech's hire DevOps developers service provides pre-vetted engineers with Kubernetes security hardening experience including SOC 2 control implementation. Starting at $22/hour or $3,200/month.
For the full DevOps engineer rate comparison across UK, Europe, and US, the DevOps engineer cost guide covers what each price tier delivers.
Individual DevOps engineer on a monthly retainer through our staff augmentation model. Starting at $22/hour or $3,200/month. Available in 48 hours.
For large cluster security management at scale, the managing 200+ Kubernetes workloads guide covers how senior engineers run RBAC governance and admission controller policies across 200+ workloads.
Frequently Asked Questions
-
What security does a DevOps engineer implement on Kubernetes?
A complete Kubernetes security stack covers 8 layers: Pod Security Standards (non-root containers), Network Policies (zero-trust pod networking), Secrets Management (Vault or Secrets Manager via External Secrets Operator), RBAC with least-privilege, Admission Controllers (Gatekeeper or Kyverno), Image Vulnerability Scanning, Runtime Security (Falco), and Audit Logging.
-
How do you secure containers running on Kubernetes?
The primary container security controls are: running as non-root (Pod Security Standards enforce this), using read-only root filesystems, dropping all Linux capabilities and adding only required ones, disabling privilege escalation, and scanning the container image for known CVEs before deployment. These are configured in the container's security context and enforced by admission controllers.
-
What is a Kubernetes Network Policy and why does it matter?
A Kubernetes Network Policy is a firewall rule that defines which pods can communicate with which other pods. By default, all pods can reach all other pods. A default-deny network policy blocks all traffic and requires explicit allow rules. This prevents a compromised frontend pod from directly accessing the database or other internal services it should not reach.
-
What is Falco and how does it protect Kubernetes?
Falco is a runtime security tool that detects unexpected behaviour inside containers at runtime. It monitors system calls and generates alerts when a container does something suspicious: opens a shell, reads sensitive files, makes unexpected network connections. Falco detects exploitation that occurs after a container has been compromised, even if the other security controls were bypassed.
-
How does Kubernetes security support SOC 2 compliance?
SOC 2 requires evidence of access controls, encryption, monitoring, change management, and vulnerability management. A Kubernetes security stack provides evidence for all five: RBAC demonstrates access control, Network Policies and TLS demonstrate encryption, Falco and audit logging demonstrate monitoring, Gatekeeper demonstrates change control, and image scanning demonstrates vulnerability management.
-
How much does Kubernetes security hardening cost in the UK and Europe?
A full 8-layer security sprint costs $1,760 to $3,168 at Acquaint Softtech's $22/hour rate. Compared to a UK senior DevOps engineer at GBP 80,000 to 110,000 per year fully loaded, or a German/Dutch engineer at EUR 85,000 to 120,000 per year, Acquaint Softtech delivers the same security implementation at a fraction of the ongoing cost.
-
What is the difference between Gatekeeper and Kyverno for Kubernetes policy?
OPA Gatekeeper uses Rego, a purpose-built policy language, to define admission control policies. Kyverno uses YAML-based policies that are more accessible for DevOps engineers familiar with Kubernetes manifests. Both enforce the same types of policies. Kyverno is recommended for teams new to admission controllers; Gatekeeper is preferred for complex enterprise policy requirements.
Taukir Katava is a DevOps Engineer at Acquaint Softtech with 4+ years of experience across AWS, Azure, and GCP. He specialises in Kubernetes cluster administration, CI/CD pipeline automation, and cloud infrastructure design for high-traffic platforms. Taukir writes about the practical side of production DevOps: what infrastructure decisions cost and what they actually deliver.
Table of Contents
Get Started with Acquaint Softtech
- 13+ Years Delivering Software Excellence
- 1300+ Projects Delivered With Precision
- Official Laravel & Laravel News Partner
- Official Statamic Partner
Related Reading
DevOps Engineer for SaaS Startup: What to Budget and What to Expect in the First 90 Days
A SaaS startup's first DevOps engagement costs $3,200/month. Here is exactly what gets built in each of the first 90 days, what to budget, and what to expect from a DevOps engineer at each stage.
Mukesh Ram
June 3, 2026
Kubernetes Cost Optimisation With Spot Instances: How a DevOps Engineer Reduces Your Cloud Bill by 60 to 80%
AWS Spot Instances reduce Kubernetes node costs by 60 to 80%. Here is what a DevOps engineer configures to make Spot work safely in a production K8s cluster and what you save.
Taukir K
June 10, 2026
The Complete Guide to Hiring a DevOps Engineer in 2026: CI/CD, Cloud, Kubernetes, and What It All Costs
Everything you need before hiring a DevOps engineer in 2026. What the role covers, CI/CD to Kubernetes, what it costs in India vs the US, and how to start with a vetted engineer in 48 hours.
Acquaint Softtech
May 1, 2026India (Head Office)
203/204, Shapath-II, Near Silver Leaf Hotel, Opp. Rajpath Club, SG Highway, Ahmedabad-380054, Gujarat
USA
7838 Camino Cielo St, Highland, CA 92346
UK
The Powerhouse, 21 Woodthorpe Road, Ashford, England, TW15 2RP
New Zealand
42 Exler Place, Avondale, Auckland 0600, New Zealand
Canada
141 Skyview Bay NE , Calgary, Alberta, T3N 2K6