Three roles are not an access model.
Many delivery platforms offer a short list of roles — administrator, operator, read-only — and everything that does not fit becomes an administrator. The certificate team gets full traffic rights because certificates live under traffic. The monitoring integration gets an administrator token because there is no lesser token to give it. The network team can edit WAF policy because network and security share one role.
The result is predictable: an audit asks who could have made a change, and the honest answer is most of the console. Separation of duties exists on the org chart and not in the product.
The second failure is surface drift. A permission enforced in the interface but not in the API is not a permission; it is a suggestion. Anyone who can reach the API can do what the interface refused.
Our approach
The role names the job. The scope names the blast radius. Both are enforced on every surface.
Sixteen roles, not three
Roles are cut along the lines real teams actually divide: traffic, WAF, network, GTM, certificates and monitoring, each with a manager and a user variant where that distinction matters, plus read-only and frontend-only roles for people who need to see without touching.
Scope on top of role
A role says what kind of object a user may touch. The scope says which ones: allowed frontend IPs, allowed backend networks, assigned vServices and assigned vDevices. Two Traffic Managers can administer two different estates on one appliance without seeing each other's services.
One permission model across interface, CLI and API
The interactive CLI enforces the same role as the interface — a Network Manager sees network commands and nothing else — and REST access is gated per area and per field by the same model. Persistent API tokens are bound to the role, so a pipeline token carries the pipeline's rights and not an administrator's.
Every surface writes the same audit trail
A change made by clicking, by command or by API call lands in one audit trail with lossless before-and-after diffs. The question an auditor asks — who changed this, from where, and what did it look like before — has one answer regardless of how the change was made.
Capabilities
What the role model covers, and what sits on top of it.
Sixteen named administrative roles
The full set: Admin (super-admin) · Traffic Manager · Traffic User · Traffic+WAF Manager · Traffic+WAF User · WAF Manager · WAF User · WAF Read-Only · Network Manager · Network User · GTM User · Certificate Manager · Monitor User · Read-Only User · Frontend User · Client (cloud client). Manager and user variants separate the right to configure from the right to operate.
Network scope — allowed frontend IPs and backend networks
A user's reach is bounded by address, not only by object type. Frontend addresses they may publish on and backend networks they may point at are both listed per user, so a mistake stays inside the segment the user is responsible for.
Resource scope — assigned vServices and vDevices
Users are assigned the specific published services and the specific vDevices they own. Everything else is not read-only to them; it is not visible.
Certificate rights: management versus selection
The right to select a certificate for a service and the right to manage the certificate library are separate rights. An application team can publish a service on the correct certificate without being able to export, replace or delete the key behind it.
Shell access as a per-user toggle
CLI over SSH and CLI in the browser are two independent switches, each with a maximum-session count. An operator can be given the browser console without an SSH account existing for them anywhere.
Per-user quotas: bandwidth, CPU and connections
A role can carry a resource ceiling as well as a permission set, so a tenant administrator cannot consume the appliance on behalf of everyone else.
Field-level API authorisation
REST access is gated per area and per field using the same model as the interface. A role that cannot see a field in the console cannot read it through the API either.
Directory-backed administrators with strong authentication
Administrators authenticate against local accounts, LDAP and Active Directory, RADIUS or TACACS+ with accounting. Two-factor by SMS or e-mail OTP, recovery tokens and mTLS client-certificate admin login issued by TR7's internal PKI are all available.
Workspace preferences travel with the user
Language, theme and header-bar layout are stored per user, so an operator's console looks the same on whichever node of the cluster they land.
Operational depth
The parts that decide whether an access model survives an audit.
Separation of duties, expressed rather than promised
Because WAF, traffic, network, GTM and certificates are separate role families, the common regulated-industry requirement — the person who changes a security policy is not the person who changes the traffic path — is a configuration rather than a procedure someone has to remember.
Read-only roles that are genuinely read-only
Read-Only User, WAF Read-Only and Monitor User exist so that auditors, NOC staff and dashboards do not need a role that could change something. A monitoring integration is given a token bound to one of these rather than an administrator token.
Frontend User and Client roles for delegated access
Frontend User covers people who work with published services without touching the platform underneath. Client covers the cloud-client case, where the account belongs to a consumer of the service rather than to an operator of it.
Brute-force defence on the management plane
Password complexity is enforced, and failed logins are throttled with per-IP and per-IP-plus-username budgets that expire, backed by the built-in CAPTCHA. The management plane is treated as an attack surface, because it is one.
Management services bound and scoped individually
HTTPS, SSH, FTP and SNMP each bind to a chosen address and port and carry their own allowed-network list, their own certificate and their own minimum and maximum TLS version. The console can require TLS 1.3 while a monitoring integration that cannot yet speak it reaches a different service at TLS 1.2.
Purpose-scoped file transfer accounts
File transfer does not run through one shared account. Separate accounts cover log export, configuration backup, offline IP-intelligence delivery and offline update packages, and each sees only its own directory — which is what makes air-gapped operation practical without a privileged account.
When to use it
Regulated separation of duties
A bank needs the WAF policy owner and the traffic owner to be different people, and needs to prove it. WAF Manager and Traffic Manager are separate roles with separate audit trails, so the proof is a report rather than an interview.
Application teams that publish their own services
Each team is given a Traffic User role scoped to its own vServices and its own backend networks. Teams publish and operate without a change request, and without being able to reach another team's services.
Pipeline and monitoring tokens
A CI/CD pipeline receives a persistent API token bound to a narrow role, and a monitoring system receives one bound to Monitor User. Neither holds administrator rights, so a leaked token is a bounded incident.
A certificate team that does not own traffic
Certificate Manager administers the key library and renewals; application teams select from it. The private key never has to be handed to the team that publishes the service.
Frequently asked questions
How many administrative roles does TR7 ship with?
Is the CLI subject to the same permissions as the interface?
Can two administrators manage different services on one appliance without seeing each other?
Can an API token be limited to less than an administrator?
Does RBAC require an additional licence?
How do administrators authenticate?
Sixteen roles, scoped per user, enforced on every surface
Let's walk through the role model against your own separation-of-duties requirements.