Domains represent the largest organizational units for grouping related entities (Accounts, Projects and Sub-Domains) and establishing administrative boundaries. They are the backbone of Zergaw CloudStack's multi-tenancy model.
Hierarchical Structure: Domains are arranged in a tree structure. The top-level is the Root Domain, which holds all resources and other Domains. Every Domain is a child of the Root Domain, allowing for logical segmentation.
Logical Grouping: Domains typically group Accounts that share a logical relationship.
Example (Service Provider): A Domain can be created for each major reseller or enterprise client.
Example (Large Organization): Domains can represent different departments like IT-DevOps or Finance-Production.
Unique Naming: A Domain name in Zergaw CloudStack must be unique within its parent Domain. In our platform, we map customer or enterprise Domains to their actual organizational names for clear identification and structured tenancy.
For example, if an enterprise named xyz.com is onboarded to Zergaw CloudStack’s IaaS platform, its corresponding CloudStack Domain would be:
enterprise/xyz.com
This naming has no dependency on the organization’s real DNS domain and does not require any DNS configuration. The domain name is simply used as a logical identifier within Zergaw CloudStack. Because domain names must be unique, Zergaw CloudStack leverages that uniqueness to represent each tenant cleanly and unambiguously.
During the onboarding and KYC process, you will be asked to provide your organization’s domain name. If this field is left blank, Zergaw CloudStack will automatically generate a unique domain name for your enterprise to ensure proper identification and isolation within the platform.
An Account is the fundamental unit for resource ownership within Zergaw CloudStack. It is the fundamental security and resource boundary inside a Domain.
Customer Representation: An Account usually represents a group of users or a specific customer that consumes cloud resources which shares the same roles. An Account can contain one or multiple Users that
share the same pool of resources.
share the same quotas and limits.
Activities by any user are attributed to the Account owner.
Resource Ownership: This is critical: Resources belong to an Account or Project, not to individual Users. This includes Virtual Machines (Guest Instances), Volumes, Snapshots, and Public IPs.
Resource Limits: The Root Administrator can set global resource limits, which can be further refined by Domain Administrators for Accounts within their Domain. These limits control maximum consumption (e.g., max number of running VMs, max storage gigabytes).
Account Types: Accounts have an associated Role which defines their fundamental type and access privileges:
Domain Administrator: Administrative privileges limited to their own Domain and its subdomains.
User/End User: Limited access to manage and consume resources owned by their Account.
Authentication Layer: Users are the entities that log in to the Zergaw CloudStack UI or use the API via their generated API Key and Secret Key.
Inherited Permissions: Users in the same Account inherit the same privileges determined by the Account's assigned Role. They are not isolated from other Users within the same Account.
Isolation: Users are fully isolated from Users belonging to different Accounts.
Unique Username: A username must be unique across all Accounts within the same Domain. The same username can exist in different Domains.
Example:user-A in Account-X/Domain-1 and user-A in Account-Y/Domain-2 is acceptable.
A Role defines a set of allowed functions and access permissions. In Zergaw CloudStack deployments, roles are dynamic and highly customizable, implementing the principle of Role-Based Access Control (RBAC).
API Enforcement: Roles enforce access rules by allowing or disallowing specific API requests.
Dynamic RBAC (Recommended): The Root Administrator can create custom roles with granular permissions by specifying which API calls are allowed or denied for that role. This enables fine-tuned access control.
Default Roles: Zergaw CloudStack comes with several default roles that define access scope:
Role
Scope of Access
Primary Functions
Domain Admin
Limited to their specific Domain and its subdomains.
Creating Accounts/Users within their Domain, managing resources, setting resource limits (must be lower than Root limits), and creating offerings within their scope. No visibility into physical servers.
Compute Admin
Limited to their specific Domain and its subdomains.
Creating and Manage Compute Resources
Network Admin
Limited to their specific Domain and its subdomains.
Create and Manage Network Resources
Storage Admin
Limited to their specific Domain and its subdomains.
Create and Manage Storage Resources
Read-Only User
Limited to their specific Domain and its subdomains.
Designed for monitoring, allowing only list* or get* API calls.
Resource ownership is the cornerstone of Zergaw CloudStack's operational model.
Ownership is at the Account Level or Project Level: All consumed resources (VMs, Volumes) are tied to a specific Account or Project. This centralized ownership allows for easy resource tracking.
Once a customer completes the signup and resource acquisition process through the billing portal, the portal will:
Create a domain dedicated to that customer.
Assign the purchased resource quota to the customer’s domain.
Create an account within that domain and assign it the Domain Admin role.
Create a user within that account to enable login access.