Documentation
Roles and multi-tenant
A single console can serve several organizations without them ever seeing each other. In VIGIL-MESH, the unit of isolation is the workspace: it is the tenant. Every resource — network, device, rule, invitation, audit log — is attached to one organization and does not cross that boundary: there is no cross-tenant access. Inside a workspace, responsibilities are split into separate roles, from the infrastructure operator to the read-only auditor, so that everyone has only what they need.
The workspace = the tenant
Multi-tenancy is not an option bolted on afterwards: it is the dividing line everything is organized around. The workspace is the tenant. Every resource managed in the console belongs to one and only one organization, and that ownership determines who can see and administer it. Two customers hosted on the same platform live in disjoint spaces, with no window from one into the other.
Concretely, the absence of cross access means that a member of one organization can neither list, nor read, nor modify the resources of another. Networks, enrolled devices, access policies, pending invitations, the audit log: everything is scoped to the organization. There is no “global” view cutting across tenants for convenience — convenience stops where isolation begins.
- Every resource is attached to an organization: its home tenant is the boundary of its visibility.
- No cross access: a member of one workspace neither sees nor acts on the resources of another.
- The audit log itself is scoped: each organization keeps its own chain, described in /en/docs/console-audit.
- Isolation is structural, not declarative: it does not depend on everyone “staying in their lane”, but on the partitioning of the model.
The roles
Inside a workspace, not everyone needs to do everything. VIGIL-MESH separates responsibilities into distinct roles to apply least privilege: each person is given the ability to act on what concerns them, and nothing more. Three roles structure everyday use of the console.
| Role | Scope | What it can do |
|---|---|---|
| Infrastructure operator | The platform and the organizations it hosts | Operates the underlying infrastructure and the hosting of tenants, without standing in for the internal administration of a customer's network. |
| Customer network administrator | Their own organization's network | Manages their organization's devices, access rules and members: enrollments, revocations, policy publication. |
| Read-only auditor | Their organization's resources, view only | Views the state of the network and the audit log without being able to modify anything: a right to look, not to act. |
The separation between the infrastructure operator and the customer's network administrator matters: operating the platform is not the same thing as administering a tenant's network. Likewise, the read-only auditor embodies the principle that you may need to see everything without the right to change anything — it is the role that naturally accompanies the audit log of /en/docs/console-audit.
Good practices for granting roles
Granting roles is not a trivial gesture: it is where, in practice, the line is drawn between healthy access and overly broad access. A few principles keep the model readable over time.
- 1Start from the need, not from convenienceGive the narrowest role that lets the person do their job. An administration right “just in case” is one right too many.
- 2Distinguish seeing from actingWhen someone needs to oversee without intervening — compliance, supervision, a trusted third party — the read-only auditor is the right choice.
- 3Name the accessesIndividual identities rather than shared accounts: that is what makes the audit log able to attribute each action to a person.
- 4Review regularlyNeeds evolve; roles inherited from an old project should not outlive their purpose. Review accesses periodically.
The operator / customer administrator / auditor split comes into its own in multi-party scenarios — an operator hosting the networks of several customers, each administering its own, with a third party observing. That use case and how it fits the Zero Trust model are developed in /en/docs/cas-entreprise.