10 Kubernetes Security Best Practices for 2026

Your cluster probably looks “fine” right up until the first serious review, customer questionnaire, or incident retrospective. Then the gaps show up fast. East-west traffic is wide open. Service accounts can do more than anyone intended. Pods still run as root because an old base image needed it once and nobody came back to fix it. Secrets live in places they shouldn’t. The result isn’t usually one dramatic mistake. It’s a pile of defaults, exceptions, and half-finished hardening work.

That’s why most advice on kubernetes security best practices falls short. It tells you what features exist, but not what to prioritize, what to automate, and what tends to break when you enforce controls in a live platform.

A default Kubernetes environment is still too trusting for production. Any pod may be able to talk to any other pod unless you stop it. Many teams still carry risky runtime settings and weak workload isolation even after buying the right tooling. Kubernetes security tool adoption has risen from under 35% in 2022 to over 50% in 2025, yet misconfigurations remain common, including root execution, image issues, and deprecated Helm usage, according to Dynatrace’s Kubernetes in the Wild report at https://www.dynatrace.com/resources/ebooks/kubernetes-in-the-wild/.

The pattern I’ve seen repeatedly is simple. Teams adopt scanners and dashboards first, then postpone the hard operational work of policy, identity, and enforcement. That order needs to flip.

The plan below is opinionated on purpose. Start with controls that reduce blast radius. Put every rule in code. Use Terraform for platform foundations, GitOps for cluster state, and OPA or Kyverno for admission control. If a security decision can’t survive version control, pull requests, and repeatable rollout, it won’t survive production either.

1. Implement Network Policies and Zero-Trust Architecture

If you only fix one thing this quarter, fix east-west traffic.

Most clusters still behave like a flat internal network. Once an attacker lands in one pod, lateral movement becomes far easier than it should be. Red Hat found that vulnerabilities and misconfigurations are top concerns for Kubernetes teams, and two-thirds delay deployments because of security risk in Kubernetes environments at https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview. That hesitation is rational when pod-to-pod traffic is mostly implicit.

Start with deny-all, then earn exceptions

A zero-trust model in Kubernetes means no workload gets network access just because it shares a cluster. Every allowed path should be explicit.

Use namespace and pod labels that reflect real trust boundaries, not just app names. A payment API, a background worker, and an observability agent shouldn’t all inherit the same network assumptions because they shipped from the same repo.

A practical first rollout usually looks like this:

• Apply default deny policies first: Block ingress and egress at the namespace level before carving out exceptions.
• Allow DNS deliberately: Many teams break workloads on day one because they forget kube-dns or CoreDNS traffic.
• Separate platform traffic from app traffic: Monitoring, admission controllers, and ingress controllers need their own clearly defined routes.
• Store policy with workload manifests: Keep Calico or Cilium policy YAML in the same GitOps repo as the deployment it protects.

Practical rule: If a developer can’t explain why one workload needs to talk to another, the connection probably shouldn’t exist.

Use eBPF where visibility matters

Cilium is often a better fit than older CNI setups when you need policy enforcement and runtime visibility in one place. eBPF-based networking gives you more context without forcing a service mesh rollout just to answer basic traffic questions.

That matters because zero-trust isn’t just about blocking traffic. It’s about seeing failed attempts, debugging policy safely, and proving isolation in regulated environments.

A simple default deny policy often starts like this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

After that, add narrow allow rules for ingress from your API gateway, egress to DNS, and any approved dependencies.

Once you have the basics in place, this walkthrough is useful for visualizing policy behavior in practice.

2. Enforce RBAC and Least Privilege

I rarely see a compromised cluster that had “too little” access. I see clusters where service accounts, CI bots, and human operators all had broad permissions because it was faster at the time.

That shortcut sticks around for years.

Audit what’s in use

Dynatrace notes that 90% of unused cloud privileges indicate overprovisioning and recommends auditing RBAC as a practical benchmark for tighter access control in hybrid environments at https://www.dynatrace.com/resources/ebooks/kubernetes-in-the-wild/. In Kubernetes, that usually shows up as ClusterRoles granted for convenience when a namespaced Role would’ve been enough.

Start by checking effective permissions, not just YAML intent. Use kubectl auth can-i with impersonation flags and test from the perspective of each service account that matters.

kubectl auth can-i get secrets -n prod --as system:serviceaccount:prod:api
kubectl auth can-i create clusterrolebindings --as system:serviceaccount:cicd:deployer

You want your deployment bot to deploy. You don’t want it editing RBAC, reading all secrets, or mutating unrelated namespaces.

Split access by actor, not by convenience

A workable model is boring by design:

• Developers get namespaced read and deploy rights: They don’t need cluster-admin for normal delivery work.
• Platform operators manage cluster-scoped resources: Ingress classes, CRDs, and storage classes stay with a smaller group.
• Security teams review policy and exceptions: They shouldn’t need broad day-to-day write access to application namespaces.
• Each workload gets its own service account: Shared service accounts hide blast radius and make audits painful.

Here’s a tight namespaced role for a deployment controller:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: apps-prod
  name: deployer
rules:
- apiGroups: ["", "apps"]
  resources: ["deployments", "services", "configmaps", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Pair that with external identity for humans and avoid local credential sprawl where possible. If you’re tightening admin workflows around privileged access, this overview of Privileged Access Management is relevant to the broader operating model too.

3. Use Pod Security Standards and OPA Gatekeeper for Policy Enforcement

Many teams get stuck on this point. They know Pod Security Policies are gone. They know they should move to Pod Security Standards. They still postpone the migration because legacy workloads don’t survive restricted settings on the first pass.

That’s understandable, but it’s also risky.

A 2024 CNCF survey cited by SUSE found that 62% of respondents were still using deprecated PSPs, and that correlated with higher misconfiguration rates in runtime scans at https://www.suse.com/c/best-practices-for-keeping-kubernetes-secure/.

Migrate in phases, not in one big policy swing

Pod Security Standards work best when you stage them:

1. Label namespaces with Baseline in audit and warn mode
2. Fix noisy violations
3. Move critical namespaces to Restricted
4. Use Gatekeeper for custom controls PSS doesn’t cover

PSS gives you strong built-in guardrails. Gatekeeper gives you the organization-specific layer. That includes registry allowlists, mandatory labels, required seccomp profiles, and exception handling with reviewable policy code.

If you need a deeper background on policy design, this guide on Open Policy Agent is worth reviewing alongside your cluster rollout plan.

Enforce non-root and block privileged patterns

Dynatrace reported that many organizations run a substantial portion of workloads as root users, which is exactly why “we’ll fix it later” keeps leading to ugly runtime risk. The cleanest move is to reject bad pod specs at admission time and make exceptions explicit.

A Gatekeeper constraint can enforce non-root execution:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: disallow-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot

Restricted policies work best when you pair them with an exemption process that expires. Permanent exceptions become your real baseline.

Also expect some friction. The PSS transition isn’t just a technical cleanup. It changes how teams package workloads, especially older vendor software that assumes root, writable filesystems, or broad Linux capabilities.

4. Secure Container Images and Implement Supply Chain Security

If your image pipeline is weak, everything after it becomes compensating control.

I’ve seen teams invest heavily in runtime tooling while still allowing unsigned images, stale base layers, and inconsistent registry rules into production. That’s backwards. The cluster shouldn’t be the first place you discover trust problems.

Treat image admission like a release gate

Your CI/CD system should build, scan, sign, attest, and publish images before GitOps ever references them. If the image fails one of those stages, it shouldn’t get a deployable tag.

That usually means:

• Scan on build: Catch known issues before push.
• Sign on publish: Use Cosign so the image carries verifiable identity.
• Generate an SBOM: Keep provenance attached to the artifact.
• Verify at admission: Reject images that aren’t signed or don’t come from approved registries.

The broader discipline is software provenance, not just vulnerability scanning. Many teams benefit from formalizing a supply chain security approach here, rather than bolting a scanner onto an otherwise loose release process.

Build smaller, stricter, and repeatable images

The fastest win is reducing what goes into the image in the first place. Distroless bases, pinned dependencies, and explicit package installs remove a lot of noise.

A simple Cosign flow is straightforward:

cosign sign --key cosign.key registry.example.com/payments/api:1.4.2
cosign verify --key cosign.pub registry.example.com/payments/api:1.4.2

Then enforce signature verification with Gatekeeper, Kyverno, or a cloud-native admission control option.

Supply chain security also lives inside delivery habits. Strong CI/CD pipeline best practices help in this area. The security team shouldn’t manually bless images after the fact. The pipeline should produce trusted artifacts by default.

One more thing that gets missed. Re-scan images already sitting in the registry. New vulnerabilities appear after the build. A “clean” image last month can become your next incident if nobody rechecks it.

5. Implement Secret Management and Encrypted Data at Rest

Kubernetes Secrets are not a secret management strategy by themselves. They’re a distribution mechanism.

That distinction matters because many teams still hardcode secrets into Helm values, commit encrypted blobs without a clear rotation process, or let long-lived credentials spread across namespaces. Once that happens, cleanup is harder than the original fix.

Use external secret stores and short-lived access

The better pattern is simple. Store the source of truth outside the cluster. Sync only what workloads need. Prefer workload identity over static cloud credentials whenever you can.

A practical stack often looks like this:

• External Secrets Operator for sync: Pull from Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager.
• Cloud KMS for etcd encryption: Protect secret data at rest.
• Workload identity for cloud access: Avoid embedding keys in pods.
• Rotation pipelines: Treat secret rollover as routine platform work, not an incident-only task.

Here’s a minimal External Secrets example:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db-credentials
  namespace: billing
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: billing/database
        property: password

Encrypt etcd and stop leaking through convenience

Secrets in etcd should be encrypted at rest. In managed platforms, wire this into the cloud KMS service and keep the config under Terraform so you can prove it wasn’t a one-off console click.

Also remove the common anti-patterns:

• No secrets in ConfigMaps
• No secrets baked into images
• No shared credentials across unrelated services
• No manual copy-paste into GitOps repos

What works in practice is boring and repeatable. The application team references a Kubernetes Secret. External Secrets Operator populates it from a real secret manager. The cloud identity behind that access is short-lived and scoped.

That’s far safer than asking every team to manage encryption discipline on its own.

6. Enable Audit Logging and Observability for Security Events

Without audit trails, you don’t know who changed what. Without runtime observability, you don’t know what the workload did after the change.

Many teams have one or the other. Fewer have both wired together well.

Keep the API trail and runtime trail in the same conversation

Red Hat reports that 45% of organizations hit runtime incidents, 44% dealt with build and deploy vulnerabilities, and 40% reported misconfigurations in Kubernetes environments at https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview. Those categories overlap in real incidents. A weak RBAC change can lead to a bad deployment, which then creates suspicious runtime behavior.

That’s why separate dashboards aren’t enough. You need correlation.

Log API server activity. Capture high-signal runtime events from tools like Falco or eBPF-based sensors. Ship both into the same central system where responders can follow the sequence, not just individual alerts.

A tight audit policy might increase detail for sensitive objects while keeping the rest at metadata level:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  - level: Metadata
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

Alert on actions, not just infrastructure symptoms

Too many alerting stacks focus on CPU spikes and pod restarts, then call it observability. Security observability needs behavior that means something.

Watch for events such as:

• New ClusterRoleBinding creation: Often a sign of privilege expansion.
• Unexpected secret reads: Especially from service accounts that don’t normally touch them.
• Exec into production pods: Sometimes legitimate. Often worth review.
• Denied admission requests: A useful signal that teams are pushing against policy boundaries.

If you’re centralizing this into a broader detection workflow, a platform approach to security incident and event management systems helps connect cluster telemetry with cloud and identity logs.

You don’t need every event. You need enough context to reconstruct intent, sequence, and blast radius quickly.

7. Implement Runtime Security and Vulnerability Detection

Static controls catch known bad inputs. Runtime security catches what still gets through.

That includes abused credentials, container escapes, unexpected binaries, suspicious syscalls, and zero-day behavior that wasn’t visible in the image scan. This area stays underserved because it’s harder to tune and easier to postpone.

SUSE’s 2025 data highlights the problem. It found that 28% of organizations run workloads with insecure capabilities, which keeps privilege escalation paths open. AccuKnox also cites test results where KubeArmor blocked malware more effectively than Pod Security Context alone at https://accuknox.com/blog/kubernetes-security-best-practices.

Watch process behavior, not just network flows

Network policies matter, but they won’t tell you that a shell appeared in a container that normally runs one binary and exits. They also won’t catch host interaction attempts on their own.

That’s where runtime agents and eBPF-based tools earn their place. Falco is still a common starting point. KubeArmor and Cilium Tetragon are strong options when you want syscall visibility and enforcement with modern kernel hooks.

A basic Falco rule can flag shell spawns in containers:

- rule: Terminal shell in container
  desc: Detect a shell spawned inside a container
  condition: container and shell_procs
  output: "Shell spawned in container (user=%user.name container=%container.id command=%proc.cmdline)"
  priority: WARNING

Tune for your workloads or you’ll ignore the alerts

Runtime security fails when teams deploy default rules, drown in noise, and then mute the channel.

Do this instead:

• Baseline each workload type: Batch jobs, APIs, and operators behave differently.
• Route alerts by severity and ownership: A platform team shouldn’t manually triage every low-signal app event.
• Automate narrow responses: Kill a pod, snapshot evidence, or isolate traffic based on rule severity.
• Review detections after every incident: Your runtime rules should evolve with the platform.

One useful contrarian point from the field. Service meshes are not runtime protection. They help with transport policy. They don’t replace syscall, process, and host interaction monitoring.

8. Secure Ingress and API Gateway Configuration

Ingress is where convenience creates exposure fastest.

You need teams to ship features quickly, publish APIs, terminate TLS, and integrate with identity. But if ingress and gateway policy drift across namespaces, every team effectively invents its own edge security model.

Standardize the edge stack

Don’t let each application define TLS, auth, and rate limits from scratch. Build a platform-approved ingress pattern and roll it through GitOps.

For many teams, that baseline should include:

• TLS everywhere: Use cert-manager and automate renewal.
• OIDC or OAuth2 at the edge: Push user auth up to the gateway where possible.
• WAF integration for internet-facing services: Especially for public APIs and admin endpoints.
• Consistent security headers: HSTS, X-Frame-Options, X-Content-Type-Options, and CSP where relevant.
• Rate limiting: Stop brute force and noisy clients before they hit the app.

A small NGINX ingress example shows the pattern:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  namespace: customer
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/limit-rps: "10"
spec:
  ingressClassName: nginx
  tls:
    - hosts: ["api.example.com"]
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80

Roll out mTLS gradually inside the platform

If you use Istio, Linkerd, or Kong mesh features, don’t force strict mTLS cluster-wide on day one. Start with a permissive posture in selected namespaces, validate telemetry, then tighten.

This is one of those areas where teams over-engineer quickly. A full mesh isn’t automatically more secure than a clean ingress layer plus network policies plus workload identity. Use a mesh when you need service identity, traffic policy, and observability. Don’t adopt it as a branding exercise.

A secure edge is a product decision as much as an infrastructure decision. Standardize it like one.

9. Maintain Cluster Patching and Version Management

Patching matters, but not in the simplistic “just upgrade everything immediately” way people like to say.

The practical challenge is balancing support windows, workload compatibility, node image hygiene, and delivery stability. Datadog’s 2025 analysis found that 78% of organizations run mainstream supported Kubernetes versions, which shifts attention toward runtime risk rather than version lag alone. Red Hat’s data also says 42% still under-invest in Kubernetes security despite broad DevSecOps initiatives. Both points are summarized in the Red Hat market overview at https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview.

Upgrade through infrastructure code, not calendar reminders

Treat cluster versioning and node refresh as part of the platform repo, not tribal operational knowledge. Terraform, OpenTofu, or Terragrunt should define control plane versions, node pool settings, maintenance windows, and rollout strategy.

That creates a repeatable pattern:

• Stage the version bump in lower environments
• Validate admission controllers and CRDs
• Refresh node images, not just Kubernetes versions
• Use surge or rolling node replacement
• Protect critical services with Pod Disruption Budgets

A Terraform example on a managed platform might pin a cluster version while node pools roll independently:

resource "google_container_cluster" "platform" {
  name               = "platform-prod"
  location           = var.region
  min_master_version = var.k8s_version
}

Watch deprecations before they become outages

Version management isn’t just CVEs. It’s API compatibility, removed beta resources, admission changes, and policy behavior shifts.

The Pod Security Standards transition is a good example. Teams that ignored deprecation warnings ended up combining an upgrade project with a security migration and an application refactor. That’s how routine patching turns into a quarter-long disruption.

Good patching is boring. It’s tested, scheduled, and code-driven. That’s exactly what you want.

10. Implement Workload Identity and Service Account Management

Long-lived credentials inside containers are still one of the most common self-inflicted risks in Kubernetes.

If a pod needs access to S3, BigQuery, Key Vault, or a managed database, don’t inject static cloud keys and hope rotation happens later. Bind workload identity directly to the service account the pod uses.

One workload, one identity, one narrow purpose

A service account should represent a real application boundary, not a namespace-wide convenience object.

That means:

• Create a dedicated Kubernetes service account per deployment
• Bind it to a cloud identity with only required permissions
• Scope audience and token usage where the platform supports it
• Monitor who uses the identity and when

In this scenario, least privilege becomes practical instead of abstract. The app that writes to one bucket doesn’t need wildcard storage access. The worker that reads one queue doesn’t need broad account-level rights.

A simple EKS IRSA style service account looks like this:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: reports-api
  namespace: analytics
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/reports-api-role

Clean up forgotten service accounts aggressively

Identity sprawl creeps in unnoticed. Old deployments leave behind service accounts. CI systems keep stale bindings. Shared namespaces accumulate roles nobody can explain.

Review and prune them on a schedule. If an identity hasn’t been used, either remove it or justify it in code. This is one of the easiest security wins because it usually reduces confusion for operators too.

Done well, workload identity also supports secret reduction. The fewer static credentials you distribute, the fewer credentials you need to rotate, audit, and recover after an incident.

Kubernetes Security Best Practices - 10-Item Comparison

From Checklist to Culture: Embedding Security in Your Platform

The hard truth about kubernetes security best practices is that the list itself isn’t the hard part. Many teams already know the themes. Use RBAC. Lock down pods. Scan images. Protect secrets. Patch clusters. The gap is operational discipline. Security controls exist, but they live in too many places, rely on too many manual approvals, and drift too easily from one environment to the next.

That’s why the strongest Kubernetes programs don’t treat security as a separate lane. They fold it into platform engineering. Terraform or OpenTofu defines the cluster baseline. GitOps tools like ArgoCD or FluxCD carry application and policy changes through the same review path. OPA Gatekeeper or Kyverno enforces the rules that teams agreed to before the deploy happens. Observability tools collect both operational and security signals so incident response isn’t split across disconnected systems.

This approach matters because adoption alone doesn’t fix exposure. Dynatrace reports that 89% faced at least one incident across build, deploy, or runtime phases in the last year, and it recommends unifying observability and security data for context-aware threat detection in Kubernetes environments at https://www.dynatrace.com/resources/ebooks/kubernetes-in-the-wild/. That’s the key shift. Security gets stronger when teams stop managing it as scattered controls and start managing it as versioned platform behavior.

There’s also a maturity issue many organizations underestimate. Red Hat found that 90% are pursuing DevSecOps, but only 42% are at advanced stages and 10% still operate in silos, according to the same Red Hat overview cited earlier. That gap explains a lot of what happens in the field. A company may have scanners, policies, and dashboards, yet still struggle to turn those tools into fast, low-drama engineering habits. The difference comes from standardization and ownership.

In practice, culture shows up in small decisions:

• A namespace isn’t created manually. It comes from code with labels, quotas, and baseline policy attached.
• A new service account isn’t granted broad access because someone is blocked. It gets a narrow role, reviewed in a pull request.
• An image doesn’t land in production because someone says it’s probably fine. It arrives signed, scanned, and tied to provenance.
• A policy exception doesn’t live forever. It expires, gets revisited, and leaves an audit trail.

That marks the transition from checklist to culture. Security stops being a side project and becomes part of how the platform ships changes.

The trade-off is obvious. This model asks more from engineering up front. Teams need better repos, better review habits, and clearer ownership boundaries. Some legacy workloads won’t pass restricted pod policies without changes. Some developers will push back on denied traffic or stricter service account permissions. Some deployment flows will slow down briefly while guardrails settle in.

That friction is normal. What matters is whether the friction happens in pull requests and staging environments, or during incidents and audits in production. Elite teams choose the first option every time.

If you need outside help implementing that operating model, CloudCops GmbH is one option for teams building and securing cloud-native platforms with Terraform, GitOps, observability, and policy-as-code. That kind of partner is useful when the challenge isn’t knowing the controls, but wiring them into a platform your team can run.

The end state isn’t perfect security. Kubernetes won’t give you that. The end state is a platform where risk is reduced systematically, drift is visible, controls are testable, and recovery is fast when something still goes wrong. That’s what mature security looks like in modern Kubernetes environments.

If your team needs help turning these kubernetes security best practices into Terraform modules, GitOps policies, RBAC models, runtime controls, and auditable delivery workflows, talk to CloudCops GmbH. They work with startups, SMBs, and enterprises to co-build secure cloud-native platforms across AWS, Azure, and Google Cloud.

Continue Reading

Read Unlock Cloud Security with Policy as Code

Apr 8, 2026

Unlock Cloud Security with Policy as Code

Learn how to implement policy as code to automate cloud security, compliance, & cost controls. Our 2026 guide covers OPA, Kubernetes, & Terraform.

policy as code

+4

C

CloudCops

Read A Complete Guide to Open Policy Agent for Cloud Security

Mar 13, 2026

A Complete Guide to Open Policy Agent for Cloud Security

Discover everything about Open Policy Agent (OPA) for modern cloud security. Our guide explains Rego, use cases with Kubernetes and IaC, and best practices.

open policy agent

+4

C

CloudCops

Read 10 Cloud Security Best Practices for 2026

Apr 3, 2026

10 Cloud Security Best Practices for 2026

Master our top 10 cloud security best practices for 2026. Secure your cloud-native platforms on AWS, Azure, and GCP with actionable steps and examples.

cloud security best practices

+4

C

CloudCops