Kubernetes Security: 8 Misconfigurations India Must Fix

Kubernetes security misconfigurations are the leading cause of container breaches worldwide — and Indian SaaS companies are no exception. Attackers do not need zero-days to compromise a Kubernetes cluster. Eight misconfigurations are found in the majority of real-world incidents: an exposed API server or dashboard, absent RBAC, privileged containers, missing network policies, secrets stored in environment variables, over-permissive default service accounts, unenforced pod security standards, and unscanned container images. Each misconfiguration is a door. Together, they form a highway from internet to database. This guide covers every misconfiguration, how attackers chain them, and how to close each gap — with India SaaS context throughout.

Why Indian SaaS Teams Are Especially Exposed

Indian product companies have adopted Kubernetes rapidly — managed clusters on AWS EKS, Google GKE, and Azure AKS are now default infrastructure. Speed of shipping, small platform teams, and copy-pasted Helm charts from the internet mean security defaults are rarely revisited after initial setup. Add a compressed regulatory environment (CERT-In 2022 incident-reporting rules, DPDP Act 2023 data protection requirements) and the blast radius of a cluster compromise extends well beyond service downtime into reportable data breaches.

The Attacker's Path: From Exposed API to Full Cluster Compromise

Before examining each misconfiguration, understand how they chain. Attackers rarely need all eight. Two or three chained together is enough for full cluster access.

Distribution of K8s Misconfiguration Types in Real-World Incidents

Approximate relative proportions based on incident patterns reported in the Red Hat State of Kubernetes Security (2024) and CNCF Annual Survey (2023). Actual share varies by environment and sector.

Misconfiguration 1 — Exposed API Server and Dashboard

The Kubernetes API server (port 6443) and the web dashboard (port 8001) are the front doors to your cluster. When either is exposed to the internet with anonymous authentication enabled, an attacker with a port scanner is already inside.

Anonymous authentication (--anonymous-auth=true) is disabled by default on managed clusters — but teams re-enable it for convenience and forget to reverse it. The Kubernetes dashboard, when deployed without a proper authenticating proxy, exposes full cluster control through a browser UI.

Fix: Restrict API server access to VPN/private network CIDRs only. Use --anonymous-auth=false. If you deploy the dashboard, front it with an OAuth2 proxy. Audit via:

kubectl get pods -n kubernetes-dashboard
kubectl auth can-i "*" "*" --as=system:anonymous

The second command returning yes for any verb is an immediate P0 finding.

Misconfiguration 2 — No RBAC or Wildcard Role Bindings

Role-Based Access Control (RBAC) is enabled by default in modern Kubernetes, but having RBAC enabled is not the same as having RBAC configured correctly. Common anti-patterns seen in Indian SaaS clusters:

1. ClusterRoleBinding granting cluster-admin to system:authenticated (every authenticated user is a superuser)
2. verbs: [""] and resources: [""] in custom roles
3. Granting secrets read access cluster-wide to application service accounts

Misconfiguration 3 — Privileged Containers

A container running with securityContext.privileged: true is effectively running as root on the host node. Combined with a writable /proc mount or /dev access, a container escape is trivial — the attacker walks from the container into the underlying EC2 or GCP VM and from there into the cloud IAM role attached to that node.

Crypto-mining groups have weaponised this specific path since 2019. It remains one of the most common post-exploitation techniques in Kubernetes incidents.

Fix: Set privileged: false and allowPrivilegeEscalation: false in every pod's security context. Drop all Linux capabilities and add back only what the specific workload needs.

securityContext:
  privileged: false
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  capabilities:
    drop:
      - ALL

Misconfiguration 4 — No Network Policies

By default, every pod in a Kubernetes cluster can talk to every other pod across every namespace. There are no firewall rules between workloads unless you explicitly write NetworkPolicy objects.

This means that if an attacker compromises a low-value microservice (say, a public-facing marketing API), they can immediately probe your payment service, internal admin API, and database pods on their private ClusterIPs — all from inside the cluster, with no perimeter to cross.

Fix: Start with a default-deny policy per namespace, then allow only the specific ingress and egress flows each workload actually needs. Tools like Cilium or Calico provide richer policy models than the base Kubernetes NetworkPolicy API.

Misconfiguration 5 — Secrets in Environment Variables

Kubernetes Secrets are base64-encoded, not encrypted, at rest by default. But the problem most teams overlook is that they put credentials directly in env: or in ConfigMap values — sometimes even hardcoding them in Deployment YAML committed to Git.

When an attacker has read access to the API (kubectl get pods -o yaml), they see every environment variable injected into every container. When a developer's laptop is compromised, every secret in every repo's YAML history is exposed.

Fix: Three layers are required:

1. Use Kubernetes Secret objects (not ConfigMaps or raw env values) for credentials
2. Enable Envelope Encryption at rest with a KMS provider (AWS KMS, GCP KMS) — base64 is not encryption
3. For production, migrate to a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) with dynamic short-lived credentials

Misconfiguration 6 — Default Service Accounts

Every pod in Kubernetes is automatically assigned the default service account in its namespace unless you specify otherwise. By default, this service account has a mounted token that can authenticate to the Kubernetes API.

If RBAC is weak (misconfiguration 2) or if the default service account has been granted excess permissions, any code running in any pod can query the API, list secrets, and escalate within the cluster — using nothing but the token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

Fix: Set automountServiceAccountToken: false on every pod that does not need to call the Kubernetes API. Create dedicated service accounts for workloads that do need API access, and bind them to narrowly scoped roles.

Misconfiguration 7 — Missing Pod Security Standards

Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25+. PSS defines three profiles — privileged, baseline, and restricted — that can be enforced at the namespace level via the built-in Pod Security Admission controller.

Most clusters — including fresh EKS and GKE clusters — ship with no PSS enforcement. This means pods can run as root, mount host paths, use host networking, and request privileged mode with zero cluster-level pushback.

Fix: Label production namespaces to enforce at minimum baseline, ideally restricted:

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

Enforce in audit mode first to catch violations without breaking workloads, then escalate to enforce.

Misconfiguration 8 — Unscanned Container Images

Running unscanned images means you have no visibility into the CVEs present in your running workloads. A container image pulling node:18 from Docker Hub today might include libraries with known remote code execution vulnerabilities published six months ago.

Indian SaaS teams frequently pull base images from public registries without scanning, and rely on cloud provider SLAs for the underlying infrastructure security — while remaining blind to application-layer vulnerabilities inside their own images.

Fix: Integrate image scanning into your CI pipeline before images are pushed to your registry. Tools like Trivy (open source), AWS Inspector, or GCP Artifact Analysis can scan images for known CVEs and fail the build on critical findings. Complement with admission controllers (OPA Gatekeeper, Kyverno) that block deployment of images without a clean scan certificate.

Kubernetes Security Hardening Checklist

Regulatory Context for Indian Companies

India's CERT-In Cyber Security Directions (April 2022) require organisations to report incidents — including those arising from infrastructure misconfigurations — within six hours of detection. A Kubernetes misconfiguration that leads to unauthorised data access is a reportable incident under these rules.

The DPDP Act 2023 adds data protection obligations that directly cover Kubernetes workloads handling personal data. Inadequate security controls — misconfigured clusters are an explicit example of inadequate controls — can result in regulatory action. If your cluster is processing personal data of Indian users, security hardening is not optional. Learn more about your obligations at the Bachao.AI /dpdp-compliance page.

CERT-In guidance is available at https://www.cert-in.org.in. The CNCF's security whitepaper (updated 2022) is a complementary reference at https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf.

How Bachao.AI Helps

Bachao.AI, built by Dhisattva AI Pvt Ltd, automates infrastructure and application security assessments — including detection of exposed Kubernetes endpoints, misconfigured RBAC, privileged container usage, and secrets in environment variables. Findings are delivered as structured, remediation-first reports with severity scoring aligned to CVSS v3.1 and CERT-In classification. Start with a free VAPT scan to get a baseline of your cluster's exposure before an attacker finds it for you.