Project-Overview
Projects in Zergaw CloudStack serve as organizational units that allow users within the same Domain to collaborate, manage, and share virtual resources effectively. They function as dedicated, secure workspaces for teams. The server as a way to organize accounts and resources. Users (accounts) can group themselves into projects so they can share resources such as instances, snapshots, templates, data disks, and IP addresses.
Resources created within a project belong only to the project, not to an account. They can be used only within that project.
Collaboration and Membership
Team Grouping and Resource Sharing
- Purpose: Projects enable users to group themselves into project teams. This is the primary mechanism for collaboration and resource sharing.
- Shared Resources: All members of a project can view, manage, and share the resources created by any other member within that project. This includes key virtual assets like Instances (VMs), Snapshots, Templates, Data Disks, and IP Addresses.
- Membership Flexibility: A single User can be a member of any number of projects.
- UI Focus: Users can switch their view in the UI to show only information and resources directly related to a chosen project (e.g., project Instances, project alerts, team members).
Project Administration
- Default Administrator: The User who initially creates the project automatically becomes the Project Administrator.
- Admin Privileges: Project Administrators have the power to:
- Add or remove other members (Users or entire Accounts) from the project.
- Promote or demote other Users within the project.
- Set resource limits for the project (as long as these limits are below the global defaults set by the Root Administrator).
- Delete the project.
- Multiple Admins: It is possible for a single project to have multiple Project Administrators for redundancy and shared oversight.
Resource Ownership and Scope
A project defines a boundary for resource ownership and usage.
Project-Owned Resources
- Ownership: Resources created inside a project are owned by the project itself, not by the individual Account or User who launched them.
- Scope: These resources can only be used and managed within that project.
- Member Removal: If a Project Administrator removes a User from the project, any resources (like Instances) that User created will remain with the project because the project is the true owner.
Network Isolation and Sharing
- Project-Level Networks: Projects can create dedicated, isolated networks to manage traffic exclusively for their members. These networks can offer services like Port Forwarding, Load Balancing, VPN, and Static NAT.
- Accessing External Resources: Projects can utilize resources that are explicitly shared, such as:
- Shared Networks or Public Templates available to all entities in the Domain.
- Private Templates (if the owner grants the project permission).
Access Control: Project Roles vs. Account Roles
Zergaw CloudStack uses a two-tiered Role-Based Access Control (RBAC) system for projects, which provides fine-grained control over access.
Project Roles (The Restrictor)
- Purpose: Project Roles are associated with a User or an Account specifically within the context of a project. They are used to further restrict access to operations (APIs) beyond what the Account Role already dictates.
- Granularity: You can add specific Users or entire Accounts to a project.
- Note: If an entire Account has already been added to a project, you cannot then assign a separate Project Role to an individual User of that Account.
Role Hierarchy and Rules
| Role Type | Default Permission | Effect on Access |
|---|---|---|
| Account Role | Defines the maximum possible operations for the User/Account (e.g., what they can do anywhere in the Domain). | The ultimate permission ceiling. |
| Project Role | Defines specific permissions within the project. | Restrictive (Narrower Scope). |
Key Rule: Project Roles are Restrictive, Not Permissive.
- Account Role Precedence (DENY): The Account Role always determines the highest level of access. If an action is prohibited (DENY) by the User's Account Role, the Project Role cannot override it to allow the action.
- Default Project Behavior: If a User or Account is added to a project without a specific Project Role, they will retain the full access granted by their standard Account Role when working in that project.
- Fallback: If a Project Role exists but has no explicit "Deny" rule for a specific action, the system will fall back to the Account-level role to determine permission.