OWASP Kubernetes Top Ten: K01:2022 – Insecure Workload Configurations

Introduction

Kubernetes has revolutionised container orchestration, providing software developers and architects with a scalable and efficient way to manage workloads. However, its complexity also introduces a range of security vulnerabilities, as highlighted by the OWASP Kubernetes Top Ten 2022. The first entry, K01:2022 – Insecure Workload Configurations, is a critical concern, as improperly configured workloads can expose applications to exploitation, data breaches, and unauthorised access.

This article provides an in-depth analysis of Insecure Workload Configurations, explaining its risks, real-world implications, best practices, and mitigation strategies.

Understanding Insecure Workload Configurations

What is an Insecure Workload Configuration?

An insecure workload configuration refers to the improper setup of Kubernetes workloads—Pods, Deployments, StatefulSets, and DaemonSets—resulting in vulnerabilities that attackers can exploit. These misconfigurations may stem from:

• Excessive privileges granted to workloads.
• Lack of security contexts enforcing least privilege.
• Exposed secrets and environment variables containing sensitive data.
• Insecure networking configurations, allowing unauthorised access.
• Unrestricted container execution leading to potential remote code execution (RCE).

In essence, an insecure workload configuration weakens the confidentiality, integrity, and availability (CIA) of the Kubernetes environment, posing severe business risks.

Real-World Risks of Insecure Workload Configurations

Misconfigurations in Kubernetes workloads have led to high-profile security incidents. Some real-world examples include:

1. Tesla’s Kubernetes Cryptojacking Incident

In 2018, Tesla’s Kubernetes cluster was misconfigured, exposing it to the internet without authentication. Attackers exploited this vulnerability to install cryptojacking malware, leveraging Tesla’s cloud resources to mine cryptocurrency.

2. Capital One Data Breach

In 2019, misconfigured IAM (Identity and Access Management) roles in Kubernetes allowed an attacker to escalate privileges, leading to the exfiltration of sensitive customer data from Amazon Web Services (AWS).

3. DockerHub and Kubernetes API Misconfiguration

A widespread misconfiguration in Kubernetes API settings led to unauthorised access to thousands of cloud-based container registries, exposing sensitive application images.

These cases highlight how improper workload configurations can lead to financial losses, reputational damage, and regulatory non-compliance.

Real-World Cyber Incidents and Breaches of Kubernetes

Kubernetes has become a prime target for cybercriminals due to its widespread adoption in cloud-native applications. Misconfigurations, unpatched vulnerabilities, and weak security controls have led to several high-profile cyber incidents. Below, we explore some of the most notable Kubernetes-related breaches, their causes, and lessons for software developers and architects.

1. Tesla’s Kubernetes Cryptojacking Attack (2018)

Incident Overview

Tesla suffered a cryptojacking attack after attackers compromised their Kubernetes cluster, which was exposed to the internet without authentication.

How the Attack Happened

• The Kubernetes admin console was accessible to the public without requiring authentication.
• Attackers gained access to Tesla’s Kubernetes pods and deployed cryptojacking malware to mine cryptocurrency (Monero).
• To evade detection, the hackers configured the mining scripts to operate in low CPU usage mode and routed traffic through an anonymous proxy.

Key Takeaways

✅ Always restrict access to the Kubernetes API Server and console.

✅ Disable anonymous access and enforce strong RBAC policies.

✅ Monitor CPU usage patterns to detect unusual activity, such as cryptojacking.

2. Capital One Data Breach (2019)

Incident Overview

One of the largest financial data breaches in history, Capital One lost over 100 million customer records due to a misconfigured Kubernetes IAM role in their AWS environment.

How the Attack Happened

• A former AWS employee exploited a misconfigured IAM role attached to a Kubernetes pod.
• Using Server-Side Request Forgery (SSRF), the attacker gained access to AWS metadata service credentials.
• The attacker exfiltrated sensitive customer data, including bank account numbers and Social Security numbers.

Key Takeaways

✅ Restrict IAM roles assigned to Kubernetes workloads.

✅ Use network security controls to block SSRF attacks.

✅ Regularly audit Kubernetes role bindings to prevent over-permissioned access.

3. Microsoft Azure Kubernetes Service (AKS) Vulnerability (2021)

Incident Overview

A vulnerability in Microsoft Azure’s Kubernetes Service (AKS) exposed thousands of clusters to privilege escalation attacks.

How the Attack Happened

• Researchers discovered that AKS default settings allowed privilege escalation.
• Attackers could gain control over Kubernetes service accounts and escalate privileges within the cluster.
• This could lead to data exfiltration, lateral movement, and unauthorised control of workloads.

Key Takeaways

✅ Do not rely on default cloud provider security settings—always harden configurations.

✅ Use least privilege principles for Kubernetes service accounts.

✅ Regularly scan managed Kubernetes services for new vulnerabilities.

4. Docker Hub and Kubernetes API Exposure (2019)

Incident Overview

A large-scale Kubernetes API exposure led to thousands of misconfigured Kubernetes clusters being indexed on Shodan (a search engine for exposed services).

How the Attack Happened

• Organisations left Kubernetes API servers publicly accessible, allowing attackers to:
  • List and control running pods.
  • Deploy malicious containers.
  • Access secrets stored within clusters.
• Several compromised clusters were used for cryptojacking and deploying malware-infected containers.

Key Takeaways

✅ Never expose Kubernetes API servers to the internet without authentication.

✅ Implement firewall rules and IP whitelisting to protect control plane access.

✅ Regularly check for exposed services using Shodan or Censys.

5. Argo CD Kubernetes Supply Chain Attack (2022)

Incident Overview

Argo CD, a popular Kubernetes continuous deployment tool, was found to have a critical security flaw that allowed attackers to retrieve sensitive data from Kubernetes secrets.

How the Attack Happened

• Argo CD’s insecure default configurations allowed attackers to inject malicious Helm Charts into deployments.
• Exploiting this, attackers could:
  • Access Kubernetes secrets from other applications.
  • Modify CI/CD pipelines to introduce malicious workloads.
  • Compromise the software supply chain by injecting backdoors into containers.

Key Takeaways

✅ Secure CI/CD pipelines and monitor for unauthorised deployments.

✅ Implement least privilege access for CI/CD tools interacting with Kubernetes.

✅ Regularly update Kubernetes tools to patch vulnerabilities.

6. Windows Kubernetes Cluster Exploit (2022)

Incident Overview

A zero-day vulnerability affecting Windows containers in Kubernetes allowed unauthenticated remote code execution (RCE).

How the Attack Happened

• Attackers exploited a flaw in Windows HostProcess containers, allowing them to run arbitrary commands on the host machine.
• This led to:
  • Complete cluster takeover.
  • Lateral movement across Kubernetes nodes.
  • Persistence mechanisms installed by attackers to maintain long-term access.

Key Takeaways

✅ Regularly apply security patches for Windows containers in Kubernetes.

✅ Use Linux-based workloads where possible, as they are better tested for Kubernetes security.

✅ Implement container runtime security to detect unauthorised execution.

Cyber Incidents on K01:2022 – Insecure Workload Configurations in India

India has seen rapid adoption of Kubernetes across industries such as banking, fintech, e-commerce, healthcare, and government services. However, this growth has also exposed organisations to misconfigured Kubernetes workloads, leading to cyberattacks, data breaches, and operational disruptions. The OWASP Kubernetes Top Ten K01:2022 – Insecure Workload Configurations highlights how poorly secured workloads can be exploited, leading to privilege escalation, container escapes, cryptojacking, and supply chain attacks.

This article examines real-world Kubernetes security incidents in India, their root causes, impact, and lessons learned.

1. Juspay Data Breach (2020) – Misconfigured Kubernetes Workload in a Payment Gateway

Incident Overview

Juspay, an Indian fintech company handling payments for Amazon, Swiggy, and Ola, suffered a data breach exposing over 100 million customer records.

Root Cause

• Attackers exploited a misconfigured Kubernetes workload, which lacked strict IAM (Identity and Access Management) policies.
• The container had excessive privileges, allowing attackers to access AWS S3 storage via exposed API keys.
• Server-Side Request Forgery (SSRF) was used to exfiltrate payment data.

Impact

• 100+ million card transaction records exposed.
• Attackers leaked customer names, phone numbers, and masked card details on the dark web.
• Reputational damage to Juspay and regulatory scrutiny.

Key Lessons

✅ Restrict Kubernetes workload permissions using the Principle of Least Privilege (PoLP).

✅ Rotate API keys and credentials regularly.

✅ Monitor for SSRF attacks to prevent access to internal workloads.

2. Mobikwik Data Breach (2021) – Unsecured Workload in Kubernetes Cluster

Incident Overview

Mobikwik, a popular Indian digital payments platform, suffered a massive breach involving 8.2 TB of customer data due to misconfigured Kubernetes workloads.

Root Cause

• The Kubernetes workload had unauthenticated access to sensitive backend services.
• Attackers exploited an exposed pod to access MongoDB and ElasticSearch databases.
• Data exfiltration occurred over multiple weeks before detection.

Impact

• Over 100 million customers’ KYC data exposed, including Aadhaar and PAN details.
• Financial fraud risks for affected users.
• Legal and regulatory consequences under India’s upcoming Data Protection Act.

Key Lessons

✅ Never expose Kubernetes workloads to the public internet without authentication.

✅ Use network policies to restrict pod-to-pod communication.

✅ Implement real-time workload monitoring to detect abnormal data access.

3. Indian Government Cloud (2022) – Misconfigured Workload Leading to Cryptojacking

Incident Overview

An Indian government cloud infrastructure was compromised when hackers deployed cryptojacking malware via insecure Kubernetes workloads.

Root Cause

• A Kubernetes workload was deployed without proper resource limits, allowing attackers to deploy cryptomining containers.
• Lack of runtime security monitoring led to delayed detection.
• Attackers used anonymous proxies to evade detection while mining Monero cryptocurrency.

Impact

• Government cloud compute resources hijacked, leading to performance degradation.
• Increased operational costs due to high CPU usage.
• Potential risk of lateral movement, allowing attackers to target sensitive government data.

Key Lessons

✅ Enforce resource limits on workloads to prevent abuse.

✅ Monitor unusual CPU activity to detect cryptojacking attempts.

✅ Use Kubernetes runtime security tools like Falco or Sysdig to detect suspicious workload behaviour.

4. India’s Healthcare Data Exposure (2022) – Kubernetes API Misconfiguration

Incident Overview

Security researchers found that multiple Indian hospitals and health tech companies exposed millions of patient records due to insecure Kubernetes API configurations.

Root Cause

• Kubernetes workload configurations were set to “AllowAll”, meaning anyone could query patient data.
• Attackers gained unauthorised access to Electronic Health Records (EHRs) by exploiting unprotected API endpoints.
• Some workloads had hardcoded credentials, allowing attackers to access databases.

Impact

• Sensitive health data of millions of Indian patients was exposed.
• Potential for identity theft and misuse of medical records.
• Regulatory violations under India’s upcoming Digital Personal Data Protection Bill (DPDPB).

Key Lessons

✅ Use Kubernetes Role-Based Access Control (RBAC) to limit API access.

✅ Remove hardcoded credentials from workloads.

✅ Encrypt sensitive healthcare data at rest and in transit.

5. Indian Stock Exchange DDoS Attack (2023) – Exploiting Misconfigured Workloads

Incident Overview

A Distributed Denial-of-Service (DDoS) attack targeted the Kubernetes-based trading infrastructure of a major Indian stock exchange, disrupting financial transactions.

Root Cause

• Kubernetes workloads lacked rate-limiting protections, allowing attackers to flood the APIs with millions of requests.
• Some workloads were exposed directly to the internet, making them vulnerable to botnet attacks.
• Attackers leveraged misconfigured ingress controllers to bypass security layers.

Impact

• Trading halted for hours, impacting financial markets.
• Revenue losses for brokers and traders.
• Increased scrutiny from SEBI (Securities and Exchange Board of India) on stock exchange cybersecurity.

Key Lessons

✅ Use API rate limiting to prevent abuse.

✅ Deploy Web Application Firewalls (WAFs) to protect Kubernetes workloads.

✅ Regularly test workload configurations for security weaknesses.

Common Insecure Workload Configurations

1. Running Containers as Root

By default, many container images execute processes as the root user. This can be catastrophic if an attacker gains control, allowing them to:

• Escalate privileges within the container.
• Move laterally across the cluster.
• Execute arbitrary commands on the underlying host.

Best Practice:

• Always set runAsNonRoot: true in the Pod security context.
• Use least privilege principles by defining a non-root user in the Dockerfile (USER 1001).

2. Privileged Containers

Privileged mode grants containers unrestricted access to the host system, including the ability to modify kernel parameters and bypass security controls.

Best Practice:

• Set privileged: false in the security context.
• Restrict hostPath mounts to limit access to the host filesystem.

3. Insecure Capabilities

By default, Kubernetes containers have certain Linux capabilities that can be exploited (e.g., CAP_SYS_ADMIN).

Best Practice:

Use the Pod Security Standards (PSS) to drop unnecessary capabilities:

securityContext:

  capabilities:

    drop:

      – ALL

4. Exposing Secrets in Environment Variables

Many developers hardcode secrets in environment variables, making them easily accessible if the container is compromised.

Best Practice:

• Use Kubernetes Secrets and mount them as volumes instead of exposing them in environment variables.
• Implement Secret Management Solutions such as HashiCorp Vault or AWS Secrets Manager.

5. Misconfigured Network Policies

By default, Kubernetes allows all workloads to communicate freely, creating a flat network that attackers can exploit.

Best Practice:

Implement strict network policies:

kind: NetworkPolicy

apiVersion: networking.k8s.io/v1

metadata:

  name: restrict-access

spec:

  podSelector:

    matchLabels:

      app: my-app

  policyTypes:

    – Ingress

  ingress:

    – from:

        – podSelector:

            matchLabels:

              app: trusted-app

• Enforce zero-trust networking to limit unnecessary access.
  

6. Running Outdated or Vulnerable Container Images

Containers built from outdated base images or images with known vulnerabilities can expose workloads to exploitation.

Best Practice:

• Use trusted base images from reputable sources.
• Regularly scan container images for vulnerabilities using tools like Trivy or Clair.

How to Mitigate Insecure Workload Configurations

1. Adopt Pod Security Admission (PSA) Policies

Kubernetes Pod Security Admission enforces security best practices at the namespace level. Use Restricted Mode to prevent insecure configurations:

apiVersion: policy/v1

kind: PodSecurityPolicy

metadata:

  name: restricted-policy

spec:

  privileged: false

  runAsUser:

    rule: MustRunAsNonRoot

  readOnlyRootFilesystem: true

2. Use Role-Based Access Control (RBAC)

Limit user and service account permissions with RBAC policies:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: pod-manager

rules:

  – apiGroups: [“”]

    resources: [“pods”]

    verbs: [“get”, “list”, “watch”]

3. Implement Admission Controllers

Use OPA Gatekeeper or Kyverno to enforce security policies, ensuring insecure workloads are rejected before deployment.

4. Regular Security Audits & Continuous Monitoring

• Perform Kubernetes Penetration Testing to detect misconfigurations.
• Use audit logs to track unusual activity (kubectl get events –sort-by=.metadata.creationTimestamp).
• Deploy security monitoring tools like Falco or Aqua Security.

Business Impact of Insecure Workload Configurations

For C-Level executives, insecure Kubernetes workloads present severe financial, operational, and reputational risks:

ROI of Secure Kubernetes Workloads

By securing Kubernetes workloads, businesses can:

✔ Reduce security incidents and compliance violations.

✔ Protect intellectual property and customer data.

✔ Improve operational efficiency by reducing downtime.

✔ Strengthen trust and reputation in the market.

Strengthening Kubernetes Security

These real-world cyber incidents highlight how misconfigured Kubernetes workloads can lead to massive security breaches. For software developers and architects, it is essential to:

🔹 Harden Kubernetes workloads by enforcing least privilege.

🔹 Secure API access and disable unauthorised exposure.

🔹 Regularly audit IAM roles and remove excessive permissions.

🔹 Monitor Kubernetes activity to detect unusual behaviour.

🔹 Keep Kubernetes and third-party tools updated to patch vulnerabilities.

By implementing these best practices, organisations can mitigate risks and protect their Kubernetes environments from cyber threats.

How Penetration Testing on Kubernetes Helps Discover K01:2022 – Insecure Workload Configurations

How Penetration Testing Helps Identify Insecure Workload Configurations

1. Privilege Escalation Testing

Pentesters attempt to escalate privileges by exploiting workloads running with excessive permissions. They assess:

• Whether containers are running as root
• If CAP_SYS_ADMIN or other high-risk Linux capabilities are enabled
• The effectiveness of Pod Security Admission policies

Example Attack Scenario: A pentester discovers that a pod is running with unrestricted privileges. By executing a simple kubectl exec -it <pod> — /bin/sh, they gain root access to the container and can modify system files or escalate to the node level.

Mitigation:

• Enforce least privilege principles for workloads.
• Use Pod Security Admission (PSA) to restrict privilege escalation.

2. Testing for Misconfigured Network Policies

By default, Kubernetes allows unrestricted communication between pods. Pentesters assess whether NetworkPolicies are in place to restrict traffic flow.

Example Attack Scenario: A pentester exploits an open intra-cluster network by laterally moving from a compromised application pod to a database pod, retrieving sensitive customer data.

Mitigation:

• Implement strict NetworkPolicies to isolate workloads.
• Use Zero Trust principles to limit inter-service communication.

3. Secret Exposure Testing

Pentesters evaluate how sensitive information is stored and accessed within workloads. They search for:

• Hardcoded secrets in environment variables
• Unencrypted secrets in ConfigMaps
• Poorly secured volume mounts exposing credentials

Example Attack Scenario: A pentester gains access to an application pod and discovers AWS access keys stored in plaintext environment variables. Using these credentials, they access an S3 bucket containing sensitive customer data.

Mitigation:

• Store secrets in Kubernetes Secrets instead of ConfigMaps.
• Use sealed secrets or external secret management solutions like HashiCorp Vault.

4. Assessing Runtime Security Gaps

Pentesters assess whether workloads have adequate runtime security controls. This includes testing:

• Whether hostPath volumes expose sensitive system files
• If workloads allow unrestricted process execution
• Whether anomaly detection tools (e.g., Falco) are properly configured

Example Attack Scenario: A pentester uses a compromised pod to access /etc/shadow on the host machine via an insecure volume mount, leading to credential theft.

Mitigation:

• Use read-only root file systems for workloads.
• Enforce least privilege access for volume mounts.
• Deploy runtime security monitoring tools.

5. Container Escape Testing

Pentesters attempt to break out of a container and gain access to the host system by exploiting insecure workload configurations.

Common Exploits Tested:

• Running privileged containers
• Misusing container runtime vulnerabilities
• Exploiting kernel vulnerabilities (e.g., Dirty COW, CVE-2016-5195)

Example Attack Scenario: A pentester exploits a privileged container running with –privileged mode enabled, allowing them to execute commands on the Kubernetes node.

Mitigation:

• Avoid running containers in privileged mode.
• Regularly update and patch container runtimes.
• Enable Mandatory Access Controls (MAC) like AppArmor or SELinux.

Penetration testing is an essential proactive measure to uncover insecure workload configurations in Kubernetes. By simulating real-world attack scenarios, pentesters help organisations:

• Identify misconfigurations before attackers exploit them.
• Strengthen Kubernetes security posture through hardening best practices.
• Reduce risks associated with data breaches, privilege escalation, and service disruptions.

Actionable Next Steps for Software Developers & Architects: ✅ Regularly conduct Kubernetes penetration tests. ✅ Enforce security best practices for workload configurations. ✅ Implement continuous security monitoring to detect misconfigurations in real-time.

By integrating penetration testing into DevSecOps workflows, organisations can proactively mitigate K01:2022 risks and enhance the security of Kubernetes workloads.

Final Thoughts

Kubernetes security is a shared responsibility between software developers, architects, and DevOps teams. Insecure workload configurations introduce severe risks, but by implementing security best practices, organisations can harden their workloads against attacks.

By enforcing least privilege principles, network segmentation, RBAC, and continuous security monitoring, businesses can mitigate threats, protect sensitive data, and ensure the resilience of their Kubernetes infrastructure.

For organisations investing in Kubernetes, proactive security is not just an option—it is a necessity to achieve long-term sustainability and success.