Kubernetes Security Best Practices for Production Workloads

Kubernetes Security Is Not Optional

Kubernetes adoption is accelerating across Indian enterprises, from fintech to e-commerce to healthcare. But too often, security is treated as an afterthought -- clusters are deployed with default configurations that leave critical workloads exposed.

A misconfigured Kubernetes cluster is not just a security risk. It is a compliance liability, especially under DPDPA requirements for reasonable security safeguards. This guide covers the security practices that should be in place before any production workload touches your cluster.

Pod Security Standards

Kubernetes Pod Security Standards define three profiles that control what pods are allowed to do.

Restricted Profile (Recommended for Production)

The most secure profile. Pods must: - Run as non-root user - Use read-only root filesystem - Drop all Linux capabilities - Disallow privilege escalation - Disallow host namespace sharing (hostPID, hostIPC, hostNetwork)

Baseline Profile (Minimum for Any Environment)

Prevents known privilege escalations while being less restrictive: - No privileged containers - No hostPath volumes - No host networking or ports - Restricted volume types

Implementation

Enable Pod Security admission at the namespace level: - Production namespaces: Enforce the Restricted profile - Development namespaces: Enforce the Baseline profile, warn on Restricted violations - System namespaces: Apply appropriate exceptions for cluster components

Network Policies

By default, Kubernetes allows all pods to communicate with all other pods. This is convenient for development but dangerous in production.

Default-Deny Ingress

Start by denying all ingress traffic to every namespace, then explicitly allow what is needed: - API pods receive traffic only from the ingress controller - Database pods receive traffic only from their application pods - Internal services communicate only with known peers

Namespace Isolation

Use network policies to isolate namespaces: - Production workloads cannot communicate with development namespaces - Each team's namespace is isolated from other teams - Shared services (DNS, monitoring) are accessible from all namespaces via explicit policies

Egress Control

Limit outbound traffic to prevent data exfiltration: - Allow DNS resolution (port 53) to the cluster DNS service - Allow HTTPS (port 443) to specific external services - Block all other egress by default

RBAC and Service Accounts

Least Privilege Roles

• Create custom roles with minimum required permissions for each team and service
• Never use cluster-admin for application workloads
• Separate read-only roles (for dashboards and monitoring) from write roles (for deployments)
• Audit RBAC bindings quarterly and remove stale entries

Service Account Best Practices

• Create dedicated service accounts for each application (do not use the default)
• Disable automatic token mounting (automountServiceAccountToken: false) on service accounts that do not need API access
• Use short-lived tokens via the TokenRequest API instead of long-lived secrets
• Bind service accounts to minimal roles

Human Access

• Integrate Kubernetes authentication with your SSO provider (OIDC)
• Enforce MFA for cluster access
• Use just-in-time access for production cluster modifications
• Audit all kubectl commands via API server audit logging

Image Security

Trusted Base Images

• Use minimal base images (distroless, Alpine) to reduce attack surface
• Pin image tags to specific digests, not mutable tags like latest
• Maintain a curated list of approved base images
• Rebuild images regularly to pick up security patches

Vulnerability Scanning

Scan images at every stage: - Build time: Scan in CI/CD pipeline using Trivy, Snyk, or Grype - Registry: Enable automatic scanning in your container registry (ECR, ACR, GCR) - Runtime: Deploy admission controllers that block images with critical vulnerabilities - Continuous: Re-scan running images weekly to catch newly disclosed CVEs

Image Signing

• Sign images using Cosign (Sigstore project) or Notary
• Deploy admission controllers (Kyverno, OPA Gatekeeper) that verify signatures before allowing deployment
• Reject unsigned images in production namespaces

Runtime Security

Seccomp and AppArmor

• Apply seccomp profiles to restrict system calls available to containers
• Use the RuntimeDefault seccomp profile as a minimum
• Build custom seccomp profiles for sensitive workloads based on their actual system call usage
• Enable AppArmor profiles where supported

Read-Only Root Filesystem

• Mount container root filesystems as read-only
• Use emptyDir volumes for temporary files
• This prevents attackers from modifying container binaries or installing tools

Runtime Threat Detection

Deploy runtime security monitoring: - Falco: Detects anomalous system calls, file access, and network connections in real-time - Alert on: shell execution in containers, unexpected outbound connections, file modifications in sensitive directories - Integrate alerts with your SIEM or incident response workflow

Secrets Management

Never Store Secrets in Images or Environment Variables

• Use Kubernetes Secrets with encryption at rest enabled
• Better: Use external secret stores (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Deploy the External Secrets Operator to sync external secrets into Kubernetes

Secret Rotation

• Implement automated secret rotation
• Use short-lived credentials where possible (IAM roles for service accounts, temporary database credentials)
• Audit secret access patterns and alert on unusual retrieval

Security Monitoring and Audit

API Server Audit Logging

Enable audit logging to capture: - Who accessed what resources and when - All changes to RBAC bindings and cluster configurations - Failed authentication attempts - Resource creation and deletion events

Cluster Hardening Validation

Regularly validate your cluster security posture: - Run CIS Kubernetes Benchmark checks using kube-bench - Use Polaris or Datree for workload configuration validation - Automate these checks in CI/CD and as periodic cluster scans

Getting Started

Security is not a one-time project. Start with these high-impact items:

1. Day 1: Enable Pod Security Standards (Restricted for prod, Baseline for dev)
2. Week 1: Implement default-deny network policies in production namespaces
3. Week 2: Audit and tighten RBAC bindings, disable default service account tokens
4. Week 3: Add image vulnerability scanning to your CI/CD pipeline
5. Week 4: Deploy Falco for runtime threat detection

At Optivulnix, we help organizations build security-first DevSecOps practices for Kubernetes environments. From cluster hardening to runtime monitoring, our team ensures your production workloads are protected without slowing down development. Contact us for a free Kubernetes security assessment.