Providing private cloud resources across multiple teams is a standard deployment model in the modern data center. Whether you’re splitting infrastructure between Finance and Engineering, giving unique customers their own isolated infrastructure, or managing dev, staging, and production as distinct environments, multi-tenancy is table stakes in a virtualized environment.
Deploying and managing isolated environments is a simple concept but a tricky implementation . Bolted-on multi-tenancy means separate configuration systems for identity, quotas, and networking. It means administrative overhead that compounds with every new tenant. It means security properties you can manage and report on in isolation but not across the whole stack.
Platform9’s Private Cloud Director (PCD) takes a different approach. Multi-tenancy is not a feature layer; it is the underlying model. Identity, resource governance, access control, and networking all speak the same tenant-aware language from day one. This article walks through how that works in practice, for practitioners who need to build and operate it.
The Three-Layer Architecture: Domains, Tenants, and Regions
PCD organizes multi-tenancy across two layers: an identity layer (domains and tenants) and an infrastructure layer (regions). The two compose cleanly. A tenant lives within a domain, and that tenant identity can hold resources in any region in the deployment.
Domains: The Root Boundary
A Domain is the top-level identity boundary. Each domain has its own users, groups, tenants, and authentication configuration. Tenant, user, and group names are unique within a domain, not globally, so administrators in one domain cannot see another domain’s identities or tenants.
Most single-organization deployments run entirely within the default domain. Additional domains exist for scenarios requiring identity-level separation: MSPs serving multiple customers, large enterprises with autonomous business units, or environments where one set of administrators should never see another’s tenants and users.
An important design detail: domain-level identity isolation does not require separate PCD installations. You get hard identity separation within a single platform.
Tenants: Where Workloads Actually Live
Within a domain, Tenants (called Projects in the API and CLI) are the primary unit of resource ownership and governance. A tenant defines which users can access which resources, how much they can consume, and what roles and access they hold. Compute, storage, and networking resources are all scoped at the tenant level.
Tenants are created directly from the PCD UI; no CLI required, no backend configuration. This self-service tenant lifecycle is a significant operational difference from legacy VMware environments, where equivalent isolation required Aria Automation and separate licensing.
The practical split: one tenant per department in an enterprise cloud, or one tenant per customer in an MSP model.
Regions: Infrastructure Placement and Scope
Regions represent physical data center locations within a PCD deployment. A region contains the hypervisor hosts, virtualized clusters, and networks that run workloads, and the Compute, Networking, Block Storage, and Image APIs are region-scoped. A tenant identity can hold workloads in any region in the deployment, giving organizations control over where workloads run for performance, compliance, or operational reasons.
A key relationship to understand: identity and infrastructure are orthogonal layers. Domains and tenants live in the identity layer; regions live in the infrastructure layer. A tenant identity can hold resources across multiple regions, and a region serves tenants from any domain authorized to use it. Regions define where infrastructure lives; tenants define who can use it and how much.
Architecture Summary
Identity layer: Domain → Tenants, Users, Groups, RBAC.
Infrastructure layer: Region → Clusters, Hosts, Networks.
Tenants own resources; regions host them. A tenant’s resources can live in any region in the deployment.
Identity Service: The Backbone of Every Tenant Boundary
Private Cloud Director ships with an Identity Service built on Keystone that handles authentication, authorization, service discovery, and token management and it does so with tenant context baked in at every layer.
Every API call, every UI action, every CLI command is processed against an identity that is scoped to a domain or tenant. There is no elevated ambient access that bypasses tenant boundaries. Role assignments have three components: a Role, a Resource, and an Identity. Nothing is implicitly inherited across tenant boundaries.
Authentication Methods Available
- Local accounts — built-in authentication managed within PCD
- SAML 2.0 Single Sign-On — connects to Okta, Microsoft Entra ID (Azure AD), and other enterprise IdPs
- Multi-Factor Authentication (MFA) — layered on top of any of the above for additional assurance
The SAML 2.0 integration deserves particular attention. When connected to an enterprise IdP, Private Cloud Director becomes a consumer of your corporate identity: users log in once through their existing credentials, and PCD uses that authenticated identity to enforce tenant-scoped access. Onboarding and offboarding happen in one place (your IdP), but authorization policy stays in PCD. These controls remain fully enforced regardless of whether the user is operating through the UI, via API, or through the pcdctl CLI.
Role-Based Access Control
PCD enforces least-privilege access through three predefined roles, scoped at either the domain or tenant level:
- Administrator — full control over domains, tenants, and infrastructure
- Self-Service User — permissions limited to what has been explicitly granted within the tenant
- Read Only User — can observe configurations but cannot make changes
The operational recommendation is direct: assign the least-privileged role required, avoid sharing administrative accounts across tenants, and use groups (which are also domain-scoped) to manage role assignments at scale rather than assigning roles individually.
Resource Governance: Tenant Quotas, User Quotas, and VM Leases
Isolation prevents unauthorized access. Quotas prevent something quieter but just as sinister: resource exhaustion. Without enforced limits, a single misconfigured VM or a careless user can silently starve shared infrastructure, degrading performance for every other tenant before anyone notices.
PCD enforces resource governance at several levels:
Tenant Quotas
Administrators can set explicit limits on what a tenant can consume across compute, memory, storage, and networking resources. These are hard limits. A tenant that hits its quota cannot provision additional resources regardless of how much physical capacity remains. This makes capacity planning deterministic: you allocate what you intend to allocate, and you can model the worst-case consumption per tenant.
Quota adjustments are non-disruptive. Operators can increase tenant limits without downtime or workload impact, which means governance can evolve as team needs change without requiring maintenance windows.
User Quotas
Within a tenant, PCD extends governance down to the individual user level. In shared environments — internal private clouds, lab environments, managed service offerings — not every user should have access to the full tenant quota. Per-user resource limits let operators define how much of the tenant budget any individual can consume, which prevents any single user from monopolizing shared capacity.
VM Leases
VM leases are a governance control that addresses a specific operational pattern: temporary workloads that quietly become permanent. In lab environments and development tenants especially, VMs spun up for a specific task frequently outlive their purpose, consuming quota and adding noise to capacity planning.
With VM leases, administrators define maximum lease durations for virtual machines within a tenant. A VM created with a lease will expire at the defined deadline. This encourages responsible usage, enforces cleanup discipline without manual operator intervention, and ensures that capacity allocated for temporary workloads actually gets reclaimed.
Why This Matters in Practice
The combination of tenant quotas + per-user limits + VM leases gives operators three distinct controls at three distinct scopes. It is not redundant; each layer addresses a different failure mode: tenant quotas prevent inter-tenant contention, user quotas prevent intra-tenant monopolization, and VM leases prevent lifecycle sprawl.
Multi-Tenant Networking: Isolation at the Data Plane
Identity controls who can act. Network isolation controls what can communicate. In a shared private cloud, these two planes must align; a tenant boundary that exists at the access control layer but not at the network layer is incomplete.
PCD extends tenant boundaries into the networking layer. Each tenant operates within its own logically isolated network environment:
- Virtual networks are defined per tenant
- Traffic segmentation via VLAN or VXLAN
- DNS services scoped to individual tenants
- Security groups enforce per-tenant firewall policy
The result is that workloads behave as though they are running on dedicated network infrastructure, even when the underlying physical network is shared. Cross-tenant traffic is not possible unless explicitly configured. Isolation is the default, not something you have to manually enforce.
For networking-heavy operations Private Cloud Director’s networking layer also includes Distributed Virtual Routing (DVR), Load Balancer as a Service (LBaaS), BGP support, and QoS configuration, all of which operate within the tenant model. A tenant’s network resources are as isolated as its compute and storage.
Day-2 Operations: What Multi-Tenancy Looks Like at Scale
A multi-tenancy architecture is only useful if it remains manageable as the number of tenants grows. The operational patterns that work for five tenants need to work for fifty.
API-Driven Tenant Provisioning
Tenants can be provisioned programmatically via the PCD API. This means tenant creation, quota assignment, user enrollment, and role assignment can all be codified in automation scripts or infrastructure-as-code workflows. Repeatable onboarding, where every new tenant receives the same baseline configuration, becomes a solved problem rather than a manual checklist.
Audit Logging and Compliance Reporting
Every action in Private Cloud Director is tied to an identity scoped to a tenant. This produces an audit trail that is naturally segmented: you can review what happened within a specific tenant without wading through the activity of every other tenant on the platform. For organizations with compliance requirements — SOC 2, ISO 27001, internal governance frameworks — this per-tenant auditability can significantly reduce workload when preparing for an audit.
Integration with Automation Tooling
PCD’s API-first design means it integrates with existing DevOps and IT automation workflows. Tenant lifecycle management: creation, quota changes, user provisioning, deprovisioning, can be embedded in the same tooling used for the rest of your infrastructure. This eliminates the one-off manual processes and potential misconfiguration that complicate legacy virtualization platforms.
Common Deployment Patterns
Enterprise Departmental Cloud
A single domain covering the organization. One tenant per department or team, each with its own quotas and RBAC. Shared physical infrastructure, isolated logical environments. Centralized identity via SAML 2.0 connected to the corporate IdP.
Multi-Region Enterprise
Tenants operate across multiple regions, placing workloads based on geography or compliance requirements. Centralized identity and policy enforcement with distributed infrastructure. Useful for organizations with regulatory requirements about where specific data categories can be processed.
Managed Service Provider
One domain per provider organization. One tenant per customer. Strong isolation with no cross-customer visibility. Centralized operations team manages quotas and onboarding; customers interact through scoped self-service portals within their tenant.
Conclusion
The difference between bolted-on multi-tenancy and native multi-tenancy shows up in operations. When identity, quotas, access control, and networking are separate systems that happen to be configured in parallel, the complexity multiplies with every tenant. When they share a common tenant-aware model, deploying new tenants is additive, not exponential.
Platform9 Private Cloud Director makes multi-tenancy a first-class platform primitive: domain-level isolation, tenant-scoped resource governance with enforced quotas and VM leases, SAML 2.0 SSO integrated with enterprise identity providers, scoped RBAC that cannot bleed across tenant boundaries, and tenant-aware networking isolation by default.
For practitioners evaluating VMware replacements: PCD delivers the tenant isolation and governance that VMware required Aria Automation to approximate — without the additional licensing, without the operational overhead of stitching together separate systems, and with a self-service model that does not require platform team intervention for routine operations.
The platform documentation for Identity & Multi-Tenancy, including the specific configuration steps for tenant creation, quota settings, SAML SSO setup, and VM lease configuration, is available at docs.platform9.com/private-cloud-director.
