Backstage Monitoring
You set up backstage monitoring by adding metrics plugins to your portal app. These plugins pull live system data from your cloud tools into one screen. Most engineering teams start by storing shared API keys in the portal backend. That setup works at first, but broad role permissions create major security risks. Every user who logs in can view or change data across all systems. How backstage monitoring works in your portal Backstage acts as a central hub for all your software teams and servi
Backstage Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up backstage monitoring by adding metrics plugins to your portal app. These plugins pull live system data from your cloud tools into one screen. Most engineering teams start by storing shared API keys in the portal backend. That setup works at first, but broad role permissions create major security risks. Every user who logs in can view or change data across all systems.
How backstage monitoring works in your portal
Backstage acts as a central hub for all your software teams and services. It uses a catalog file to map each service to its monitoring tool. When a developer opens a service page, the portal frontend asks for data. The portal backend reads the shared API key from its local config file. Then the backend sends a read request to your external metrics or log tool. The external tool checks the shared key and sends back the system charts.
Teams also set up health checks for the portal app itself. The backend exposes a status endpoint and sends out its own system logs. Platform engineers ship these logs and metrics to a central collector. This helps the platform team check if the catalog sync or search fails. You can also track how long each plugin takes to load a page.
Managing role permissions for portal plugins
By default, a new portal gives every logged-in user the same read role. Anyone on the team can look at every service and its monitoring data. Platform teams use the built-in permission framework to lock down these open views. You write policy rules that check a user group before showing a page. The portal reads group data from your identity provider when a user logs in. If a user belongs to the payments team, they see payment service metrics. Other teams get blocked when they try to open that specific catalog item.
This setup still relies on static backend keys to talk to outside tools. The portal backend holds one big role that can read everything at once. If a plugin allows write actions, that single key has huge power. A user might restart a pod or trigger a build from the portal. The outside tool only sees the shared portal key in its audit logs. You lose track of which person actually ran the command in the portal.
Backstage Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native portal roles solve and where they fall short
Native portal rules do a great job of hiding UI tabs and buttons. They stop a casual user from clicking on a restricted team page. They also help platform teams group services by owner in the software catalog. This keeps the daily view clean and stops simple mistakes inside the browser.
Still, native setup rules only decide who logs in and sees a page. They do not check what individual queries or commands do while in flight. When engineers need to fix a broken service, charts are never enough. They have to run live database queries or shell commands on production hosts. Static keys and broad roles cannot filter out dangerous statements during a fix. They also cannot mask sensitive fields like emails, phone numbers, or card numbers. If a log stream or query returns national IDs, raw text shows up. To protect production data, teams need controls that check every single request live. Masking rewrites matched fields in results before they ever reach the user screen.
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
How do I track the health of the portal backend itself?
You can enable the built-in status check and metrics endpoints on the backend. Then your collector scrapes memory use, request latency, and catalog sync errors.
Why do external audit logs only show the portal service account?
Most portal plugins use a single static API key stored on the server. The target tool sees that shared server key instead of the human user.
Can portal permission rules hide sensitive data inside a log line?
No, native portal rules only allow or block access to a whole resource. They do not inspect payload text or rewrite emails and card numbers live.