TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
You're spending 40 hours a week writing code that AI could do in 10.
While you're grinding through pull requests, 200k+ engineers at OpenAI, Google & Meta are using AI to ship faster. How?
The Code newsletter teaches them exactly which AI tools to use and how to use them. Here's what you get twice a week:
AI coding techniques used by top engineers at top companies
Tools and workflows that cut your coding time in half
Tech insights that keep you 6 months ahead
This guide shows you how to build production-ready AI agents.
👀 Remote Jobs
Canonical is hiring a Cloud Solutions Architect
Remote Location: Worldwide
Sporty Group is hiring a Weekend DevOps Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
🔴 Have a remote role you'd like to get in front of 55,000+ DevOps and Cloud Practitioners? Start Hiring Here →
🧠 DEEP DIVE USE CASE
How to Protect Kubernetes Workloads from Pod Escape
Pod escape is one of the most critical risks in Kubernetes. It happens when an attacker breaks out of a container and gains access to the underlying host. From there, the blast radius expands fast, moving from a single Pod to the entire node, and eventually the cluster.
In a real attack flow, it begins inside a single compromised Pod.
Typical attack vector:
Change identity
Change permissions (user impersonation)
Retrieve or issue a service account token
Execute code on PODs
Move PODs from one node to another
Logical Isolation with Namespaces
The first and most effective way to limit blast radius is namespace isolation. Namespaces are Kubernetes’ built-in logical partitions, they act like virtual clusters inside a single physical cluster.
In the Namespaces diagram above, you can see a clean separation:
Dev Namespace (green border) contains only pod:dev workloads.
Prod Namespace (yellow border) contains only pod:prod workloads.
Pods in the Dev namespace have no default visibility into Prod resources (and vice versa). This prevents a compromised dev workload from directly reaching production services, ConfigMaps, or Secrets, even if the attacker escapes the container.
Pro tip: Always label your Pods and use networkpolicies + namespace selectors to enforce this isolation at the network layer too.
Not All Namespaces Are Equal
Kubernetes ships with four immortal namespaces that cannot be deleted (they are core to cluster operation). Everything else is user created and fully under your control.
Immortal Namespaces (system owned):
default – Never run production workloads here.
kube-system – Core components (etcd, kube-proxy, CoreDNS). Highly privileged.
kube-public – Publicly readable.
kube-node-lease – Node heartbeats.
User Created Namespaces (your responsibility):
dev, prod, logging, ingress-nginx, etc.
Security rule of thumb:
Deploy application workloads only in user created namespaces. Keep kube-system and default strictly off limits for user Pods. This alone stops many privilege escalation paths that rely on the default namespace’s broader permissions.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 55,000+ Cloud Native Professionals? Let's work together. Advertise With Us
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
