- TechOps Examples
- Posts
- Hidden Risk Of Relying On Labels In Kubernetes Security
Hidden Risk Of Relying On Labels In Kubernetes Security
Govardhana M K
October 10, 2024
In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the top news, tools, videos, and articles in the TechOps industry.
Before we begin... a big thank you to today's sponsor
A Full-stack generative AI platform.
WRITER — Build feature-rich AI apps including digital assistants, content generation, and data analysis with no code.
Loved by Intuit, Accenture and Samsung!
IN TODAY'S EDITION
🧠 Use Case
Hidden Risk Of Relying On Labels In Kubernetes Security
🚀 Top News
📽️ Videos
Create Serverless Apps Using Kubernetes and Knative
Troubleshooting Terraform with TF_Log
📚️ Resources
What are Virtual Kubernetes Clusters?
The Four Stages of Terraform Automation
Kubernetes Roadmap: Step by step guide to learning Kubernetes in 2024
🛠️ TOOL OF THE DAY
KubeClarity - Tool for detection and management of vulnerabilities of container images and filesystems
Scans both runtime K8s clusters and CI/CD pipelines for supply chain security.
🧠 USE CASE
Hidden Risk Of Relying On Labels In Kubernetes Security
A while ago, a client approached me with a request to optimize the network security of their Kubernetes cluster.
They had a complex architecture with microservices talking to each other, and they were using NetworkPolicy to control communication.
However, despite their policies, they were seeing some unintended traffic flows that left them concerned.
Upon investigation, I 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: techops-examples-db
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: admin
The intention was clear: only pods with the role: admin label could access the techops-examples-db pod.
On closer inspection, I noticed potential issues:
Labels Could Be Modified: Developers could label any pod as
role: adminat runtime, granting it database access.Namespace Confusion: Policies often overlooked namespaces, allowing a
role: adminpod in the dev environment to mistakenly access production services.
After discussing the concerns with the client, I 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/techops/sa/admin-service-account"]
Now, only pods associated with the admin-service-account could access the techops-examples-db.
This was more reliable, as ServiceAccounts offer 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!
Writer RAG tool: build production-ready RAG apps in minutes
RAG in just a few lines of code? We’ve launched a predefined RAG tool on our developer platform, making it easy to bring your data into a Knowledge Graph and interact with it with AI. With a single API call, writer LLMs will intelligently call the RAG tool to chat with your data.
Integrated into Writer’s full-stack platform, it eliminates the need for complex vendor RAG setups, making it quick to build scalable, highly accurate AI workflows just by passing a graph ID of your data as a parameter to your RAG tool.
If you're enjoying TechOps Examples please forward this email to a colleague.
It helps us keep this content free.