<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security on RLGeeX</title><link>https://www.rlgeex.com/tags/security/</link><description>Recent content in Security on RLGeeX</description><generator>Hugo</generator><language>en-us</language><copyright>RLGeeX © 2025 - Real-Life Geeks providing expert IT consulting</copyright><lastBuildDate>Tue, 10 Nov 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://www.rlgeex.com/tags/security/index.xml" rel="self" type="application/rss+xml"/><item><title>Organization Policies at Scale: Attach High, Pick Managed Constraints, Roll Out in Dry Run</title><link>https://www.rlgeex.com/news/organization-policies-at-scale-attach-high-pick-managed-constraints-roll-out-in-/</link><pubDate>Tue, 10 Nov 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/organization-policies-at-scale-attach-high-pick-managed-constraints-roll-out-in-/</guid><description>&lt;p>This post is for cloud engineers building a GCP foundation with Terraform who want Organization Policy to keep working once the hierarchy grows past a few projects. My argument is that org policy at scale comes down to three decisions. Attach constraints as high in the hierarchy as you can. Handle exceptions with conditions, not scattered overrides. Once other teams own workloads, never enforce a new constraint until it has run in dry-run mode. By the end you should know where each policy belongs, which kind of constraint to reach for, and how to promote one from observed to enforced.&lt;/p></description></item><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>RBAC in a Shared Kubernetes Cluster: Namespace First, Then Audit What Escalates</title><link>https://www.rlgeex.com/news/rbac-in-a-shared-kubernetes-cluster-namespace-first-then-audit-what-escalates/</link><pubDate>Tue, 06 Jan 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/rbac-in-a-shared-kubernetes-cluster-namespace-first-then-audit-what-escalates/</guid><description>&lt;p>This post is for platform teams running multi-tenant Kubernetes on GCP, where several teams share one cluster. RBAC is the isolation control you should design first, because it protects all the others. Below is a default binding pattern and a list of grants to audit. The short version is to scope tenant access to namespaces with RoleBindings that point at a small set of shared ClusterRoles. Then check for escalation paths, not just for who can read what.&lt;/p></description></item></channel></rss>