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.

Kestra Blueprints gives you 690+ ready-to-use workflow templates for automating Cloud, AI, Infrastructure, Data, and Business processes.

Notable workflows that helped me this week:

Each blueprint demonstrates a real-world use case with fully configured tasks, triggers, and integrations — so you can import it and adapt it to your needs.

Start building reliable workflows directly from the UI without maintaining brittle scripts and disconnected CI/CD jobs.

If you’re not a subscriber, here’s what you missed last week.

How Kubernetes Deploys and Exposes Applications

What Problem Does Kubernetes Volume Solve?

To receive all the full articles and support TechOps Examples, consider subscribing:

One-time 25% OFF on all annual plans of memberships. Closes Soon.

Kubernetes Goat - A "Vulnerable by Design" cluster environment to learn and practice Kubernetes security using an interactive hands-on playground.

A backend engineer runs a security review before a compliance audit and finds something uncomfortable: every pod in the production namespace can reach every other pod, on every port, in both directions. The payment service can open a connection to the internal admin dashboard. The Redis cache pod can make outbound calls to any external IP on the internet. None of this was configured deliberately. It is simply what Kubernetes does by default, and most teams do not discover it until an audit or, worse, an actual breach forces them to look.

By default, a Kubernetes cluster applies no network isolation between pods at all. Every pod can send traffic to every other pod on any port, regardless of namespace, unless something explicitly restricts it. A NetworkPolicy is that restriction. It is a namespaced resource that selects a group of pods by label and defines exactly which traffic is permitted to and from them, with everything else denied once at least one policy targets those pods.

The from field in that policy uses a podSelector matching tier: backend, meaning only pods carrying that specific label are allowed to initiate the permitted connection. Any other pod in the namespace, even one running perfectly legitimate application code, gets blocked from reaching port 5432 the moment this policy exists, because a NetworkPolicy is deny by default for anything it does not explicitly permit once it selects a pod.

This is the detail that catches teams off guard the first time they write a NetworkPolicy. Applying a policy that allows only tier: backend to reach a database pod does not just add a new rule. It silently removes the previous default-allow behavior for every other kind of traffic to that pod, ingress and egress alike, depending on which policy types are declared.

Most teams reach for NetworkPolicy to protect something valuable, like a database, from receiving unwanted inbound connections. Fewer teams think about restricting what that same database is allowed to send out, which is exactly where a compromised pod becomes dangerous. If an attacker gets code execution inside a database pod through a vulnerability, an open egress path means that pod can exfiltrate data to any external endpoint without restriction.

This is the pattern a database tier should follow in any production cluster. The database only ever replies to whoever asked it a question, and it never initiates its own outbound connections. Blocking that egress path means that even if an attacker gains a shell inside the database container, there is no route out to a command-and-control server, since the pod's network policy denies any egress traffic beyond replying to established connections from the backend tier.

Achieving this use case requires two NetworkPolicy objects working together, since a single policy targets one set of pods at a time.

The database pod needs a policy selecting tier: database with an ingress rule permitting only tier: backend as the source, and an egress section that is either omitted entirely, which blocks all egress once Egress is listed under policyTypes, or scoped narrowly to just the response path back to the backend tier. The backend pod's own policy, separately, needs to explicitly permit its egress to tier: database, since NetworkPolicy rules on one pod do not implicitly grant permission on the other side of the connection. Both sides need to agree for traffic to flow.

A common mistake here is assuming an ingress rule on the database pod is sufficient on its own. It is not, if the backend pod also has an egress restricting policy in place that does not list the database as an allowed destination. Both the sender's egress rules and the receiver's ingress rules have to permit the connection, or it gets dropped.

Kestra Blueprints gives you 690+ ready-to-use workflow templates for automating Cloud, AI, Infrastructure, Data, and Business processes with fully configured tasks, triggers, and integrations — so you can import it and adapt it to your needs.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Looking to promote your company, product, service, or event to 50,000+ DevOps and Cloud Professionals? Let's work together.