Tanzu Observability
You set up tanzu observability by deploying collection agents to your app hosts. These agents send metrics, traces, and logs to a central cloud platform. Most teams start this setup by granting broad role permissions to their devs. That approach speeds up testing, but wide permissions create big security risks in prod. If a role has too much power, one bad command can break live systems. How tanzu observability roles and agents work To get data flowing, your team installs local agents on each
AI Observability: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up tanzu observability by deploying collection agents to your app hosts. These agents send metrics, traces, and logs to a central cloud platform. Most teams start this setup by granting broad role permissions to their devs. That approach speeds up testing, but wide permissions create big security risks in prod. If a role has too much power, one bad command can break live systems.
How tanzu observability roles and agents work
To get data flowing, your team installs local agents on each server or cluster. These agents read system stats and app traces from your running workloads. Then, the agents push that data out to the cloud dashboard for your team. Admins control who can view or change this setup through role permissions.
You link your identity provider to the platform to manage user sign-ins. When devs log in, the system checks their group and assigns a role. Some roles only let users read charts and check alerts during an outage. Other roles let users write new alert rules, manage agent keys, or delete data.
Data flow relies on static API tokens that live on your host servers. Devs also use personal keys when they run scripts to query metrics or logs. Managing all these keys and roles across many clusters takes daily effort. Teams must rotate keys often and check role lists when people change jobs.
What native permissions solve and what they miss
Built-in role controls do a great job of managing dashboard sign-ins. They decide who can log in to the web portal and edit charts. They also stop junior devs from deleting shared alerts or billing rules. For basic portal use, native roles give you a solid first line of defense.
Still, dashboard roles do not control what happens on the host servers themselves. When an alert fires, an engineer must log in to the database or cluster. Native monitoring roles only govern the charts, not the live fix commands. Once a user opens a terminal to fix a host, broad server roles take over.
AI Observability: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Monitoring logs can also capture raw user data by mistake during a crash. Emails, phone numbers, card numbers, and national IDs often slip into error traces. Standard role rules decide who opens the log page, not what fields show up. They do not rewrite sensitive fields in results or approve risky commands in flight.
How to tighten host and data controls
To keep prod safe, teams must separate chart viewing from server command rights. Devs should read metrics all day without holding standing keys to prod hosts. When a server needs a fix, each action should pass a strict check first. Teams also need tools that mask emails and card numbers in query results.
Start by removing shared admin keys from developer laptops and build scripts. Next, review your log pipelines to find where raw user fields enter the stream. Put controls in place that check every database query and server command in flight. This shift keeps your systems fast while stopping bad commands before they run.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
How do agents send data from private clusters?
Local agents collect metrics and logs inside your network and push them out. They use encrypted web traffic and API tokens to reach the cloud platform.
Can native roles mask sensitive fields in error logs?
No, standard roles only control who can open the log viewer page. To hide emails or card numbers, you must filter data before or during queries.
Why is dashboard role control not enough for incident fixes?
Dashboard roles only limit what charts or alerts a user can change. When engineers log in to servers to fix bugs, you need command-level controls.