Multi-Tenant Admin Center

MSPs and security teams managing multiple environments use the Admin Center to spin up a dedicated Sentinel instance per client. Each instance has its own data, rules, users, and alerts — with shared super-admin access across all of them.

What Gets Isolated

Each tenant instance runs in its own Docker container with its own:

  • Elasticsearch indices (prefixed by organization ID + instance name)
  • User database (tenant admins can create their own operators/viewers)
  • Rules (YAML detection rules per client)
  • Alerts & response actions
  • Syslog + NetFlow + SNMP ports (auto-allocated from ranges — e.g. 1600/1601/1602 for syslog)
  • Web UI port (auto-allocated — e.g. 9000/9001/9002, fronted by wildcard subdomain)

Automated Provisioning

Creating a new instance from the Admin Center UI triggers end-to-end automation:

  1. DNS-safe slug generated from the client name (ACME Corp. → acme-corp)
  2. A record created via the GoDaddy API: <slug>.yourdomain.com → <public-ip>
  3. Port allocation from configured ranges
  4. Docker container launched with per-instance Elasticsearch prefix
  5. Nginx host map updated and reloaded — HTTPS served on wildcard cert immediately
  6. Super-admin seeding — every global super-admin is provisioned into the new instance's user index with the same password hash

One wildcard cert, any number of tenants

Sentinel uses a wildcard Let's Encrypt cert (*.yourdomain.com) so adding a tenant doesn't require issuing a new certificate. Renewals are automatic via certbot's scheduled timer.

Roles

super_admin   Global; can log into any instance, manages all orgs + users
org_admin     Scoped to one organization; full control of that client's instances
org_operator  Scoped; can start/stop/view instances, not delete
viewer        Scoped; read-only

Super-Admin Single Sign-On

When you create a super-admin in the Admin Center (or change their password), the user is automatically propagated to every existing instance's user index. They can log into any client's Sentinel with the same credentials. Demoting or deleting a super-admin cleans them out of every instance too.

Note

The password hash is copied directly — both the Admin Center and the SIEM use bcrypt with the same cost factor, so no transform is needed and no password ever touches the network unencrypted.

Creating a Client

From the Admin Center:

  1. Clients → New Client — creates an organization
  2. Instances → New Instance — pick the organization, give the instance a name
  3. Within seconds: DNS resolves, HTTPS works, super-admins can log in. The tenant's own admin can then be added via Users scoped to their organization.

Inline Organization Creation

When creating an instance, the organization dropdown includes a "+ Create new organization" option that spawns a mini-form inline. Handy for the common case of a new client getting their first instance.

Rolling Upgrades

When you ship a new Sentinel image, the Admin Center's Update All Instances button:

  1. Optionally rebuilds the Docker image
  2. Stops each tenant container
  3. Recreates it from the new image, preserving volumes (config, ES data, users)
  4. Reports per-instance success/failure

Per-Instance Syslog Routing (one public IP, many tenants)

The default model gives each instance a unique internal port (1600, 1601, 1602…). Customers configure their UniFi devices to send syslog / NetFlow / SNMP to that specific port.

For customers who can only use default ports (514 / 2055 / 162), a source-IP dispatcher pattern is available — contact support for the configuration.

Security Notes

  • Each instance's ES indices are namespaced with a UUID — impossible for one tenant to query another's data
  • The wildcard cert is the only shared HTTPS state; compromise of one tenant doesn't compromise others
  • Admin Center super-admin actions are audit-logged to admin-center-audit
  • Password changes are propagated synchronously; delete/disable flows through the same path