An OpsAPI deployment has two very different audiences. Customers use the apps: they need those on the public internet, and OpsAPI signs them in. Staff run the platform through admin dashboards, and those dashboards are where a stolen password does the most damage. The pattern we recommend is simple to state: public apps stay public, and every admin surface is reachable only through a VPN or a zero-trust network access (ZTNA) broker, with OpsAPI’s own sign-in, emailed codes and roles still enforced inside.
Which surfaces count as admin
| Surface | Why it matters | Behind the broker? |
|---|---|---|
| OpsAPI admin dashboard | Users, roles, workspaces, settings | Yes |
| Edge proxy admin | Can reroute any hostname | Yes |
| Secrets vault UI | Every credential the platform uses | Yes |
| Grafana and Prometheus | Traffic, user activity, sometimes personal data | Yes |
| Kubernetes API | Everything | Yes, plus short-lived credentials |
| Customer apps and the sign-in page | Must work from anywhere | No: public, behind the edge |
Two doors
The same OpsAPI sign-in sits behind both doors. That’s deliberate: the broker proves the device and the network path, OpsAPI proves the person and their role. Neither replaces the other.
App segments, not a flat network
A classic full-tunnel VPN puts a laptop on the network, and then everything reachable from that network is reachable from the laptop. ZTNA products publish one application at a time to named groups instead. Examples of the approach include Zscaler Private Access (app segments and access policies), Cisco Secure Client with Duo device checks, Cloudflare Access, or a self-hosted WireGuard VPN with tight per-peer rules. We describe the pattern, not a product; check each vendor’s current documentation for its terms.
- No public Ingress for admin apps. They stay ClusterIP services; the connector reaches them from inside.
- Outbound only. The connector dials the broker; firewalls need no new inbound rule.
- Per-app policy. “SRE on-call may reach Grafana and the Kubernetes API; support may reach the OpsAPI admin.” Nobody gets the whole network.
- Device posture. Brokers can require a managed, patched, encrypted device before the tunnel opens.
Five layers in front of an admin dashboard
| Layer | Question | Answered by |
|---|---|---|
| Device + network | Managed device on our private path? | Broker client and device checks, or a VPN key per person |
| Access policy | In a group allowed to reach this app? | Broker app segments mapped to workforce directory groups |
| Application sign-in | Who is this, did they pass MFA? | OpsAPI sign-in; platform admins always get an emailed code |
| Authorisation | What may they do here? | OpsAPI workspace roles (module.action permissions) |
| Revocation | Can we remove them fast? | Disable in the broker and deactivate the OpsAPI user |
Workforce identity and customer identity are different
The broker normally trusts the company’s workforce directory: the people employed to run the platform. OpsAPI holds the people who use the apps, plus the staff accounts inside each workspace. Keep the two separate in your head and in your tooling. We don’t wire OpsAPI up as the identity source for a ZTNA product, and OpsAPI isn’t a SAML or OpenID Connect provider, so most brokers couldn’t use it directly anyway.
Logging that names a person
Behind a single VPN exit address, the edge log shows the same IP for every member of staff. Per-person audit comes from two places that do know who someone is: the broker’s access log (who reached which app, from which device) and OpsAPI’s auth_events and activity tables (who signed in, what they changed). Ship both to the same place and keep the clocks in sync.
Offboarding is two actions
- Remove the person from the broker (or delete their VPN peer). Admin dashboards become unreachable.
- Deactivate their OpsAPI account. Their tokens stop working at the next check and they can’t sign in to any app.
Do both, and test it: a leaver’s browser should get no admin page at all, and their OpsAPI login should fail.
The public demo is the exception
dashboard.demo.opsapi.org is on the public internet on purpose, so anyone can look around. It still needs a sign-in, and the published demo account is read-only in its own showcase workspace of fictional users: every change is refused, and the account is reset every 30 minutes. Real people who sign in to the demo apps live in a different workspace the demo account can’t see. Don’t copy this setup to production.
Rollout checklist
- List every admin surface (the table above is a start) and remove public DNS records or edge rules for each.
- Publish each one through the broker as its own app, with a group-based policy.
- Keep OpsAPI MFA on for every workspace that has staff accounts.
- From an unmanaged device off the broker, confirm every admin hostname fails before it reaches a login page.
- Run an offboarding drill with a test account: broker removal plus OpsAPI deactivation, then check both paths fail.