Hidden Risk Of Relying On Labels In Kubernetes Security

A while ago, a person approached my mentor with a request to optimize the network security of their Kubernetes cluster.

He had a complex architecture with microservices talking to each other, and he was using NetworkPolicy to control communication.

However, despite their policies, they were seeing some unintended traffic flows that left them concerned.

Upon investigation, we noticed that their policies were built around pod labels.

Here’s an example (modified the identity) of what they had in place:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: access-control-database

spec:

podSelector:

matchLabels:

app: ops-examples-db

policyTypes:

- Ingress

ingress:

- from:

- podSelector:

  matchLabels:

role: admin

The intention was clear: only pods with the role: admin label could access the ops-examples-db pod.

On closer inspection, I noticed potential issues:
Labels Could Be Modified: Developers could label any pod as role: admin at runtime, granting it database access.

Namespace Confusion: Policies often overlooked namespaces, allowing a role: admin pod in the dev environment to mistakenly access production services.

After discussing the concerns with that person, my mentor asked if they were using Istio.

They were already using Istio for traffic management but hadn’t considered it for network security.

This presented a good opportunity!

Leveraging the Existing Setup:
We switched from pod labels to ServiceAccounts for more secure access control.

Here’s how the updated policy looks like:

apiVersion: security.istio.io/v1

kind: AuthorizationPolicy

metadata:

name: access-control-istio

spec:

rules:

- from:

- source:

principals: ["cluster.local/ns/ops/sa/admin-service-account"]

Now, only pods associated with the admin-service-account could access the ops-examples-db.

This was more reliable, as ServiceAccounts offer a secure identity without relying on easily altered or misconfigured labels.

Why It Worked Better?

• Tighter Control:
  ServiceAccounts eliminated the risk of unauthorized access via label changes by tying access to pod identity.

• Built-In Security:
  Network traffic is encrypted with TLS, preserving identity across clusters and environments.

• No New Tools:
  The client was already using Istio, so no additional deployment was needed.

If you're using Kubernetes and relying on labels for access control, consider alternatives for better security and scalability.

Until next time, stay secure and keep optimizing!