Container Security 101: Kubernetes Hardening for Indian DevOps Teams

Kubernetes is secure by configuration, not by default. The controls that matter most.

Kubernetes has become the default platform for many Indian product teams, often adopted faster than the security practices around it. A default cluster is built to run workloads, not to resist an attacker. These are the controls we check first.

Control access to the cluster

• Keep the API server private, or restrict it to known networks.
• Use role-based access control with least privilege. Avoid binding cluster-admin to CI/CD service accounts or to developers for day-to-day work.
• Use your cloud provider’s identity integration rather than long-lived static credentials.
• Enable audit logging and send it somewhere the cluster’s administrators cannot erase.

Restrict what pods can do

PodSecurityPolicy was removed in Kubernetes 1.25. Use Pod Security Admission instead, applying the “restricted” profile wherever possible and “baseline” at minimum. In practice this means:

• Run containers as non-root, with a read-only root filesystem where possible.
• Drop Linux capabilities and disallow privilege escalation.
• No privileged containers, host networking or host path mounts for application workloads.

Segment the network

By default, every pod can reach every other pod. Apply a default-deny NetworkPolicy per namespace, then allow only the flows each service needs, including egress to the internet.

Handle secrets properly

Kubernetes Secrets are only base64-encoded unless you enable encryption at rest. Turn on envelope encryption with your cloud KMS, restrict who can read secrets, and consider an external secrets manager for high-value credentials.

Secure the supply chain

• Use minimal base images and scan them for vulnerabilities in CI.
• Sign images and verify signatures at admission, for example with Sigstore cosign and a policy engine such as Kyverno or OPA Gatekeeper.
• Allow images only from registries you control.

Watch at runtime

Runtime detection tools such as Falco can alert on suspicious behaviour, like a shell spawned inside a production container. Combine this with centralised logs retained long enough to meet CERT-In’s 180-day log retention direction.

Measure against a benchmark

The CIS Kubernetes Benchmark, checked with tools such as kube-bench, gives a repeatable baseline. Managed services like EKS, AKS and GKE handle much of the control plane, but workload configuration remains your responsibility.

This article is general information, not legal advice. Compliance services do not guarantee certification; certification bodies issue certificates.