Team and managers
A Pharos workspace has two roles, admin and user, and they are local to Pharos. Who belongs to the organisation is decided in the Wazuh Hub. What each member may do in Pharos is decided here. The two layers are never mapped onto each other: being the organisation's owner in the Hub does not make anyone an admin in Pharos.
The two roles
| Role | Can |
|---|---|
| User | Everything that reads: search the corpus, open every CVE record, see the fleet, its managers and their agents, triage signals and advisories, read the notification settings and the Billing page |
| Admin | All of the above, plus the team, the managers, the notification destinations and routing, the monthly limit, and switching Pharos on |
The first person into a workspace becomes its admin, because the workspace is created at their first sign-in and somebody has to be able to connect the first manager from Wazuh Fleet. See Sign in. Everyone who arrives after that joins as a user, unless an invitation says otherwise. A role is decided once, when the member is invited, and there is no control to change it afterwards today.
The Team page
The Team page lists who can sign in to this workspace: each member's name and email, their role, whether they are active or still invited, how they sign in, and when they joined. The one action is Invite member, and it is an admin's.
An invitation takes an email address, an optional name, and the role the person will hold: User, full access to the intelligence and the fleet or Admin, and can also manage the team and billing. Sending it does two things. The Hub creates a Wazuh ID account in the organisation for the address, or recognises the one it already has, and emails the person if the account is new. Pharos records that this workspace and this role are waiting for them. They join the workspace at their first sign-in, and the invitation expires after 14 days. A pending invitation can be revoked from its row, which withdraws Pharos's half only: the Wazuh ID account, if one was created, stays.
Removing a member is not something the Team page does. Membership of the organisation belongs to the Hub, so a person is removed there, and their access to every Labs service ends with it. Removal is not instant. Pharos reads who a member is from a session token that stays valid for about an hour, so a removed member can keep working until it expires.
What only an admin can do
The console hides these controls from a user, and the service refuses them too: a hidden button is a courtesy, the refusal is the permission.
- Invite a member, and revoke a pending invitation.
- Connect a Wazuh Fleet environment, and disconnect one. This is how a manager is added. See Install the sidecar from Wazuh Fleet.
- Change a Fleet-installed manager's Wazuh login, which reaches every Pharos manager of its Fleet environment. See Install the sidecar from Wazuh Fleet.
- Disconnect, reconnect or remove a manager, and start or stop its inventory sharing.
- Change the notification destinations and the routing table, and send a test. See Notifications.
- Set the monthly limit, and switch Pharos on, on the Billing page. See Signals.
The managers and their lifecycle
The Managers page has one row per connected deployment: whether it is still reporting, whether its alert stream is readable, its agent count, whether it shares inventory, its coverage, and the signals it has produced this month. Everybody in the workspace sees it. Managers are unlimited and free, and the bill is for the signals they emit.
A manager's state badge reads one of five things. Disconnected and Revoked are decisions somebody made; Active, Offline and Pending are read from whether it is actually reporting, so a manager whose host has stopped reads Offline rather than staying Active:
| State | Meaning |
|---|---|
| Active | Reporting, and everything it sends is being read |
| Offline | It has not reported in over a day. Its credential is still valid, but nothing is coming in |
| Pending | Enrolled, but it has not reported yet. Waiting for its first report |
| Disconnected | Still enrolled, and nothing is being read from it. Its credential and its read position are kept, so reconnecting is one click and picks up where it left off |
| Revoked | Removed from Pharos. Its credential no longer resolves and it cannot be reactivated. Its history is kept. A Wazuh Fleet host can be added again from Add a manager, as a new manager |
Disconnecting is reversible. Removing from Pharos is terminal for that manager, and the console asks for the manager's identifier to be typed before it does it. On a Wazuh Fleet host, Wazuh Fleet is asked to remove the Pharos plugin first, and the manager is removed only once Fleet has accepted. If Fleet refuses or cannot be reached, nothing changes. The host is then free, and Add a manager offers it again as a new manager, while the removed one keeps its history and its signals. Either way the rest of the fleet is unaffected. Revoked managers are not listed with the others, though the page says how many there are.
A Fleet-installed manager takes its credential from Fleet. A native manager that loses its credential is removed from Pharos and added again from Wazuh Fleet. See The sidecar on the host.
Alongside its state, each manager has a finer sync reading: online when it has reported in the last fifteen minutes, stale after that, offline after a day, and never synced if nothing has arrived yet. The state badge is read off the same clock: it stays Active through a stale gap between check-ins, but a manager silent for more than a day reads Offline, and one that has never reported reads Pending. A disconnected manager stops syncing yet keeps reading Disconnected, because that is a decision rather than a matter of liveness.