<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Network-Policy on RLGeeX</title><link>https://www.rlgeex.com/tags/network-policy/</link><description>Recent content in Network-Policy on RLGeeX</description><generator>Hugo</generator><language>en-us</language><copyright>RLGeeX © 2025 - Real-Life Geeks providing expert IT consulting</copyright><lastBuildDate>Thu, 05 Nov 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://www.rlgeex.com/tags/network-policy/index.xml" rel="self" type="application/rss+xml"/><item><title>Default-deny network policies for tenant isolation on GKE</title><link>https://www.rlgeex.com/news/default-deny-network-policies-for-tenant-isolation-on-gke/</link><pubDate>Thu, 05 Nov 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/default-deny-network-policies-for-tenant-isolation-on-gke/</guid><description>&lt;p>This post is for platform teams running multi-tenant Kubernetes on GCP, where each team or customer gets its own namespace. Network policies are the right tool for isolating services from each other, but they isolate only the pods a policy selects. The real work is setting a default-deny baseline in every tenant namespace and then allowing traffic on purpose. Below I cover what to turn on, the order I&amp;rsquo;d roll it out in, and where policies stop protecting you.&lt;/p></description></item></channel></rss>