Vmware Tanzu Application Service
You set up vmware tanzu application service by grouping apps into orgs and spaces. Then you map your identity provider groups to specific platform roles for each team. Many platform teams start by giving broad developer roles to speed up early deploys. That shortcut creates risk when one broad role lets engineers read live service keys. It also lets them run live app tasks across every shared space at once. How vmware tanzu application service manages orgs and spaces The platform uses a two-l
Application-to-Application Password Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up vmware tanzu application service by grouping apps into orgs and spaces. Then you map your identity provider groups to specific platform roles for each team. Many platform teams start by giving broad developer roles to speed up early deploys. That shortcut creates risk when one broad role lets engineers read live service keys. It also lets them run live app tasks across every shared space at once.
How vmware tanzu application service manages orgs and spaces
The platform uses a two-level structure to keep different teams and workloads apart. At the top level, an org holds quotas, domains, and shared service plans. Inside each org, teams create separate spaces for dev, test, and live apps. Every app and bound backing service lives inside one specific space at a time.
A built-in account system handles user logins and links to your identity provider. Platform admins map directory groups to org roles and space roles during setup. Org managers can set usage quotas and add users to their assigned org. Space developers can push code, bind services, and open shells into running app containers. Space auditors can only read logs, check app status, and view space quotas.
Service bindings pass database and queue keys right into the app runtime variables. When a developer binds a backing service, the platform writes those keys into memory. Anyone with the space developer role can read those bound keys at any time. They can also open an interactive shell inside a running app container to debug.
What native platform roles solve and what they miss
Native org and space roles do a good job of controlling basic platform entry. They keep test apps away from live quotas and block guests from pushing code. Auditors get read-only views of metrics and logs without changing any running state. For standard deploy pipelines, this native role model works well and stays clear.
The gap appears when engineers need to fix a live problem in a space. The space developer role is an all-or-nothing grant for every app in that space. Once logged in, a developer can read raw service keys from the app settings. They can also run any shell command inside the container or query bound databases.
Application-to-Application Password Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native roles decide who can enter a space, not what happens inside a session. Platform logs show that a user opened a container shell or viewed app variables. Those logs do not check each command or database query while it runs. They also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. If a developer queries a bound database, raw customer records return straight to their screen.
How to tighten access across live spaces
Start by taking human users out of the live space developer role right away. Let your automated build tools push code and bind services using dedicated machine accounts. Give human engineers the space auditor role so they can still read basic logs. This simple change stops routine exposure of bound database keys in live spaces.
Next, split your spaces by data sensitivity instead of putting all live apps together. Put apps that handle card numbers or national IDs into their own isolated space. Limit who can inspect those spaces, and review role bindings on a set schedule. Keep staging spaces free of real user records so developers can test safely.
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 beside the service as an open-source proxy, a sidecar for your database or API.
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 review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do orgs and spaces differ in this platform?
An org is a top-level account boundary that holds users, quotas, and custom domains. A space sits inside an org and holds the running apps and bound services. Teams usually create one org per business unit and separate spaces for each stage.
Can space auditors view bound service keys?
No, the space auditor role only grants read access to logs, metrics, and quotas. Users with the space developer role can view bound keys and app variables. Moving engineers from developer to auditor roles in live spaces hides those raw keys.
Why is container shell access risky in live spaces?
A container shell lets an engineer run any command inside the live app space. From that shell, the user can read memory variables and connect to bound databases. Native platform roles cannot filter individual commands or mask data inside that active shell.