<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gke on RLGeeX</title><link>https://www.rlgeex.com/tags/gke/</link><description>Recent content in Gke 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/gke/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><item><title>Credential isolation between clients on a shared GCP foundation</title><link>https://www.rlgeex.com/news/credential-isolation-between-clients-on-a-shared-gcp-foundation/</link><pubDate>Thu, 26 Feb 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/credential-isolation-between-clients-on-a-shared-gcp-foundation/</guid><description>&lt;p>This post is for cloud engineers building a GCP foundation with Terraform that will host workloads for more than one client. Isolation between clients comes from giving each client principals and trust domains that cannot overlap. Naming conventions and the secrecy of identifiers do not provide it. If two clients&amp;rsquo; workloads can end up as the same IAM principal, IAM cannot tell them apart, and a role granted to one applies to both. Below is how I would lay out service accounts, keys and pools so they can&amp;rsquo;t overlap, and when you can relax.&lt;/p></description></item></channel></rss>