Tanzu Run
You use tanzu run to build, deploy, and start apps on your cluster. This workflow takes your source code and turns it into a running workload. Most platform teams set up shared cluster roles so devs can deploy code fast. Still, broad roles often give users too much power over live workloads. When a role allows full cluster writes, one bad command can break shared services. How tanzu run works under the hood The platform uses a supply chain model to move code from source to production. When a
Run: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use tanzu run to build, deploy, and start apps on your cluster. This workflow takes your source code and turns it into a running workload. Most platform teams set up shared cluster roles so devs can deploy code fast. Still, broad roles often give users too much power over live workloads. When a role allows full cluster writes, one bad command can break shared services.
How tanzu run works under the hood
The platform uses a supply chain model to move code from source to production. When a dev starts a workload, the system reads the workload definition file. The cluster controller then pulls the source code from your version control system. Next, the build service turns that code into a container image. It checks the base image and adds the needed software layers. After the build finishes, the system writes deployment files for the cluster. The cluster then schedules the pods and starts the app containers. All of these steps depend on role bindings inside the cluster. Admins bind user groups to cluster roles so devs can start builds. The cluster checks these role bindings when the user first sends the request.
What native cluster roles solve and what they miss
Native cluster roles are great at deciding who can log in and deploy. They let admins group users by team and assign namespace rules. A role can allow a dev to read logs or create a workload. This setup stops random users from touching namespaces they do not own. Yet native roles only check permissions at the resource level. Once a user has write rights, the cluster trusts every command they send. The native role system does not check the content of individual requests in flight. If a dev has rights to debug a pod, they can run any command inside it. They can read secret files or query connected databases from that pod. They might see raw emails, phone numbers, or card numbers in query results. Native logs also miss the exact commands run inside an interactive pod shell. You know who started the session, but not what they ran inside it.
How to tighten workload execution rules
To lower risk, teams must separate build rights from live runtime rights. Start by scoping developer roles down to single namespaces rather than the whole cluster. Give your automated supply chain service accounts the power to write pod specs. Do not give human users direct write permissions on production pods. When devs need to check a live problem, avoid granting wide cluster admin roles. Instead, set up a workflow that checks each command or query before it runs. Make sure your audit logs capture every action taken during a live debug session. Also, apply data masking rules that rewrite sensitive fields like national IDs in results. This keeps private user data safe while devs fix broken apps.
Run: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does a workload run do in a Tanzu cluster?
It tells the cluster supply chain to build source code and start app pods. The platform handles image creation, security scans, and pod scheduling based on your template.
Why are broad namespace roles risky for app deployments?
Broad roles let users open pod shells, read mounted secrets, and alter running containers. Native roles check who starts a session, not the commands run inside it.
How can teams protect sensitive data during live app debugging?
Teams can route debug sessions through a system that logs commands and masks data. Data masking rewrites matched fields like emails and card numbers in query results.