So your boss wants the NOC team to have a dashboard, but you're smart enough not to give them the keys to the kingdom. Good move. With Radware, or any expensive appliance/SaaS, letting folks poke around willy-nilly is a recipe for an expensive "oops" moment.
The goal: a dashboard that shows everything (alerts, throughput, error rates, the usual) but prevents any configuration changes. You don't want someone fat-fingering a filter and silencing a critical alert.
Here’s the open-source inspired, vendor-agnostic approach I'd advocate for, even if you're stuck with a proprietary backend:
* **Create Dedicated Read-Only Users:** This is step zero. In Radware's management console, create a user role with *View* permissions only. No "Edit," "Configure," or "Admin." Assign your NOC team to this role. Sounds obvious, but you'd be surprised how often people just share the admin login 😬.
* **Build the Dashboard with Exported Data:** The real power move is to not give them direct UI access at all. Use Radware's API (if it has one worth using) to pull metrics into a system you control.
* Scrape whatever metrics you can into Prometheus.
* Build your dashboards in Grafana, pointed at that Prometheus data.
* This gives you complete control, historical data beyond Radware's retention, and the ability to correlate with other systems. Plus, Grafana's dashboard permissioning is robust and free.
If you *must* use the native UI, then lockdown is key. A common pitfall is forgetting that "view" permissions might still let users export configs or trigger certain actions. Test thoroughly.
The core principle? Your monitoring/observability *presentation* layer should be decoupled from your *configuration* layer. It's cleaner, safer, and stops you from being locked into a vendor's idea of what a dashboard should be.
-owl
Open source is the answer
> Create Dedicated Read-Only Users
This is the part where most enterprise tools show their true, bloated colors. You're assuming Radware's role system has a sane, granular "View Only" permission. Half the time, "View" permissions are bundled with obscure "Configure Report" or "Acknowledge Alarm" rights that *are* configuration changes.
Your API scrape idea is the real fix. It bypasses their janky RBAC entirely. But let's be honest, if their API is anything like most appliance vendors, you'll spend a week just getting authenticated before you can pull a single metric. Good luck.
Exactly, and even if their API is a mess, you can still establish a stable data layer. I set up a periodic export from our monitoring appliance to a separate PostgreSQL instance last year. It's just a cron job dumping CSVs via SFTP, but it works. That way, the dashboard queries only the replicated, static data.
You then build your Grafana panels on top of that isolated database. The read-only user exists at the database level, not the appliance, which is far simpler to lock down. The latency from the export is maybe five minutes, but for a NOC overview, that's usually fine.
The key is treating the vendor interface as a data source, not a dashboard platform.
-- bb42