Project Tanzu
You set up project tanzu by linking your cloud account and creating a management cluster. Then you assign roles so your team can run container apps on worker clusters. Most teams start by linking their identity tool to the main management plane. They often give developers broad admin roles to move fast during early testing. Broad roles let any user change cluster rules or read private app data. How project tanzu manages clusters and roles This platform splits container management into two cle
Temporary Project-Based Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up project tanzu by linking your cloud account and creating a management cluster. Then you assign roles so your team can run container apps on worker clusters. Most teams start by linking their identity tool to the main management plane. They often give developers broad admin roles to move fast during early testing. Broad roles let any user change cluster rules or read private app data.
How project tanzu manages clusters and roles
This platform splits container management into two clear layers for your engineering team. The first layer is a central management cluster that controls your cloud resources. You use this central layer to build, update, and delete smaller worker clusters. The second layer holds the worker clusters where your team runs their daily apps.
To manage team permissions, the platform uses standard Kubernetes role rules across clusters. Admins link the central control plane to an external identity system for user logins. When a developer logs in, the system checks their group and assigns a role. You can scope these roles to a whole cluster or a single namespace. A namespace acts like a private folder for a specific team or app. The system pushes these role rules down to every worker cluster you create.
What native cluster roles solve and what they miss
Native role rules solve the basic problem of who can enter a cluster. They let you group users by team and block outsiders from your servers. You can separate production clusters from test clusters using simple group assignments. This setup keeps your cloud organized as you add more clusters and apps.
Still, native roles only check permissions when a user first logs in. They do not inspect the actual commands or database queries a user runs next. Once a developer has a role that allows pod access, they can run anything. They can open a shell inside a container and read live production tables. Native cluster logs also fail to capture what happens inside those interactive shell sessions. You know who entered the cluster, but not what commands they ran inside.
Temporary Project-Based Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing live cluster sessions and database queries
To fix this gap, teams must control actions at the command and query level. Instead of handing out static cluster keys, you should check every action in flight. When an engineer needs to fix a broken app, approve single commands instead. This approach stops accidental deletes while letting your team fix urgent production bugs.
You also need a clear audit trail for every database query and shell command. Recording the exact text of each command helps you pass security audits fast. Also, applying data masking to query results protects private user records during debugging. Masking rewrites matched fields like emails, phone numbers, and card numbers in results. Your engineers can still fix app issues while sensitive data stays safe in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the main purpose of this container platform?
It helps teams build, run, and manage Kubernetes clusters across different cloud providers. It gives operators one central place to control cluster updates and user roles.
How do developers log in to worker clusters?
Developers log in through their company identity provider to get a temporary cluster token. The platform checks their group membership and applies the matching Kubernetes role rules.
Why are native Kubernetes roles not enough for production security?
Native roles only control initial cluster entry and broad resource permissions. They cannot inspect live shell commands or mask sensitive fields like national IDs.