Artica Meta: Tenants
Serve several customers from one Artica Meta server: each tenant administers only its own nodes, groups and policies.
Tenants let one Artica Meta server serve several customers.
A managed service provider runs the Meta server.
Each customer becomes a tenant with its own nodes, groups, policies and objects.
The customer's administrators sign in to the same console and only see their tenant.
A Meta server without tenants works as before.
Everything belongs to the provider.
Vocabulary
| Term | Meaning |
|---|---|
| Provider | You, the operator of the Meta server. Accounts with the privilege Can manage Artica clients with global management console Artica Meta see every node and every tenant. |
| Tenant | A customer. It owns groups of nodes, policies, proxy objects, virtual network cards and enrollment accounts. |
| Owner | An account or a directory group allowed to administer a tenant. |
| Tenant administrator | An owner who also holds the privilege Can manage the Artica Meta tenants (customers) owned by this account or one of its groups. |
| Global element | An element that belongs to the provider. Tenants can read some of them but never change them. |
What a tenant administrator sees
A tenant administrator works in the usual Artica Meta pages.
The lists only show the elements of the tenant:
- The groups of the tenant and the nodes inside them.
- The policies, proxy objects and virtual network cards created in the tenant.
- The enrollment accounts of the tenant groups.
- The events, metrics and status of the tenant nodes.
Some provider elements are shared as read-only references.
Global proxy objects, global virtual network cards and global links can be read.
A global policy is visible when it is attached to one of the tenant nodes.
These elements carry a Provider badge and cannot be modified.
Nodes, groups and enrollment accounts of the provider are never visible.
Elements of another tenant are never visible either.
Asking for one returns the same "not found" answer as an element that does not exist.
An account that only holds the tenant administrator privilege sees the Artica Meta pages and nothing else in the console.
Before you start
- The Artica Meta service is enabled on the server.
See Activate the Artica Meta service. - A REST API key is configured on the Meta server.
The REST API key is required.
Without it, the REST API ports accept any client from an allowed network with provider rights.
The tenants page shows a warning and refuses to create a tenant until the key exists.
Do not remove the key once tenants exist.
Step 1: create the tenant
- Open Artica Meta > Meta tenants.
- Click New tenant.
- Enter a name and an optional description.
The name identifies the customer in the provider console and in the tenant selector.
Two tenants cannot share the same name.
Only the provider sees the Meta tenants page.
Step 2: give nodes to the tenant
A node belongs to the tenant of its groups.
Open the tenant and go to the Groups tab:
- New group in this tenant creates an empty group owned by the tenant.
- Move provider group into this tenant hands an existing group to the tenant.
Its nodes follow the group. - Move node moves a single node into a group of the tenant.
A node belongs to one tenant at most.
Adding it to a group of another tenant is refused.
It can also stay in provider groups.
It still belongs to the tenant.
When a node changes tenant, Artica Meta removes its direct attachments to the policies of the former tenant.
The usual release then applies on the node.
The new tenant sees the node events from the move onward.
A tenant administrator cannot remove a node from the last group of its tenant.
Ask the provider to move it.
Step 3: declare the owners
Open the tenant and go to the Owners tab.
Click Add an owner and fill in:
| Field | Value |
|---|---|
| Kind | Account or Group. |
| Authentication | The method that opens the session: Active Directory, LDAP, Local administrators or RADIUS. |
| Identifier | The login name of an account. For a group, the key read at sign-in (see below). |
| Label | A free text shown in the list. |
Group identifiers depend on the authentication method:
| Authentication | Group identifier |
|---|---|
| Active Directory | The group DN. |
| LDAP | The gidNumber of the group. |
| Local administrators | sqlite:<id> of the local group. |
| RADIUS | The RADIUS group name. |
Groups are usually easier to pick from the group privileges editor.
The Artica Meta service section of a group lists the tenants it administers, like SIEM tenants.
Open sessions pick up an owner change on their next page.
A removed owner loses access immediately for direct API calls made with its session.
Step 4: grant the tenant administrator privilege
Being an owner is not enough.
The account, or one of its groups, also needs the privilege Can manage the Artica Meta tenants (customers) owned by this account or one of its groups.
It is in the Artica Meta service section of the privileges editor.
This section only appears when the Artica Meta service is enabled.
This privilege does not include the provider privilege.
A tenant administrator cannot see provider pages or other tenants.
Signing in as a tenant administrator
At sign-in, Artica Meta resolves the tenants owned by the account and its groups.
- One tenant: the Meta pages show it directly.
- Several tenants: an Active tenant selector appears.
The pages show one tenant at a time. - No tenant: the pages show "No tenant assigned to your account".
Ask the provider to add the account as an owner.
Working inside a tenant
Policies and objects
Everything a tenant administrator creates belongs to the tenant.
This covers groups, policies, proxy objects and virtual network cards.
Names only need to be unique inside the tenant.
Each tenant can hold up to 20,000 proxy objects.
See Policies for how policies work.
A tenant policy can only reference elements of its own tenant or global elements.
This applies to proxy objects (obj:<id>), virtual network cards (vnic:<id>) and links.
A tenant policy can only be attached to the nodes and groups of that tenant.
This rule also applies to the provider.
A global policy can only reference global elements.
The provider can attach it to any node, tenant nodes included.
Automatic imports
Some policy types import the existing configuration of a node: DHCP, DNS cache, Proxy PAC, Active Directory, firewall and FortiGate WCCP.
The imported policy, its proxy objects and its virtual network cards are created in the tenant of the node.
Import never reuses an element of another tenant or a global element.
Clusters
A slave node receives its policies through its master.
Artica Meta looks for the master among the nodes of the same tenant only.
Two customers can therefore use the same master address without conflict.
When the master and the slave belong to different tenants, nothing is delivered to the pair.
The tenant sees "master not managed" with the address reported by its own node.
What stays with the provider
These pages and actions remain reserved to the provider:
- The Meta tenants page, owners and tenant moves.
- Artica Meta parameters, mTLS clients and agent deployment.
- Adding, enrolling and deleting nodes, SSH upgrades and the updates black-list.
- Node connection settings (port, path prefix, address, system CA).
A tenant administrator can only change the name and description of a node. - Fleet dashboards, the reverse gateway and database maintenance.
The provider cannot open the integrated web console of a tenant node from the Meta console.
That console runs inside the Meta web origin.
A script planted on the node by the customer would then run with the provider session.
Open the node console directly instead.
The tenant administrators keep this button for their own nodes.
Deleting a tenant
A tenant can only be deleted when it is empty.
Move or delete its groups, policies, proxy objects and virtual network cards first.
Security notes
- Giving a node to a tenant gives the customer root access to the machine.
The remote shell, snapshot restore and free packages all run as root. - Treat a node that leaves a tenant as compromised and reinstall it.
A remote shell opened before the move stays open for up to 30 minutes. - Data reported by tenant nodes (host names, logs, service names) is controlled by the customer.
Known limits
- An Active Directory account member of more than about 150 groups gets no tenant at sign-in.
The lookup request becomes too large and is refused. - Operations already running on a node stay visible to its new tenant until they expire, one hour at most.
- An enrollment account name is unique across the whole server.
A tenant learns that a name is taken elsewhere.