<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rbac on RLGeeX</title><link>https://www.rlgeex.com/tags/rbac/</link><description>Recent content in Rbac on RLGeeX</description><generator>Hugo</generator><language>en-us</language><copyright>RLGeeX © 2025 - Real-Life Geeks providing expert IT consulting</copyright><lastBuildDate>Tue, 06 Jan 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://www.rlgeex.com/tags/rbac/index.xml" rel="self" type="application/rss+xml"/><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>