Multi-tenancy is the foundation of any cloud business. Without it, every customer needs dedicated hardware, and the economics don't work. But multi-tenancy introduces a fundamental security challenge: ensuring that tenant A can never access tenant B's data, network, or compute resources.
At PLATFORMA, tenant isolation is enforced at six layers. A breach at any single layer cannot compromise another tenant.
Layer 1: API Authentication
Every API request is authenticated via httpOnly session cookies. The session contains the tenant ID, which is injected into every downstream service call. There is no API parameter that allows specifying a different tenant ID — the tenant context comes exclusively from the authenticated session.
We deliberately chose cookies over JWT tokens for a security reason: cookies can be revoked server-side instantly. If a session is compromised, we invalidate it and the attacker loses access immediately. With JWTs, you're stuck waiting for the token to expire.
Layer 2: Database Isolation
All database queries include a tenant ID filter. This is enforced at the ORM level — every Mongoose model includes a `tenantId` field, and every query method automatically adds the tenant filter. A developer cannot accidentally write a query that returns cross-tenant data.
We run automated tests that attempt to access data across tenants. Every API endpoint is tested with authentication from tenant A and a resource ID belonging to tenant B. The expected result is always 404 — the resource doesn't exist from tenant A's perspective.
Layer 3: Network Isolation
In OpenStack, each tenant gets its own Neutron network, subnet, and router. Security groups enforce that VMs from different tenants cannot communicate directly. Even if a VM is compromised, the attacker cannot reach VMs belonging to other tenants.
For Kubernetes tenants, we use namespace isolation with network policies. A NetworkPolicy denying all ingress from other namespaces is applied by default. Tenants can allow traffic within their own namespace but cannot open connections to other tenant namespaces.
Layer 4: Storage Isolation
Each tenant's block storage volumes are only attachable to their own instances. Cinder enforces this at the project level. When a tenant deletes a volume, the underlying storage is zeroed before being returned to the pool — no data remnants.
Layer 5: Billing Isolation
Billing data is scoped per tenant. Invoices, usage records, and payment methods are all tenant-scoped. The billing API never returns data from another tenant, and the Stripe integration uses separate Stripe customers for each tenant.
Layer 6: Portal Isolation
The white-label portal is tenant-scoped by domain. A customer logged into portal.clientA.com cannot access any data from portal.clientB.com, even if they somehow obtained valid session cookies — the cookie domain prevents cross-site usage.
Continuous Verification
Isolation isn't something you set and forget. We run weekly automated penetration tests that specifically target cross-tenant access paths. We also maintain a bounty program for security researchers who find tenant isolation bypasses. So far, zero bypasses in production.