Tenant Management allows users to create and manage their organization
structures based on their actual business scenarios. It also provides features such as
project-based resource access control, ticket management, and independent zone
management.
The Tenant Management feature is provided in a separate module. Before
you can use this feature, you need to purchase the Plus License of Tenant Management, in
addition to the Base License.
Definitions
Definitions related to Tenant Management:
Personnel and Permissions: The Tenant Management system is structured on the
basis of personnel and permissions. You can create departments and roles
based on your business needs, and grant a variety of permissions to your
users.
Organization: Organization is the basic unit in Tenant
Management. You can create an organization or synchronize an organization
through SSO. The organizations can be categorized into
the default department and the customized department. You can customize a
new team and a sub-department. The new team, usually a company or subcompany
(subsidiary), can be used to create multi-level departments. An
organizational structure tree is displayed in cascade, and you can directly
get a complete picture of the organization structure.
Note: Notice that
project members can only view the organization structure where their
team belongs to.
User: A user is a natural person that constructs the most basic
unit in Tenant Management. There are local user and the SSO user on ZStack Cloud.
Local User: A user that is created on the Cloud.
A local user can be added to an organization or a project, and
attached to a role.
SSO User: A user is that is synchronized
to the Cloud through SSO. A SSO user can
be added to an organization or a project, and attached to a role,
and changed to a local user.
Note:
To log in to the Cloud, tenant management users need to use the
Tenant login entry.
Local users log in to the Cloud via the Local User
entry.
AD/LDAP users log in to the Cloud via the AD/LDAP User
entry.
OIDC/OAuth2/CAS users log in to the Cloud from the
SSO application without the password.
The admin and platform manager can view the list of all
users.
If you created an organizational structure tree on the Cloud,
platform members can view only the list of users belonging to
the organizational structure. If you did not create any
organizational structure tree, platform members can view all
users.
User Group: A user group is a collection of natural persons or a
collection of project members. You can use a user group to grant
permissions.
Role: A role is a collection of permissions that can be granted
to users. A user that assumes a role can call API operations based on the
permissions specified by the role. Roles are categorized into platform roles and
project roles.
Platform Role: After a user has a platform role attached, the user
will have the management permission of the corresponding zone.
Permissions of a platform role take effect only in the zone managed
by the user.
Project Role: After a user joins a project and have a project role
attached, the user will have the permission to use the project and
manage the data in the project.
Note:
One user can have both platform roles and project roles
attached.
One user can have more than one platform role or project role
attached.
In a project, if a user has multiple project roles attached, the
user will have all the permissions attached to the project
roles.
SSO: The Single Sign-On service provided by the Cloud. It
supports seamless access to SSO systems. Through the service, related SSO users can
directly log in to the Cloud and manage cloud resources. Currently,
AD/LDAP/OIDC/OAuth2/CAS servers can be added.
AD authentication:
Active Directory (AD) is a directory service
designed for Windows Standard Server, Windows Enterprise Server,
and Windows Datacenter Server. AD provides an independent,
standard login authentication system for increasingly diverse
office applications.
AD users or organizations can be
synchronized to the user list or organization of ZStack Cloud via an AD server, while specified
AD login attributes can be used to directly log in to ZStack Cloud.
LDAP authentication:
Lightweight Directory Access Protocol (LDAP)
can provide a standard directory service that offers an
independent, standard login authentication system for
increasingly diverse office applications.
LDAP users can
be synchronized to the user list of ZStack Cloud via an LDAP server, while
specified LDAP login attributes can be used to directly log in
to ZStack Cloud.
OIDC authentication:
OpenID Connect (OIDC) is a set of
authentication protocols based on the OAuth2 protocol, and it
allows the clients to verify the user identity and obtain basic
user configuration information.
The user information can
be synchronized to the Cloud according to the mapping rules via
an OIDC server, and users of the OIDC authentication system can
log in to the Cloud without the password.
OAuth2 authentication:
Open Authorization 2.0 (OAuth2) is a set of
authorization protocol standards that can authenticate and
authorize users to access related resources. The Cloud currently
only supports authorization through the authorization
code.
The user information can be synchronized to the
Cloud according to the mapping rules via an OAuth2 server, and
users of the OAuth2 authentication system can log in to the
Cloud without the password.
CAS authentication:
Central Authentication Service (CAS) is a set
of single sign-on protocols that allow website applications to
authenticate users.
The user information can be
synchronized to the Cloud according to the mapping rules via a
CAS server, and users of the CAS authentication system can log
in to the Cloud without the password.
Project Management: Project management allows you to schedule resources
based on projects. You can create an independent resource pool for a
specific project. By this way, you can better manage the project lifecycle
(including determining time, quotas, and permissions) to improve cloud
resource utilizations at granular, automatic level and strengthen mutual
collaborations between project members.
Project: A project is a task that needs to be accomplished by
specific personnel at a specified time. In Tenant Management, you can plan resources
at the project granularity and allocate an independent resource pool to a project.
The word Tenant in Tenant Management mainly refers to projects. A project is
a tenant.
When you create a project, you need to specify the resource quotas
and reclaim policy, and add project members.
The basic resources (instance offering, image, network, and other
resources) on the Cloud are suggested to shared or created in
advance.
Ticket Management: To better provide basic resources efficiently for each
project, project members (project admins, project managers, or regular
project members) can apply for tickets to obtain cloud resources. Tickets
are reviewed and approved according to custom ticket review processes of
each project. Finally, the admin, project admins, department managers, and
the customized approvers approve the tickets. Currently, five types of
ticket are available: apply for VM instances, delete VM instances, modify VM
configurations, modify project cycles, and modify project quotas.
Process Management: Process management is part of ticket management that
manages the processes related to the resources of projects. Processes can be
categorized into default processes and custom processes.
Default process: The project member submits a ticket to the admin,
and then the admin approves the ticket. This process applies to the
following scenarios:
The tickets that are not configured with a ticket
process.
The tickets which apply for modifications on the project
cycle.
The tickets which apply for modifications on the project
quota.
If the custom ticket process is deleted, the tickets will be
resubmitted automatically via the default ticket
process.
Custom process: The project member submits a ticket. The project
member makes process settings via process management. Finally, the
admin or project admin approves the ticket. This process applies to
the following scenarios:
The tickets created to apply for VM instances, delete VM
instances, and change VM configurations will be
prioritized to be submitted via the configured, custom
ticket process.
If you modify the valid ticket process, the tickets will be
automatically resubmitted via this modified, custom ticket
process.
If you modify the invalid ticket process, you need to
resubmit the tickets manually by using this modified, custom
ticket process.
My Approval: In the Cloud, only the administrator and project
administrators are granted approval permissions. the administrator and project
administrators can approve or reject a ticket. If a ticket is approved, resources
are automatically deployed and allocated to the specified project.
Note: The platform admin and regular platform members do not have the
permission for ticket management, and the menu My Approval is not
supported for these two roles.
Architecture
The Tenant Management mainly includes four subfeatures, including
project management, ticket management, independent zone
management, and SSO.
Platform Management:
To effectively manage the
Cloud, the platform user (platform admin/regular platform member) can
cooperate with the super administrator to manage and operate the Cloud
together. ZStack Cloud provides various system
roles such as Platform Admin Role and Dashboard Role. You can also
satisfy various usage scenarios by creating custom roles at the API
level.
Project Management:
The project management is
project-oriented to plan for resources. Specifically, you can create an
independent resource pool for a specific project. Project lifecycles can
be managed (including determining time, quotas, and permissions) to
improve cloud resource utilizations at granular, automatic level and
strengthen mutual collaborations between project members.
Ticket Management:
To better provide basic
resources efficiently for each project, project members (project admins,
project managers, or regular project members) can submit tickets to
obtain cloud resources. Tickets are reviewed and approved according to
custom ticket review processes of each project. Finally, the admin,
project admins, department managers, and the customized approvers
approve the tickets. Currently, five types of ticket are available,
including applying for VM instances, deleting VM instances, modifying VM
configurations, modifying project cycles, and modifying project
quotas.
Independent Zone Management:
Usually, a zone
corresponds to an actual data center in a place. If you isolated
resources for zones, you can specify the corresponding zone admins for
each zone to achieve independent managements of various machine rooms.
In addition, the admin can inspect and manage all zones.
SSO:
The SSO
authentication is a SSO service provided by
ZStack Cloud. You are allowed to seamlessly
access the SSO system. The corresponding
account system can directly log in to the Cloud to conveniently use
cloud resources. Currently, you can add an AD/LDAP/OIDC/OAuth2/CAS
server.
Differences in Roles and relevant Permissions
Definitions related to Tenant Management Account System:
admin: A super administrator who owns all permissions. Usually, the admin is
the IT system administrator who have all the permissions.
Local User: A user that is created on the Cloud. A local user can be added
to an organization, added to a project, and attached to a role.
SSO User: A user that is synchronized to the Cloud through SSO
authentication. A SSO user can be added to an organization, added to a
project, and attached to a role.
Platform User: A user that is not added to a project
yet, including platform admin and the regular platform member.
Platform Admin: A user that has the platform admin role attached. A platform
admin who has been allocated a specified zone or all zones manages the data
center of the allocated zone or zones.
Head of Department: The admin can assign a head for the
department, and this role is used for identification only. When a head of
department becomes a project member, the head of a department has the
permission to check department bills.
Project User: A user who has joined a project, including
project admin, project operator, and regular project member.
Project Admin: A user that has the project admin role
attached. A project admin is responsible for managing users in a project,
and has the highest permission in a project.
Project Manager: A user that has the project manager
role attached. A project manager assists project admins to manage projects.
One or more project members in the same project can be specified to act as
project managers.
Department Manager: The admin can assign a department
manager for the new team. It is a type of platform role and is responsible
for the operation management of the entire department, including project
management, ticket management, checking bills, and department critical
resource monitoring.
Root Role: The root role is used to limit the permission scope of the custom
role. The permission of a custom role is inherited from its root role, and
is a subset of the root role permission.
Quota: A measurement standard that determines the total
quantity of resources for a project. A quota mainly includes the VM instance
count, CPU count, memory capacity, maximum number of data volumes, and
maximum capacity of all volumes.
Project Reclaim Policy: You need to specify a project
reclaim policy when you create a project. There are three types of project
reclaim policy, including unlimited, reclaim by specifying time, and reclaim
by specifying cost.
Unlimited: After you create a project, resources within the project
will be in the enabled state by default.
Reclaim by Specifying Time:
When the expiration date for a project is less than 14 days,
the smart operation assistant will prompt you for The
license will be expired after a project member logs
in to the Cloud.
After the project expired, resources within the project will
be collected according to the specified policy. The policy
includes disabling login, preventing project members from
logging in to the Cloud, stopping resources, and deleting
projects.
Reclaim by Specifying Cost: When the project spending reaches the
maximum limit, resources within the project will be collected
according to the specified policy. The policy includes disabling
login, preventing project members from logging in to the Cloud,
stopping resources, and deleting projects.
Access Control: When you create a project, you can
specify whether to allow or prohibit project members to or from logging in
to the project within a specified time period. There are two types of access
control policy: login allowed time and login prohibited time.
Login Allowed Time: You can set the time when members in the project
can log in to the project by day or week. After setting, the project
members can log in to the project only during the login allowed time
period.
Login Prohibited Time:You can set the time when members in the
project cannot log in to the project by day or week. After setting,
the project members cannot log in to the project during the login
prohibited time period.
Security group constraint: If you enable security group constraint, when a
project member creates a VM instance, the VM instance must have one or more
security groups attached.
Before you can enable security group constraint for the project,
make sure that the project security group quota is set to 1 or
higher.
If you enable the security group constraint for the project, a
default security group is created when the project is created.
The tenant management system grants users a variety of permissions. The permissions
of different user roles are as follows:
Differences in Accounts Login in Tenant Management
Admin can log in to the Cloud via Account
Login.
By using Chrome or Firefox, go to
the Account Login page via
http://management_node_ip:5000/#/login. To log in to
the Cloud, the admin must enter the corresponding user name and
password.
Figure 1. Main Login Page
For users (platform admin, platform user, project admin, project
manager, regular project member, or department manager), log in to
the Cloud via Project Login.
By using Chrome or
Firefox, go to the Project Login page via
http://management_node_ip:5000/#/ project. To log in
to the Cloud, enter the corresponding user name and password.
Specifically, the Cloud has two login entrances for Project
Login as follows:
Local user: the user created on the Cloud. Log in to the
Cloud via Local User.
AD/LDAP user: the SSO user synchronized to the
Cloud via the SSO. Log in to the
Cloud via AD/LDAP User, as shown in Project Login
Page.
After the successful login, you can select the
platform or project to be managed to log in to the corresponding
management interface.
Figure 2. Tenant Login Page
Feature Differences from Various
Perspectives
Feature Menu
admin/Platform Admin/Regular Platform
Member
Project Admin/ Project
Manager
Department Manager
Regular Project Member
Organization
○
○
○
○
User
○
○
○
×
Role
○
○
○
○
Project Member
×
○
×
○
User Group
○
○
○
○
SSO
○
×
×
×
Project
○
×
○
×
Process Management
○
×
×
×
My Tickets
×
○
×
○
My Approval
○
○
○
×
Differences in Permissions of Platform/Project Roles
Platform Roles: admin, platform admin, department manager, and
regular platform user. The permissions corresponding to these
roles are differentiated as follows:
Role
Difference
admin
A super administrator who
owns all permissions.
Platform Admin
A platform admin is a type
of administrator who has been allocated a
specified zone or all zones, and assists the admin
to jointly manage the Cloud. A platform admin has
all the permissions that the admin has, except the
following:
A platform admin is allocated a specified zone
or all zones, and has the permissions to manage
resources in the zone or zones only. Currently, a
platform admin is not granted relevant permissions
to create or delete zones.
A platform admin does not have the permissions
related to ticket management, and the menu
My Approval is not
displayed for this role.
A platform admin does not have the permissions
related to certificate management, and cannot
perform actions such as uploading a
certificate.
Department Manager
The department manager is a
role who has been allocated a specified
department, which can be designated by the admin
for the new team and responsible for managing the
whole department. A department manager has the
following permissions:
View homepage: Allows you to view the summary
of project resources in the department under the
management only.
View the Cloud monitor: Allows you to view the
monitoring information of critical resources of
the department under your management.
View organizations: Allows you to view the
organizational structure of the Cloud, but not to
perform related operations.
View users: Allows you to view the user
information on the Cloud, but not to perform
related operations.
View user groups: Allows you to view the user
group information, but not to perform related
operations.
Viewing roles: Allows you to view the system
project roles of the Cloud, the project roles
whose owner is the admin, and the project roles
whose owner is the management department (and
sub-departments).
View projects and project-based operations:
For projects under the managed department (and
sub-departments), you can view, edit, and add
project members. Setting a department, changing
billing prices, generating project templates, and
setting logon time limits for projects are not
supported.
Ticket approval: Supports ticket approval, but
the menu Process Management
is not displayed.
View/Export bills: Allows you to view or
export project bills and departmental bills of the
department (and sub-departments) under your
management.
Regular Platform
Member
Platform members other than
the platform admin. A Platform member has all the
permission that the admin has, except the
following:
A regular platform member does not have the
permissions related to ticket approval, and the
menu My Approval is not
displayed for this role.
A regular platform member can view users who
are in the same organizational structure
only.
Ungranted permissions.
Project Roles: project admin, project manager, and project
member. The permissions corresponding to these roles are
differentiated as follows:
A project admin can specify one or more project members
in the same project to act as project managers,
assisting project admins to manage projects.
A project manager has all the permissions that a project
admin has, but
Advantages
The Tenant Management of ZStack Cloud has the following
advantages:
Full-featured: Tenant Management provides users with a range of features
such as organization structure managements, project-based resource access
control, ticket management, and independent zone management.
User-friendly: Tenant Management allows you to manage the operation
permissions of different roles in a multi-level organizational structure,
making the organizational management more flexible and user-friendly.
Cost-effective: Each organization has different kinds of departments. In a
traditional IT company, resources are allocated to these departments based
on their actual needs, and permissions are assigned as needed as well.
Against the backdrop of cloud migration, the management over the departments
is achieved on the cloud to minimize the management costs.
Scenarios
Each organization has its own administrative departments. In a traditional IT
company, resources are allocated to administrative departments based on their actual
needs, and permissions are assigned as needed as well. After companies migrate their
business to the cloud, they expect to enjoy the same experience in resources
allocation and permissions assignment on the cloud, which is compatible with the
management by administrative departments.
The Tenant Management of ZStack Cloud provides users with a
range of features such as organization structure managements, project-based resource
access control, ticket management, and independent zone management. Through the
division of the organizational structure, it provides the same management as the
administrative department and minimizes the management costs.
Typical Practices
Quick Start with Tenant Management
About this task
Tenant Management module is the office automation (OA) system provided by ZStack Cloud. It supports basic features such as organization,
user, and project management. In the mean time, it also offers advanced features
such as 3rd-party authentication, ticket management, and independent zone
management. This scenario takes basic features as an example to introduce you the
quick start guide for Tenant Management.
The example use case is as follows:
The admin creates an organizational tree.
The admin creates users and adds users to the corresponding organizational
structure
The admin specifies the department admin.
The admin shares basic resources globally.
The admin creates a project and designates project admin.
The project admin creates a custom role.
The project admin adds members and attaches roles to the project
members.
Log in to the Cloud.
Assume the customer scenario as follows :
The company consists of two subsidiaries that are in Beijing and Shanghai,
and they need to create organizational trees respectively. The list of
organizational structure is as follows:
Organization
Sub-department
Company-BJ
Sales-BJ
Company-SH
Dev-SH
QA-SH
The list of department admin is as follows:
Department
Department Admin
Company-BJ
Tomas
Sales-BJ
Ben
Company-SH
Frank
Dev-SH
Tom
QA-SH
Bill
The user list is as follows:
Name
User Name
Password
Department
Tomas
Tomas
password
Company-BJ
Ben
Ben
password
Sales-BJ
Amy
Amy
password
Sales-BJ
Shelly
Shelly
password
Sales-BJ
Bill
Bill
password
QA-SH
Sam
Sam
password
QA-SH
Chil
Chil
password
QA-SH
Frank
Frank
password
Company-SH
John
John
password
Dev-SH
Jack
Jack
password
Dev-SH
Tom
Tom
password
Dev-SH
The project list is as follows:
Project
Project Member
Project Admin
Role of Project Member
DevProjectA-SH
Jack, Frank, John,and Tom
Jack
Normal project member
SalesProjectA-BJ
Tomas, Ben,Amy, and Shelly
Tomas
Normal project member
Procedure
The admin creates an organizational tree.
The admin creates the organizational tree on Private Cloud based on the organizational structure of the company.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > Organization. On the Organization page, click the plus sign to
the right of Organization. Then, the Create
Organization page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the organization.
Description: Optional. Enter a description for the
organization.
Type: Choose the type of the organization. You can add a
new team (by default) or add a subdepartment.
Note: To add
Subdepartment, you need to specify
Upper Department from the subdepartment or new
team that are already added.
Admin: Optional. Specify an appropriate user as the
admin.
Department Manager: Optional. Specify a department
manager for the new team to assist the admin to manage the department.
Note:
A department manager is in charge of the operational management of
the whole department, including project management, ticket approval,
bill checks, and key resource monitoring.
A user cannot be specified as the department manager if the user is
already attached to other roles.
A user cannot be attached to other roles if the user is specified as
the department manager.
Quota Setting: The quota settings can be configured
manually, and you can configure the quota settings for the following
resources:
Compute Resource: including memory, and the
number of VM instances, running VM instances, CPU, GPU devices, elastic baremetal instances, and VM scheduling
polices.
Storage Resource: including the quantity of data
volume, volume snapshot, available storage capacity, image, total image
size, backup data, and available backup capacity.
Network Resource: including the quantity of VXLAN
network, L3 network, security group, VIP, EIP, port forwarding, load
balancer, and listener.
Other: including scheduled job, scheduler,
resource alarm, event alarm, endpoint, and tag.
Figure 3. Create Organization
Take Table 1 for
reference, repeat the steps above to complete the creation of the
organization structure tree.
The admin creates users and adds users to the corresponding organizational
structure.
On the main menu of ZStack Cloud,
choose Operational Management > Tenant Management > Personnel and Permissions > User. On the User page, click
Create User. The Create
Organization page appears. Take Table 3 for
reference, follow the steps below to batch create users via template import,
and add the users to corresponding organizations.
Note: In this scenario,
the column of project can be left blank, while you can fill in the
information such as description, Email address, phone number, and code
as needed.
Note:
On the Create User page, select
Template Import as the method to create a user. The
detailed steps are as follows:
Download the template.
Click Download Template to
download a template in the .csv format.Figure 4. Template
Note: User name, name, and password are required parameters, and
the user name must be globally unique.
Fill in the configuration information of users according to the prescribed
format.
The user template includes a header and an example row, which
needs to be deleted or overwritten when editing the template.
On
the template, set the following parameters:
Name: Enter a name for the user.
User Name: Enter the user name as an
unique identifier for logging in to the Cloud.
Password: Set a user login password.
Description: Optional. Enter a
description for the user.
Phone Number: Optional. Enter a phone
number of the user.
Email Address: Optional. Enter an email
address of the user.
Identifier: Optional. Enter a user ID,
such as the job ID.
Organization: Optional. A user can be
added to one or multiple organizations.
Note:
The organization that you fill in has to be an
existing organization. Note that organizations must
be separated by /. For example:
Company/Dev.
If the organization path duplicates, attach the UUID
of a upper-department, such as
Company(f11444d42701483791370e9f8b9300b9)/Dev.
If a user is added to multiple organizations
simultaneously, separate these organizations by
&&, such as
Company/Dev&&Company/QA.
Project: Optional. A user can be added to
one or multiple projects.
Note:
The project that you fill in has to be an existing
project. When a single project is added, enter the
project name directly, such as
project-01.
If a user is added to multiple projects
simultaneously, separate these projects by
&&, such as
project-01&&project-02.
After finishing the configurations in the template, you can directly upload
the template to the Cloud by the browser. Confirm the template and click
OK. The Cloud automatically creates users
according to the uploaded template configuration file.Figure 5. Upload Template
The admin specifies the department admin.
Take Table 2 for
reference, repeat the steps below to add the department admin for each
department.
On the Organization page, click Actions > Change Department Admin, and specify a user as the department admin.
The admin shares basic resources globally.
To ensure a smooth project, the basic resources needs to be globally shared,
including disk offering, instance offering, images, and private
networks/VXLAN Pool.
Take the image as an example, on the Image page, choose
one or more images, click Actions > Set Sharing Mode, and choose Share globally as the
sharing mode.Figure 6. Share Resource Globally
Repeat the operations above to share other basic resources globally.
The admin creates a project and specifies the project admin.
On the Project page, click Create
Project. The Create Project page
appears.
On the displayed page, set the following parameters:
Name: Enter a name for the project.
Description: Optional. Enter a description for the
project.
Project Configuration: You can choose manual or project
template for the project configuration.
If you choose
Manual for the project configuration, set the
following parameters:
Quota Setting: Specify quota settings to
control the total resources in the project.
Compute Resource: including memory,
and the number of VM instances, running VM instances, CPU,
GPU devices, elastic baremetal instances,
and VM scheduling polices.
Storage Resource: including the
quantity of data volume, volume snapshot, available storage
capacity, image, total image size, backup data, and
available backup capacity. Notice that the Backup Service
Plus License is required for the quota settings of backup
data and available backup capacity.
Network Resource: including the
quantity of VXLAN network, L3 network, security group, VIP,
EIP, port forwarding, load balancer, and listener.
Other: including scheduled job,
scheduler, resource alarm, event alarm, endpoint, and
tag.
Figure 7. Quota Setting
If you choose Project Template for the
project configuration, set the following parameters:
Project Template: If you choose the project
template for the project configuration, you need to select an
existing project template, which is used to directly apply the quota
settings defined in that template for the project.
Figure 8. Project Template
Zone: Specify a zone to which the project belongs, and a
project can only belong to one zone.
Reclaim Policy: Default values:
Unlimited. You can also select Reclaim by
specifying time and Reclaim by specifying
cost.
Unlimited::
After you create a project,
resources within the project will be in the enabled state by
default.
Reclaim by specifying time:
When the expiration date for a project is less than 14 days, a
project member will receive a project expiration reminder that
the project is about to expire after logging in to the
Cloud.
After the project expired, resources within the project will be
reclaimed according to the specified reclaim policy.
To reclaim by specifying time, you need to set the following
parameters:
Deadline: Set a deadline for the
project.
Reclaim Policy:
Three reclaim policies are supported:
Disable Project Member Login: After the project is
expired, all project members are prohibited from
logging in to the project, and the resources (VM
instances and VPC vRouters) in the project are still
running normally.
Disable Project Member Login and Stop Project
Resource: After a project is expired, all project
members are prohibited from logging in to the
project, and all the resources (VM instances and VPC
vRouters) in the project are in the stopped
state.
Delete Project: A project is deleted after
expiration, and the project is in the Deleted
status. All project members are prohibited from
logging in to the project, and all the resources (VM
instances and VPC vRouters) in the project are in
the stopped state.
Note: After the VPC vRouter in the project is stopped,
the network services it provides will stop
correspondingly, and VM instances cannot access the
external network.
Reclaim by specifying cost：
A project is
expired when the project total spending reaches the maximum limit.
After the project is expired, the resources within the project will
be reclaimed according to the specified reclaim policy.
To
reclaim by specifying cost, you need to set the following
parameters:
Spending Limit: Set a spending limit
for the project.
Reclaim Policy: Three reclaim
policies are supported:
Disable Project Member Login: After the project is
expired, all project members are prohibited from
logging in to the project, and the resources (VM
instances and VPC vRouters) in the project are still
running normally.
Disable Project Member Login and Stop Project
Resource: After the project is expired, all project
members are prohibited from logging in to the
project, and all the resources (VM instances and VPC
vRouters) in the project are in the stopped
state.
Delete Project: A project is deleted after
expiration, and the project is in the Deleted
status. All project members are prohibited from
logging in to the project, and all the resources (VM
instances and VPC vRouters) in the project are in
the stopped state.
Note: After the VPC vRouter in the project is stopped,
the network services it provides will stop
correspondingly, and VM instances cannot access the
external network.
Access Control: Optional. You can specify whether to
allow or prohibit project members to or from logging in to the project within a
specified time period.
If not set, the time for project members to login in to
the project is unlimited. You can configure the access control by setting
the login allowed time and login prohibited time.
Login Allowed Time: You can set the time when
members in the project can log in to the project by day or week.
After setting, the project members can log in to the project only
during the login allowed time period.
Login Prohibited Time: You can set the time
when members in the project cannot log in to the project by day or
week. After setting, the project members cannot log in to the
project during the login prohibited time period.
Note:
If the time period you set is earlier than or includes the
current platform time, the access control policy takes effect in
the next time period.
If you apply both the reclaim policy and access control policy,
the reclaim policy has a higher priority.
Project Admin: Optional. Assign a corresponding user as
the project admin.
Member: Optional. Add relevant users into the project as
project members
Department: Optional. Load the project to the
department,and then the billing is made by departments.
Pricing List: Optional. Select the pricing list used by
the project. If not specified, the default pricing list is applied.
Security Group Constraint: By default, the security group
constraint is disabled. If you enable security group constraint, when a project
member creates a VM instance, the VM instance must have one or more security
groups attached.
Note:
Before you can enable security group constraint for the project,
make sure that the project security group quota is set to 1 or
higher.
If you enable the security group constraint for the project, a
default security group is created when the project is created.
You can use the Project Security Group Constraint setting in Global
Setting to make the setting take effect globally. By default, the
Project Security Group Constraint setting is disabled. If you enable
the setting, projects are enabled the security group constraint by
default when they are created.
Rule: Optional. If you enable the security group
constraint for the project, you can directly set the rules of security
group when you create the project, or set the rules later.
In this scenario, refer to Table 4, and
create DevProjectA-SH (ZONE-SH), SalesProjectA-BJ (ZONE-BJ) and specify
relevant project admin. The content other than the Project
Admin can be left blank currently.
The project admin creates a custom role.
By using Chrome or Firefox, the project admin can go to the Project Login
page via http://management_node_ip:5000/#/project. To log in to the
Cloud, the project admin must enter the corresponding user name and
password.
Figure 9. Tenant Login Page
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > Role. On the Role page, click Create
Role. The Create Role page appears.
Project admins of different projects can refer to the steps above to create
roles for the projects. Users can be granted regular project member
permissions as needed.
The project admin adds members and attaches roles to the project members.
On Project page, choose the project, and click to enter
its details page. Click Member > Add Project Member. You can refer to Table 4 to add
project members and attach corresponding roles for them.
Project admins of different projects can refer to the above steps to add
members and attach roles to the project members.
Log in to the Cloud.
The users who have joined projects and have roles attached can log in to the
Cloud to use resources on the platform, and also perform various actions. By
using Chrome or Firefox, the project members are allowed go to the Project
Login page via http://management_node_ip:5000/#/project. To log in to
the Cloud, the project members must enter the corresponding user name and
password.
After the project members log in to the Cloud, all the projects to which they
belong are displayed in the form of cards, then choose to enter project.
Figure 10. Choose Project
What to do next
The Quick Start Guide for Tenant Management is completed.
Platform Management
Custom Permissions: Network Admin
About this task
ZStack Cloud supports the API-level fine-grained permission
control, which allows you to custom permissions for a user and meets your needs in
different scenarios. This scenario takes an example of creating the role of network
admin to introduce you the steps to custom permissions for a user.
The example use case is as follows:
The admin creates a platform user named Jerry.
The admin customs a platform role as a network admin.
Attach the role of network admin to the platform user Jerry.
Assume the customer scenario as follows:
A company in Shanghai needs to create a role of network admin, who assists the admin
to jointly manage the network resources on the Cloud, and has all permissions
related to L2 network, L3 network, network services, and public network billings
.
Permissions
Remarks
Billing Management Operations
Provides billing-related features, which is
used for public network IP billing.
Backup Storage Operations
Provides backup storage features, which is
used to add the VPC vRouter image and create VPC
vRouters.
Cluster Operations
Provides cluster-related features, which can
be functional only after the L2 network is attached to the
cluster.
Image Operations
Provides image-related features, which is
used to add the VPC vRouter image and create VPC
vRouters.
Instance Offering Operations
Provides instance offering-related features,
which is used to create instance offerings and create VPC
vRouters.
L2 Network Operations
Provides L2 network-related features, such as
L2NoVlanNetwork, L2VlanNetwork, and VxlanNetwork.
L3 Network Operations
Provides L3 network-related features, such as
public network, flat network, and VPC network.
Network Service Operations
Provides network service-related features,
including security group, VIP, EIP, port forwarding, load
balancing, SNAT, DHCP, and IPsec Tunnel.
OSPF Operations
Provides OSPF dynamic routing-related
features, which are used for VPC vRouters.
VPC vRouter Operations
Provides features related to VPC vRouter and
VPC network.
VM Instance Operations
Provides VM instance-related features, which
are used to create VPC vRouters.
VPC Operations
Provides features related to VPC vRouter and
VPC network.
Zone Operations
Provides zone-related features. Network
resources have the zone attributes, so they can be used only
when they are attached to a specific zone or zones.
ZWatch Operations
Provides alarm-related features, which are
used for alarms related to vRouters, L3 network, and
VIPs.
Procedure
The admin creates a platform user named Jerry.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > User > Local User. On the Local User page, click Create
User. Then, the Create User page is displayed.
Note: If
you add a ZStack IAM server, you cannot create a local user. You can create SSO
users only.
On the Create User page, select
Custom as the method of creating a user, and on
the displayed page, set the following parameters:
Name: Enter a name for the user.
Description: Optional. Enter a description
for the user.
User Name: Enter a user name, which is the
unique identifier for logging in to the Cloud.
Password: Set the user login password.
Confirm Password: Enter the login password
again.
Immediate Department: Optional. Users can be
added directly to the corresponding department.
Phone Number: Optional. Enter user mobile
number.
Email Address: Optional. Enter user email
address.
Identifier: Optional. Enter the user ID, such
as the job ID.
Platform Role: Optional. You can specify one
or more platform roles for one user. You need to set the management
zone for the use after the platform role is specified.
Note:
After the platform role is attached to users, these
users can have permissions to manage corresponding
zones. The permissions of the platform role only take
effect in the zone under the control of the user.
After the platform role is attached to users, these
users need to log in to the Cloud via Project
Login.
Management Zone: Specify the zone
under the control of the platform role.
Note:
After a zone is specified to users, these users
can only manage the zones specified to them.
One platform role can manage a group of zones,
while one zone can be co-managed by multiple
platform roles.
Project: Optional. A user can be added to one
or more projects.
Note: After a user is bound to a project, this user
will have corresponding permissions of the project, and manage
corresponding data within the project.
Click the OK button to create a platform user named
Jerry.Figure 11. Create User
The admin customs a platform role as a network admin.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > Role. On the Role page, click Create
Role. The Create Role page appears.
The three steps to create a role are as follows:
Basic Info.
On the displayed page, set the
following parameters:
Name: Enter a name for the
role.
Description: Optional. Enter a
description for the Role.
Role Type: Choose the role
type.
Note: The role type of a network admin is
platform user.
Root Role: Set the root role. The
root role is used to limit the permission range of
custom roles, whose permissions are inherited from the
root role. Permissions of these custom roles are a
subcollection of those of the root role.
Figure 12. Configure Basic Info
UI permissions.
Select the module permissions and configure these
UI permissions according to the permission list for network
admin role above.
Figure 13. Configure UI Permissions
Preview.
Check the role to be created, and you are allowed to
modify the UI permissions as the figure shown as below:Figure 14. Preview
Attach the role of network admin to the platform user Jerry.
On the User page, choose the user Jerry, and click Actions > Modify Platform Role. On the Modify Platform Role page,
click OK button to attach the role of network admin
to the user named Jerry.
Figure 15. Attach the Role of Network Admin to User
After attaching the role of network admin to the user named Jerry, Jerry is
assigned permissions related to network management that support all
network-related operations, enabling him to assist the admin to jointly
manage the network resources on the Cloud.
Default Permissions: Monitor
About this task
A variety of system roles are preset on ZStack Cloud, which
makes the Cloud more convenient for users. This scenario takes the monitor role as
an example to introduce the system roles.
Assume the customer scenario as follows:
A company in Shanghai needs a monitor role, who is responsible for the real-time
monitoring of the large-screen on the Cloud.
The example use case is as follows:
The admin creates a platform user named Liz, and attaches the user to the
monitor role.
The user Liz (with the monitor role) logs in to the real-time monitor.
Procedure
The admin creates a platform user named Liz, and attaches the user to the
monitor role.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > User > Local User. On the Local User page, click Create
User. Then, the Create User page is displayed.
Note: If
you add a ZStack IAM server, you cannot create a local user. You can create SSO
users only.
On the Create User page, select
Custom as the adding method, and you can refer to
the following examples to enter the corresponding content:
Name: Enter a name for the user.
Description: Optional. Enter a description
for the user.
User Name: Enter a user name, which is the
unique identifier for logging in to the Cloud.
Password: Set the user login password.
Confirm Password: Enter the login password
again.
Immediate Department: Optional. Users can be
added directly to the corresponding department.
Phone Number: Optional. Enter the user mobile
number.
Email Address: Optional. Enter the user email
address.
Identifier: Optional. Enter the user ID, such
as the job ID.
Platform Role: Choose Monitor
Role, and the user is assigned corresponding monitor
permissions.
Note:
After the platform role is attached to users, these
users can have permissions to manage corresponding
zones. The permissions of the platform role only take
effect in the zone under the control of the user.
After the platform role is attached to users, these
users need to log in to the Cloud via Project
Login.
Management Zone: Specify the zone
under the control of the platform role.
Note:
After a zone is specified to users, these users
can only manage the zones specified to them.
One platform role can manage a group of zones,
while one zone can be co-managed by multiple
platform roles.
Project: Optional. A user can be added to one
or more projects.
Note: After a user is bound to a project, this user
will have corresponding permissions of the project, and manage
corresponding data within the project.
Figure 16. The admin Creates Platform User and Attaches the User to the
Monitor Role
The user Liz (with the monitor role) logs in to the real-time monitor.
By using Chrome or Firefox, the user named Liz goes to the Project Login page
via http://management_node_ip:5000/#/project. After Liz enters the
corresponding user name and password to log in to the Cloud, she goes to the
real-time monitor page directly.
Figure 17. Login to Real-time Monitor
Note: Pay attention to the following when using the monitor role:
he users with monitor role do not have a user homepage and
cannot modify their passwords by themselves. Only the
admin/platform admin/regular platform members can modify
passwords for them.
The default language and theme of the real-time monitor follow
the existing configuration of the Cloud, and only the
admin/platform admin/regular platform member are allowed to make
relevant modifications.
The real-time monitor keeps running after the user logs in, and
the user remains logged in after the web page is closed. If the
user need to log out, the use can visit the jump link
http://management node_ip:port/#/login.
Independent Zone Management
About this task
Independent zone management is one of the sub-features provided by Enterprise
Management module.
The example of use case is as follows:
The admin logs in and creates two users and binds the platform manager to
manage and control Shanghai and Beijing respectively.
Platform Manager-SH logs in to the Cloud, creates an organization of
Shanghai branch and corresponding projects.
Platform Manager-BJ logs in to the Cloud, creates an organization of Beijing
branch and corresponding projects.
Functional verification.
Assume an enterprise user has a branch office in Shanghai and Beijing respectively,
and the headquarters administrator (i.e.: admin) designates corresponding platform
managers respectively to realize independent management of the data centers in the
two places.
Procedure
The admin logs in and creates two users and binds the platform
administrator.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > User > Local User. On the Local User page, click Create
User. Then, the Create User page is displayed.
Note: If
you add a ZStack IAM server, you cannot create a local user. You can create SSO
users only.
On the displayed page, click Custom and set the
following parameters:
Name: Enter a name for the user.
Description: Optional. Enter a description
for the user.
User Name: Enter a user name, which is the
unique identifier for logging in to the Cloud.
Password: Set the user login password.
Confirm Password: Enter the login password
again.
Immediate Department: Optional. Users can be
added directly to the corresponding department.
Phone Number: Optional. Enter the user mobile
number.
Email Address: Optional. Enter the user email
address.
Identifier: Optional. Enter the user ID, such
as the job ID.
Platform Role: Select Platform Manager.
Note:
After the platform role is bound to users, these users
can act as the manager to manage the Cloud. The platform
role that has the zone attribute can manage data centers
of the assigned zones.
Notice that these users can log in to the Cloud via
Project Login.
Management Zone: Select
Specify and ZONE-SH for the platform role.
Note:
After a zone is specified to users, these users
can only manage the zones specified to them.
One platform role can manage a group of zones,
while one zone can be co-managed by multiple
platform roles.
Project: Optional. A user can be added to one
or more projects.
Note:
After a user is bound to a project, this user will have
corresponding permissions of the project, and manage
corresponding data within the project.
If a user is bound with multiple project roles in a
project, this user will have all corresponding
permissions owned by the bound roles.
Figure 18. Create User as Platform Manager
Create another user (Platform Manager-BJ) by following the steps above.
Platform Manager-SH logs in to the Cloud, creates an organization of Shanghai
branch and corresponding projects.
Platform Manager-SH logs in to the Cloud through Project Login with a Chrome
browser or FireFox browser:
http://management_node_ip:5000/#/project.
By creating users, Platform Manager-SH enters the personnels of the
Shanghai branch into the Cloud.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > User > Local User. On the Local User page, click Create
User. Then, the Create User page is displayed.
Note: If
you add a ZStack IAM server, you cannot create a local user. You can create SSO
users only.
On the displayed page, click Custom and set
the following parameters:
Name: Enter a name for the user.
Description: Optional. Enter a
description for the user.
User Name: Enter a user name, which
is the unique identifier for logging in to the Cloud.
Password: Set the user login
password.
Confirm Password: Enter the login
password again.
Immediate Department: Optional. Users
can be added directly to the corresponding department.
Phone Number: Optional. Enter user
mobile number.
Email Address: Optional. Enter user
email address.
Identifier: Optional. Enter the user
ID, such as the job ID.
Platform Role: Optional. You can
specify one or more platform roles for one user. You need to
set the management zone for the use after the platform role
is specified.
Note:
After the platform role is bound to users, these
users can act as the manager to manage the Cloud.
The platform role that has the zone attribute can
manage data centers of the assigned zones.
Notice that these users can log in to the Cloud
via Project Login.
Management Zone: Specify the
zone under the control of the platform role.
Note:
After a zone is specified to users, these
users can only manage the zones specified to
them.
One platform role can manage a group of zones,
while one zone can be co-managed by multiple
platform roles.
Project: Optional. A user can be
added to one or more projects.
Note:
After a user is bound to a project, this user
will have corresponding permissions of the
project, and manage corresponding data within the
project.
If a user is bound with multiple project roles
in a project, this user will have all
corresponding permissions owned by the bound
roles.
Note:
In this scenario, the Project and
Immediate Department are left
blank as they are not created yet.
ZStack Cloud allows you to create a
user by manual addition and template import.
Figure 19. Create User
Create an organization of the Shanghai branch.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Personnel and Permissions > Organization. On the Organization page, click the plus sign to
the right of Organization. Then, the Create
Organization page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the organization.
Description: Optional. Enter a description for the
organization.
Type: Choose the type of the organization. You can add a
new team (by default) or add a subdepartment.
Note: To add
Subdepartment, you need to specify
Upper Department from the subdepartment or new
team that are already added.
Admin: Optional. Specify an appropriate user as the
admin.
Department Manager: Optional. Specify a department
manager for the new team to assist the admin to manage the department.
Note:
A department manager is in charge of the operational management of
the whole department, including project management, ticket approval,
bill checks, and key resource monitoring.
A user cannot be specified as the department manager if the user is
already attached to other roles.
A user cannot be attached to other roles if the user is specified as
the department manager.
Quota Setting: The quota settings can be configured
manually, and you can configure the quota settings for the following
resources:
Compute Resource: including memory, and the
number of VM instances, running VM instances, CPU, GPU devices, elastic baremetal instances, and VM scheduling
polices.
Storage Resource: including the quantity of data
volume, volume snapshot, available storage capacity, image, total image
size, backup data, and available backup capacity.
Network Resource: including the quantity of VXLAN
network, L3 network, security group, VIP, EIP, port forwarding, load
balancer, and listener.
Other: including scheduled job, scheduler,
resource alarm, event alarm, endpoint, and tag.
Figure 20. Create Organization
On the Organization page, the organizational
structure of the Shanghai branch created by the Platform Manager-SH
is as follows:Figure 21. Organization of Shanghai Branch
Create a project.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Project Management > Project. On the Project page, click Create
Project. Then, the Create Project page is
displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the project.
Description: Optional. Enter a description for the
project.
Project Configuration: You can choose manual or project
template for the project configuration.
If you choose
Manual for the project configuration, set the
following parameters:
Quota Setting: Specify quota settings to
control the total resources in the project.
Compute Resource: including memory,
and the number of VM instances, running VM instances, CPU,
GPU devices, elastic baremetal instances,
and VM scheduling polices.
Storage Resource: including the
quantity of data volume, volume snapshot, available storage
capacity, image, total image size, backup data, and
available backup capacity. Notice that the Backup Service
Plus License is required for the quota settings of backup
data and available backup capacity.
Network Resource: including the
quantity of VXLAN network, L3 network, security group, VIP,
EIP, port forwarding, load balancer, and listener.
Other: including scheduled job,
scheduler, resource alarm, event alarm, endpoint, and
tag.
Figure 22. Quota Setting
If you choose Project Template for the
project configuration, set the following parameters:
Project Template: If you choose the project
template for the project configuration, you need to select an
existing project template, which is used to directly apply the quota
settings defined in that template for the project.
Figure 23. Project Template
Zone: Specify a zone to which the project belongs, and a
project can only belong to one zone.
Reclaim Policy: Default values:
Unlimited. You can also select Reclaim by
specifying time and Reclaim by specifying
cost.
Unlimited::
After you create a project,
resources within the project will be in the enabled state by
default.
Reclaim by specifying time:
When the expiration date for a project is less than 14 days, a
project member will receive a project expiration reminder that
the project is about to expire after logging in to the
Cloud.
After the project expired, resources within the project will be
reclaimed according to the specified reclaim policy.
To reclaim by specifying time, you need to set the following
parameters:
Deadline: Set a deadline for the
project.
Reclaim Policy:
Three reclaim policies are supported:
Disable Project Member Login: After the project is
expired, all project members are prohibited from
logging in to the project, and the resources (VM
instances and VPC vRouters) in the project are still
running normally.
Disable Project Member Login and Stop Project
Resource: After a project is expired, all project
members are prohibited from logging in to the
project, and all the resources (VM instances and VPC
vRouters) in the project are in the stopped
state.
Delete Project: A project is deleted after
expiration, and the project is in the Deleted
status. All project members are prohibited from
logging in to the project, and all the resources (VM
instances and VPC vRouters) in the project are in
the stopped state.
Note: After the VPC vRouter in the project is stopped,
the network services it provides will stop
correspondingly, and VM instances cannot access the
external network.
Reclaim by specifying cost：
A project is
expired when the project total spending reaches the maximum limit.
After the project is expired, the resources within the project will
be reclaimed according to the specified reclaim policy.
To
reclaim by specifying cost, you need to set the following
parameters:
Spending Limit: Set a spending limit
for the project.
Reclaim Policy: Three reclaim
policies are supported:
Disable Project Member Login: After the project is
expired, all project members are prohibited from
logging in to the project, and the resources (VM
instances and VPC vRouters) in the project are still
running normally.
Disable Project Member Login and Stop Project
Resource: After the project is expired, all project
members are prohibited from logging in to the
project, and all the resources (VM instances and VPC
vRouters) in the project are in the stopped
state.
Delete Project: A project is deleted after
expiration, and the project is in the Deleted
status. All project members are prohibited from
logging in to the project, and all the resources (VM
instances and VPC vRouters) in the project are in
the stopped state.
Note: After the VPC vRouter in the project is stopped,
the network services it provides will stop
correspondingly, and VM instances cannot access the
external network.
Access Control: Optional. You can specify whether to
allow or prohibit project members to or from logging in to the project within a
specified time period.
If not set, the time for project members to login in to
the project is unlimited. You can configure the access control by setting
the login allowed time and login prohibited time.
Login Allowed Time: You can set the time when
members in the project can log in to the project by day or week.
After setting, the project members can log in to the project only
during the login allowed time period.
Login Prohibited Time: You can set the time
when members in the project cannot log in to the project by day or
week. After setting, the project members cannot log in to the
project during the login prohibited time period.
Note:
If the time period you set is earlier than or includes the
current platform time, the access control policy takes effect in
the next time period.
If you apply both the reclaim policy and access control policy,
the reclaim policy has a higher priority.
Project Admin: Optional. Assign a corresponding user as
the project admin.
Member: Optional. Add relevant users into the project as
project members
Department: Optional. Load the project to the
department,and then the billing is made by departments.
Pricing List: Optional. Select the pricing list used by
the project. If not specified, the default pricing list is applied.
Security Group Constraint: By default, the security group
constraint is disabled. If you enable security group constraint, when a project
member creates a VM instance, the VM instance must have one or more security
groups attached.
Note:
Before you can enable security group constraint for the project,
make sure that the project security group quota is set to 1 or
higher.
If you enable the security group constraint for the project, a
default security group is created when the project is created.
You can use the Project Security Group Constraint setting in Global
Setting to make the setting take effect globally. By default, the
Project Security Group Constraint setting is disabled. If you enable
the setting, projects are enabled the security group constraint by
default when they are created.
Rule: Optional. If you enable the security group
constraint for the project, you can directly set the rules of security
group when you create the project, or set the rules later.
Figure 24. Create Project
The Project page displays the projects of
Shanghai branch created by Platform Manager-SH.Figure 25. Projects of Shanghai Branch
Platform Manager-BJ logs in to the Cloud, creates an organization of Beijing
branch and corresponding projects.
Functional verification.
After the independent zone scenarios are completed, you can verify from the
following steps.
Platform managers can manage and control the resources within the
zone.
For example, Platform Manager-SH can only manage and control resources
within the ZONE-SH. The resources in ZONE-BJ are not visible for
Platform Manager-SH.Figure 26. Platform Manager-SH Perspective
A project only belongs to one zone and can access to resources within
the zone.
For example, a project created by Platform Manager-SH only belongs to
ZONE-SH and can only access to resources within ZONE-SH.Figure 27. Platform Manager-SH Perspective
Project members can only access and use resources within the
project.
For example, project manager Jerry, project admin Tom,
and project member John of the project Dev-project-1-SH in
the ZONE-SH can only access and use resources within the project
Dev-project-1-SH.
The admin can inspect and manage all zones.
In this scenario, the admin can inspect and manage ZONE-SH and
ZONE-BJ.Figure 28. Admin Perspective
Project Management
Reclaim by Specifying Time
About this task
ZStack Cloud allows you to configure multiple reclaim policies
and actions. This scenario will be validated with the reclaim policy of reclaiming
by specifying time and reclaim actions of disabling project member login.
The detailed steps are as follows:
Platform Manager-SH sets reclaim policy as Reclaim by specifying
time and reclaim action as Disable Project Member
Login.
When the expiration date for a project is less than 14 days, project members
will receive a project expiration reminder that the project is about to
expire after logging in to the Cloud.
After the project is expired, project members are prohibited from logging in
to the project and the VM instances in the project are still running
normally.
Platform Manager-SH restores the expired project. Then, the project can be
normally logged in and the resources in the project are running
normally.
Assume that the project Dev-project-1-SH of Shanghai branch includes the
following members: Jerry (Project Admin), John (Project Manager), and Tom (Project
Member). In order to control project progress by time, Platform Manager-SH decides
to reclaim the project by specifying time.
Procedure
Platform Manager-SH sets reclaim policy as Reclaim by specifying
time and reclaim action as Disable Project Member
Login.
You can set the reclaim policy when creating a project or after a project is
created. In this scenario, set the reclaim policy of an existing
project.
Platform Manager-SH logs in to the Cloud through project login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Project Management > Project. On the Project page, locate
Dev-project-1-SH and enter its details page. On the details page
of Dev-project-1-SH, click the Edit icon of
Reclaim Policy to set reclaim policy as
Reclaim by specifying time and reclaim action as
Disable Project Member Login.
Figure 29. Modify Reclaim Policy
When the expiration date for a project is less than 14 days, Jerry (Project
Admin), John (Project Manager), and Tom (Project Member) will receive a project
expiration reminder that the project is about to expire after logging in to the
Cloud.
After the project Dev-project-1-SH is expired, Jerry (Project Admin),
John (Project Manager), and Tom (Project Member) are prohibited from logging in
to the project, and the VM instances in the project are still running
normally.
Figure 30. Expired Project
Note: After a project is expired, the VM instances in the project are still
running normally.
Platform Manager-SH restores the expired project. Then, the project can be
normally logged in and the resources in the project are running normally.
Platform Manager-SH restores the expired project.
Platform Manager-SH logs in to the Cloud through project login
(http://management_node_ip:5000/#/project). On the
Project page, select the expired
Dev-project-1-SH and click Actions > Restore Expired Project. Then the Restore Expired
Project page is displayed. On the displayed page,
modify the reclaim policy to restore the expired project.
Figure 31. Restore Expired Project
The project can be normally logged in and resources in the project are
running properly.
Jerry (Project Admin), John (Project Manager), and Tom (Project
Member) log in to the Cloud through project login, and
Dev-project-1-SH can be normally logged in.
Figure 32. Project Login Restored Normally
Note: After an expired project is restored, the resources in the project
are running properly.
Enable/Disable Security Group Constraint for Individual Project
About this task
ZStack Cloud allows you to set security group constraint for
an individual project. If you enable security group constraint, when a project
member creates a VM instance, the VM instance must have one or more security groups
attached. If you disable security group constraint, you can choose to attach or not
attach a security group according to your needs, and efficiently isolate VM
instances through security group. This chapter mainly validates two scenarios:
enable security group constraint for individual project and disable security group
constraint for individual project.
Scenario 1:
Assume that a company has created 10 VM instances (including VM-A) using
service network VPC-Network-1 to run its routine business, and configured
firewall to protect its service network. Due to surged business, the company needs
to create new VM instances using the same service network to run those increased
business. It is required that the newly created VM instances to be isolated from the
existing VM instances through a security group. The company set up a project named
as Project-A to be responsible for this. Project-A is composed of one
project manager and two project members.
Follow these steps to enable security group constraint for an individual project:
Admin enables Default Value of Project Security
Constraint in Global Setting.
Admin creates a project named as Project-A, add two project members
Jack and Rose, and associate them with the role of normal project
member.
Admin set the sharing mode of VPC-Network-1 to Project-A.
Project members Jack and Rose creates two VM instances respectively named as
VM-B and VM-C using VPC-Network-1 and associates
the default security group with the two VM instances.
Test whether VM-A, VM-B, and VM-C are isolated through
the security group.
Scenario 2:
Assume that a company sets up a project named as Project-B, which includes one
project manager named as Bob and two project members named as Tom and Jerry
respectively. The company assigns the project team to create 10 VM instances
(including VM-A1) using service network VPC-Network-2 to run important
business. The firewall is configured to secure the service network and the VM
instances are also associated with a default security group to achieve refined
network security control. Due to business increase, Project-B is asked to use
the same service network to create two VM instances to run the increased businesses
without associating with any security group to isolate themselves from the existing
VM instances.
Follow these steps to disable security group constraint for an individual project:
Admin disables Security Group Constraint for
Project-B.
Project member Tom and Jerry create two VM instances respectively named as
VM-D and VM-F using VPC-Network-2 and without
associating security groups.
Test whether VM-D, VM-F, and VM-A1 are isolated in
network.
Enable Security Group Constraint for an Individual Project
Admin enables Default Value of Project Security
Constraint in Global Setting.
On the main menu of ZStack Cloud, choose Settings > Platform Setting > Global Setting > Basic > Operational Management > Tenant Management, set Default Value of Project Security
Constraint to enabled.
Admin creates a project named as Project-A, add two project
members Jack and Rose, and associate them with the role of normal
project member.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Project Management > Project. On the Project page, click
Create Project. Then, the
Create Project page is displayed.
On the displayed page, set the following
parameters:
Name: Enter a name for the
project.
Description: Optional. Enter a
description for the project.
Project Configuration: You can choose
manual or project template for the project configuration. In
this scenario, select Manual.
Quota Setting: Specify quota settings
to control the total resources in the project.
Compute Resource: including
memory, and the quantity of VM instance, running VM,
CPU, elastic baremetal instance,
GPU device, and VM scheduling policy.
Storage Resource: including
the quantity of data volume, volume snapshot,
available storage capacity, image, total image size,
backup data, and available backup capacity. Notice
that the Backup Service Plus License is required for
the quota settings of backup data and available
backup capacity.
Network Resource: including
the quantity of VXLAN network, L3 network, security
group, VIP, EIP, port forwarding, load balancer, and
listener.
Other: including scheduled
job, scheduler, resource alarm, event alarm,
endpoint, and tag.
Zone: Specify a zone to which the
project belongs, and a project can only belong to one
zone.
Reclaim Policy: Default values:
Unlimited. You can also select
Reclaim by specifying time and
Reclaim by specifying cost. In
this scenario, select Unlimited.
Access Control: Optional. Specify
whether to allow or prohibit project members to or from
logging in to the project within a specified time period. In
this scenario, disable Access Control.
Project Admin: Optional. Assign a
corresponding user as the project admin.
Department: Optional. Load the
project to the department,and then the billing is made by
departments.
Pricing List: Optional. Select the
pricing list used by the project. If not specified, the
default pricing list is applied.
Security Group Constraint: By
default, the security group constraint is disabled. If you
enable security group constraint, when a project member
creates a VM instance, the VM instance must have one or more
security groups attached.
Note:
Before you can enable security group constraint
for the project, make sure that the project
security group quota is set to 1 or higher.
If you enable the security group constraint for
the project, a default security group is created
when the project is created.
You can use the Project Security Group
Constraint setting in Global Setting to make the
setting take effect globally. By default, the
Project Security Group Constraint setting is
disabled. If you enable the setting, projects are
enabled the security group constraint by default
when they are created.
Rule: Optional. If you enable
the security group constraint for the project, you
can directly set the rules of security group when
you create the project, or set the rules later.
Figure 33. Create Project
Locate Project-A on the Project page and
click Actions > Add Project Member. On the Add User dialogue box,
add Jack and Rose to the project and associate them with the role of
project member.
Figure 34. Add Project Member
Admin set the sharing mode of VPC-Network-1 to
Project-A.
On the main menu of ZStack Cloud, choose Resource Center > Network Resource > L3 Network Resources > VPC Network. On the VPC Network page, locate
VPC-Network-1 and click Actions > Set Sharing Mode. On the Set Sharing Mode page,
share VPC-Network-1 to Project-A.
Figure 35. Set Sharing Mode of VPC-Network-1 to Specified
Project
Project members Jack and Rose creates two VM instances respectively
named as VM-B and VM-C using VPC-Network-1 and
associates the default security group with the two VM instances.
Jack and Rose log in to the Cloud respectively through Project Login.
On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, click
Create VM Instance. Then, the
Create VM Instance page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the VM
instance.
Quantity: Enter the number of VM
instances to be created.
Tag: Optional. Bind one or more tags
to the VM instance as needed.
Instance Offering: Select an existing
instance offering.
Image: Select an existing image.
Root Disk Offering: Select an
existing disk offering for the root volume of the VM
instance.
Data Volume: Optional. Choose whether
to create data volumes and attach the volumes to the VM
instance.
Network Configurations: Configure the
network resources and network services for the VM instance.
You can add multiple networks as needed.
Network: Select an L3 network
for the VM instance. Supported network types: VPC
network, public network, and flat network. In this
scenario, select VPC-Network-1 shared by the
admin.
Make Default: Set one of the
networks as the default network of the VM
instance.
Enable SR-IOV: Optional.
Choose whether to use SR-IOV to generate a VF NIC
and pass it through to the VM instance. By default,
SR-IOV is disabled. You can enable it if you have
qualified hardware resources.
Assign IP: Optional. Choose
whether to assign an IP address to the VM NIC. By
default, this option is not selected and the Cloud
automatically assigns an IP address to the VM
instance.
MAC Address: Optional. Choose
whether to customize a MAC address for the VM
instance. By default, this option is not selected
and the Cloud automatically assigns a MAC address to
the VM instance.
Security Group: Associate the
default security group with the VM instance.
EIP: Optional. Associate an
existing elastic IP address (EIP) with the VM
instance.
User Data: Optional. Inject
user-defined parameters or scripts to customize
configurations for the VM instance or to accomplish specific
tasks.
Click OK to create a VM instance.
Test whether VM-A, VM-B, and VM-C are isolated
through the security group.
Log in to the system of VM-B and VM-C respectively and
use ping command to test the network connection with
VM-A.
Disable Security Group Constraint for an Individual Project
Admin disables Security Group Constraint for
Project-B.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Project Management > Project. On the Project page, locate
Project-B and enter its details page. On the details
page, click the Edit icon to the right of
Security Group Constraint. On the
Set Security Constraint page, disable
security group constraint.
Project member Tom and Jerry create two VM instances respectively named
as VM-D and VM-F using VPC-Network-2 and without
associating security groups.
Tom and Jerry log in to the Cloud respectively through Project Login.
On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, click
Create VM Instance. Then, the
Create VM Instance page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the VM
instance.
Quantity: Enter the number of VM
instances to be created.
Tag: Optional. Bind one or more tags
to the VM instance as needed.
Instance Offering: Select an existing
instance offering.
Image: Select an existing image.
Root Disk Offering: Select an
existing disk offering for the root volume of the VM
instance.
Data Volume: Optional. Choose whether
to create data volumes and attach the volumes to the VM
instance.
Network Configurations: Configure the
network resources and network services for the VM instance.
You can add multiple networks as needed.
Network: Select an L3 network
for the VM instance. Supported network types: VPC
network, public network, and flat network. In this
scenario, select VPC-Network-2 shared by the
admin.
Make Default: Set one of the
networks as the default network of the VM
instance.
Enable SR-IOV: Optional.
Choose whether to use SR-IOV to generate a VF NIC
and pass it through to the VM instance. By default,
SR-IOV is disabled. You can enable it if you have
qualified hardware resources.
Assign IP: Optional. Choose
whether to assign an IP address to the VM NIC. By
default, this option is not selected and the Cloud
automatically assigns an IP address to the VM
instance.
MAC Address: Optional. Choose
whether to customize a MAC address for the VM
instance. By default, this option is not selected
and the Cloud automatically assigns a MAC address to
the VM instance.
Security Group: Associate the
default security group with the VM instance.
EIP: Optional. Associate an
existing elastic IP address (EIP) with the VM
instance.
User Data: Optional. Inject
user-defined parameters or scripts to customize
configurations for the VM instance or to accomplish specific
tasks.
Click OK to create a VM instance.
Test whether VM-D, VM-F, and VM-A1 are isolated in
network.
Log in to the system of VM-D and VM-F, and use
ping command to test the network connection with
VM-A1.
To better provide basic
resources efficiently for each project, project members (project admins,
project managers, or regular project members) can submit tickets to
obtain cloud resources. Tickets are reviewed and approved according to
custom ticket review processes of each project. Finally, the admin,
project admins, department managers, and the customized approvers
approve the tickets. Currently, five types of ticket are available,
including applying for VM instances, deleting VM instances, modifying VM
configurations, modifying project cycles, and modifying project
quotas.
ZStack Cloud provides you the following two
types of ticket process:
Default process: The project member submits a ticket to the admin, and then the
admin approves the ticket. This process applies to the following scenarios:
The tickets that are not configured with a ticket process.
The tickets which apply for modifications on the project cycle.
The tickets which apply for modifications on the project quota.
If the custom ticket process is deleted, the tickets will be resubmitted
automatically via the default ticket process.
Custom process: The project member submits a ticket. The project member makes
process settings via process management. Finally, the admin or project admin
approves the ticket. This process applies to the following scenarios:
The tickets created to apply for VM instances, delete VM instances, and
change VM configurations will be prioritized to be submitted via the
configured, custom ticket process.
If you modify the valid ticket process, the tickets will be
automatically resubmitted via this modified, custom ticket process.
If you modify the invalid ticket process, you need to resubmit the
tickets manually by using this modified, custom ticket process.
Preparation
To use the ticket management feature, you need to meet the following requirements:
The admin installs the latest version of ZStack Cloud
and deploys necessary resources for VM creation.
The admin purchases the Plus License of Tenant Management, in addition to
the Base License.
The admin/platform member creates users, organization, and projects in
advance.
Default Process
Default process: The project member submits a ticket to the admin, and then the admin
approves the ticket.
The following two scenarios describe how default process works:
The tickets that apply for modifications on the project cycle:
This scenario
introduces regular operations involved in ticket approval process, including
recall, reject, re-submit, approve, and delete a ticket. For more
information, see Tickets that Apply for Modifications on Project Cycle.
The tickets that apply for modifications on the project quota:
This scenario
takes a ticket that applies for modification on project quota as an example
to introduce how project admin submits a ticket. For more information, see
Tickets that Apply for Modifications on Project Quota.
Tickets that Apply for Modifications on Project Cycle
About this task
In this scenario, we will take a ticket that applies for a modification on project
cycle as an example to introduce regular operations involved in this process,
including recall, reject, re-submit, approve, and delete a ticket.
The detailed steps are as follows:
Frank (Project Member) submits a ticket.
Frank (Project Member) recalls a ticket.
Admin rejects a ticket.
Frank (Project Member) re-submit a ticket.
Admin approves a ticket and modifies the project cycle.
Frank (Project Member) deletes a closed ticket.
Assume that a company sets up a project named as Dev-Project-A, which is
composed of one project admin (Jack), one project manager (Tom), and two project
members (Frank and John). As the project is about to expire due to the reclaim
policy, Frank will apply for a modification on the project cycle by submitting a
ticket.
Procedure
Frank (Project Member) submits a ticket.
Frank (Project Member) logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
Frank ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Tickets. On the My Tickets page, click
Create Ticket. Then, the Select Ticket
Type dialogue box is displayed.
On the displayed Select Ticket Type dialogue box, select
Modify Project Cycle for ticket type, and click
OK. Then, the Create Ticket: Modify
Project Cycle page is displayed.
On the displayed page, set the following parameters:
Ticket Name: Enter a name for the
ticket.
Remark: Optional. Enter a remark for the
ticket.
Applicant: By default, the applicant of the
ticket is displayed.
Apply for Project: By default, the project of
the applicant is displayed.
Application Contents: Configure the
application contents of the ticket.
Reclaim Policy: By default, the
Specify Recycle Time is displayed.
Current DeadlineBy default, the
specified deadline of the project is displayed.
Apply for Deadline: Specify a new
deadline of the project.
Figure 40. Create Ticket
Note: Currently, only projects that reclaimed by specifying time support
submit a ticket that apply for modifications on project cycle. If
projects are specified with other reclaim policies, then you cannot
submit a ticket that apply for modifications on project cycle.
Frank (Project Member) recalls a ticket.
Frank finds out that there is already a ticket applying for modification on
project cycle, so he decides to recall his ticket.
On the My Tickets page, locate the ticket that you want
to recall and click Recall. Then, the
Recall Ticket dialogue box appears. Enter a remark
on the dialogue box and click OK to recall the
ticket.Figure 41. Recall Ticket
After a ticket is recalled, it will be in the Recalled state and
displayed on the Closed tab.
Admin rejects a ticket.
The ticket submitted by Frank will be sent to admin, and the recalled ticket
will not be displayed. The admin logs in to the Cloud. On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Approval. On the My Approval page, the ticket
submitted by Frank is displayed on the Pending tab.Figure 42. Admin-My Approval
Admin decides to reject the ticket as the new project cycle is too long. On
the My Approval page, select the ticket and click
Reject.Figure 43. Admin-Reject Ticket
After a ticket is rejected, you can view the rejected ticket on
Resolved tab.
Frank (Project Member) re-submit a ticket.
The rejected ticket of is displayed on the Closed tab of
My Tickets page.Figure 44. Rejected Ticket
Click the name of the ticket and enter its details page. On the details page
of the ticket, you can view the process record and remarks of the ticket.
Figure 45. Ticket Details Page
Now, Frank needs to modify the ticket based on the remarks and re-submits the
ticket. Select the rejected ticket and click
Resubmit. On the Resubmit: Modify Project
Cycle page, modify the application contents based on the
remarks and click OK. After a ticket is re-submitted,
it will be sent to admin and displayed on the Submitted
tab.
Admin approves a ticket and modifies the project cycle.
Admin receives the ticket from Frank and decides to approve the ticket and
modify the project cycle. On the Pending tab of the
My Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, click OK.Figure 46. Approve Ticket
After a ticket is approved by admin, the modification on project cycle takes
effect immediately.
After the process is over, the approver can view logs on the details page of
the ticket. If a ticket fails to be executed, you can troubleshoot the
exception according to the log.Figure 47. View Logs
Frank (Project Member) deletes a closed ticket.
After the closed ticket is deleted by an applicant, it will be displayed on
the Archived tab from the admin perspective.
On the Closed tab of My Tickets
page, select a ticket and click Delete. On the
Delete Ticket dialogue box, click
OK.Figure 48. Delete Closed Ticket
From the admin perspective, on the Archived tab of the
My Approval page, you can view the process record
and the detail information of the ticket.Figure 49. Admin-Archived Ticket
Tickets that Apply for Modifications on Project Quota
About this task
In this scenario, we will take a ticket that applies for a modification on project
quota as an example to introduce how project admin submits a ticket. The following
table lists the quotas that you can modify.
Quota Type
Quota Item
Compute Resource
VM Instances
Running VM Instances
CPUs
Memory
GPU Devices
VM Scheduling Policies
Storage Resource
Volume Snapshots
Data Volumes
Available Storage Capacity
Images
All Image Capacities
Backups (Backup Service Module
required)
Available Backup Capacity (Backup Service
Module required)
Network Resource
VXLAN Networks
L3 Networks
Security Groups
VIPs
EIPs
Port Forwardings
Load Balancers
Listeners
Other
Scheduled Jobs
Schedulers
Resource Alarm
Event Alarm
Endpoint
Tag
The detailed steps are as follows:
Jack (Project Admin) submits a ticket.
Admin approves the ticket and modifies the project quota.
Assume that a company sets up a project named as Dev-Project-A, which is
composed of one project admin (Jack), one project manager (Tom), and two project
members (Frank and John). Due to insufficient project quotas, Jack applies for a
modification on the project quotas by submitting a ticket.
Procedure
Jack (Project Admin) submits a ticket.
Jack (Project Admin) logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Tickets Approval > My Tickets. On the My Tickets page, click
Create Ticket. Then, the Select Ticket
Type dialogue box is displayed.
On the displayed Select Ticket Type dialogue box, select
Modify Project Quota for ticket type, and click
OK. Then, the Create Ticket: Modify
Project Quota page is displayed.
On the displayed page, set the following parameters:
Ticket Name: Enter a name for the
ticket.
Remark: Optional. Enter a remark for the
ticket.
Applicant: By default, the applicant of the
ticket is displayed.
Apply for Project: By default, the project of
the applicant is displayed.
Apply for Configuration: Select the
corresponding quota items that you want to modify. For more
information, see Table 1。
Quota Type: Select a quota type.
Valid values: Compute Resource, Storage Resource, Network
Resource, and Other.
Current Quota:By default, the current
quota configuration is displayed.
Apply for Quota: Enter a quota that
is larger than the current quota.
Figure 50. Create Project
Admin approves the ticket and modifies the project quota.
Admin receives the ticket from Jack and decides to approve the ticket and
modify the project quota. On the Pending tab of the
My Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, click OK.Figure 51. Approve Ticket
After a ticket is approved by admin, the modification on project quota takes
effect immediately.
After the process is over, the approver can view logs on the details page of
the ticket. If a ticket fails to be executed, you can troubleshoot the
exception according to the log.Figure 52. View Logs
Custom Process
Custom process: The project member submits a ticket. The project member makes process
settings via process management. Finally, admin or project admin approves the
ticket.
The following three scenarios describe how custom process works:
The tickets that apply for deleting VM instances
In this scenario, we will
introduce the custom process by submitting a ticket that applies for
deleting VM instances. For more information, see Tickets that Apply for Deleting VM Instances.
The tickets that apply for VM instances
In this scenario, by submitting a
ticket that applies for VM instances, we will introduce the basic operation
introduction involved in custom process, such as modifying ticket flow and
deleting ticket process. For more information, see Tickets that Apply for VM Instances.
Tickets that Apply for Deleting VM Instances
About this task
In this scenario, we will introduce the custom process by submitting a ticket that
applies for deleting VM instances.
Note:
To use a ticket to delete a VM instance, we recommend that the admin disables
the relevant permission of project members, including Delete and
Recover.Figure 53. Modify UI Permissions
You can disable the Delete VM Instance permission by the following
methods:
For roles to be created, you can edit the permission on the
UI Permission section of the
Create Role page.
For existing roles: You can edit the permissions on the UI
Permission and API Permission
tab of the details page of a role. Or you can locate a role and
click Actions > Modify UI Permission.
The detailed steps are as follows:
Admin creates a ticket process.
John (Project Member) submits a ticket.
Frank (Level 1 Approval) approves the ticket.
Jack (Project Admin) approves the ticket.
Admin approves the ticket and deletes VM instances.
Assume that a company sets up a project named as Dev-Project-A, which is
composed of one project admin (Jack), one project manager (Tom), and two project
members (Frank and John). As project members do not have the permission to delete VM
instances, they need to submit a ticket that applies for deleting VM instances.
Procedure
Admin creates a ticket process.
Admin logs in to the Cloud
(http://management_node_ip:5000/#/login). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > Process Management. On the Process Management page, click
Create Ticket Process. Then, the Create
Ticket Process page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the ticket
process.
Description: Optional. Enter a description
for the ticket process.
Project: Select a project for the ticket
process.
Ticket Type: Select one or more ticket types
for the ticket process. In this scenario, select Delete
VM Instance.
Process Setting: Display the details of the
ticket process.
The initial process setting interface includes two
basic steps: Submit Ticket and
Execution Flow. You can select admin,
project admin, and department manager as the approver of the
execution flow.
Execution Flow: Select an
approver. Valid values: admin, project admin, and
department manager.
Note:
when admin is selected as the approver of the
execution flow, you need to add flow in the
process setting. When project admin or department
manager is selected, you can skip the flow
addition in the process setting.
For tickets that apply for VM instances, admin
can configure advanced settings by clicking
Advanced Deployment, while
project admin cannot configure advanced
settings.
You can add a flow by click the plus sign in the
process setting. Set the following parameters:
Flow Name: Enter a name for the
added flow.
Approver: Select an approver for
the ticket. You can select an approver from the
specified project.
Note: You can delete a flow by click the delete sign to the
right of the Flow Name.
In this scenario, the process flow goes from John (Project Member), to Frank
(Level 1 Approval), to Jack (Project Admin Approval), and finally to admin
(Execution Flow).
Figure 54. Create Ticket Process
John (Project Member) submits a ticket.
John wants to delete two VM instances. Since he does not have the Delete VM
Instance permission, John decides to submit a ticket that applies for
deleting VM instances.
John logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Tickets. On the My Tickets page, click
Create Ticket. Then, the Select Ticket
Type dialogue box is displayed.
On the displayed Select Ticket Type dialogue box, select
Delete VM Instance for ticket type, and click
OK. Then, the Create Ticket: Delete VM
Instance page is displayed.
On the displayed page, set the following parameters:
Ticket Name: Enter a name for the
ticket.
Remark: Optional. Enter a remark for the
ticket.
Applicant: By default, the applicant of the
ticket is displayed.
Apply for Project: By default, the project of
the applicant is displayed.
VM Instance: Select one or more VM instances
that you want to delete.
Figure 55. Create Ticket
The created ticket that applies for deleting VM instances will be sent to
Frank (Level 1 Approval) according to the custom process.Figure 56. Created Ticket
Frank (Level 1 Approval) approves the ticket.
Frank logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Approval. On the Pending tab of the My
Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, enter a remark and click
OK.Figure 57. Frank Approves Ticket After a ticket is approved, it will be displayed on the
Resolved tab and sent to next process.
Jack (Project Admin) approves the ticket.
The ticket approval method is the same as that of Level 1 Approval. Jack logs
in to the Cloud through Project Login. On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Approval. On the Pending tab of the My
Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, enter a remark and click
OK.
Admin approves the ticket and deletes VM instances.
Admin logs in to the Cloud through Account Login
(http://management_node_ip:5000/). On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Approval. On the Pending tab of the My
Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, enter a remark and click
OK.Figure 58. Approve Ticket
After admin approves the ticket, the application for deleting VM instances
takes effect immediately.
After the process is over, the approver can view logs on the details page of
the ticket. If a ticket fails to be executed, you can troubleshoot the
exception according to the log.Figure 59. View Logs
Note:
Deleting a VM instance adopts a Delay Instance Deletion Policy, the
deleted VM instance are listed on the Recycle
Bin tab and are in Deleted state. You can
recover a deleted VM instance before the retention period
expires.
If you want to completely delete a VM instance, you can manually
expunge a VM instance or set Instance Deletion
Policy in Global Setting by admin.
Tickets that Apply for VM Instances
About this task
In this scenario, by submitting a ticket that applies for VM instances, we will
introduce the basic operation introduction involved in custom process, such as
modifying ticket flow and deleting ticket process.
Note:
To use a ticket that applies for a VM instance, we recommend that the admin
disables the Create VM Instance permission of project members.Figure 60. Modify UI Permissions
You can disable the Create VM Instance permission by the following
methods:
For roles to be created, you can edit the permission on the
UI Permission section of the
Create Role page.
For existing roles: You can edit the permissions on the UI
Permission and API Permission
tab of the details page of a role. Or you can locate a role and
click Actions > Modify UI Permission.
The detailed steps are as follows:
Admin creates a ticket process.
John (Project Member) submits a ticket.
Frank (Level 1 Approval) approves the ticket.
Ticket process becomes invalid.
Admin modifies the ticket flow.
John (Project Member) re-submits the ticket.
Finish the ticket approval process.
Admin deletes a ticket process.
Assume that a company sets up a project named as Dev-Project-A, which is
composed of one project admin (Jack), one project manager (Tom), and two project
members (Frank and John). As project members do not have the permission to create VM
instances, they need to submit a ticket that applies for VM instances.
Procedure
Admin creates a ticket process.
Admin logs in to the Cloud
(http://management_node_ip:5000/#/login). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > Process Management. On the Process Management page, click
Create Ticket Process. Then, the Create
Ticket Process page is displayed.
On the displayed page, set the following parameters:
Name: Enter a name for the ticket
process.
Description: Optional. Enter a description
for the ticket process.
Project: Select a project for the ticket
process.
Ticket Type: Select one or more ticket types
for the ticket process. In this scenario, select Apply
for VM Instance.
Process Setting: Display the details of the
ticket process.
The initial process setting interface includes two
basic steps: Submit Ticket and
Execution Flow. You can select admin,
project admin, and department manager as the approver of the
execution flow.
Execution Flow: Select an
approver. Valid values: admin, project admin, and
department manager.
Note:
when admin is selected as the approver of the
execution flow, you need to add flow in the
process setting. When project admin or department
manager is selected, you can skip the flow
addition in the process setting.
For tickets that apply for VM instances, admin
can configure advanced settings by clicking
Advanced Deployment, while
project admin cannot configure advanced
settings.
You can add a flow by click the plus sign in the
process setting. Set the following parameters:
Flow Name: Enter a name for the
added flow.
Approver: Select an approver for
the ticket. You can select an approver from the
specified project.
Note: You can delete a flow by click the delete sign to the
right of the Flow Name.
In this scenario, the process flow goes from John (Project Member), to Frank
(Level 1 Approval), to Jack (Project Admin Approval), and finally to admin
(Execution Flow).
Figure 61. Create Ticket Process
John (Project Member) submits a ticket.
John needs a VM instance for work. Since he does not have the Create VM
Instance permission, John decides to submit a ticket that applies for a VM
instance.
John logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Tickets. On the My Tickets page, click
Create Ticket. Then, the Select Ticket
Type dialogue box is displayed.
On the displayed Select Ticket Type dialogue box, set
the following parameters:
Ticket Type: Select Apply for VM
Instance.
Hypervisor: You can select to apply for
KVM/ESX VM instances. In this scenario, select
KVM.
Click OK. Then, the Create Ticket:
Apply for VM Instance page is displayed.
On the displayed page, set the following parameters:
Ticket Information:
Ticket Name: Enter a name for the
ticket.
Remark: Optional. Enter a remark for
the ticket.
Applicant: By default, the applicant
of the ticket is displayed.
Apply for Project: By default, the
project of the applicant is displayed.
Basic Configuration:
Name: Enter a name for the VM
instance.
Description: Optional. Enter a
description for the VM instance.
Quantity: Enter the number of VM
instances that you apply for.
Instance Offering: Select an existing
instance offering.
Image: Select an existing image.
Data Volume: Optional. Choose whether
to create data volumes and attach the volumes to the VM
instance.
Disk Offering: Select an
existing disk offering for the data volume of the VM
instance.
Quantity: Enter the number of
data volumes created from the selected data disk
offering that you want to attach to the VM
instance.
Enable
VirtioSCSI: Optional. Choose whether
to use VirtioSCSI bus to create a SCSI data
volume.
Advanced:
Affinity Group: Optional.
Select an affinity group for the VM instance.
USB Redirection: Optional.
Redirect a USB device on a VDI client to a VM
instance.
Resource Configurations:
Network Configuration: Select an L3
network used by the VM instance and complete the network
configurations.
Network: Select an L3 network
used by the VM instance. Supported network types:
public network, flat network, and VPC network.
Make Default: If you add
multiple networks, set one of the networks as the
default network.
Assign IP: Optional. Choose
whether to assign an IP address to the VM NIC.
MAC Address: Optional. Choose
whether to configure a MAC address for the VM
instance.
Security Group: Optional.
Associate a security group with the VM
instance.
GPU Device: Optional. Attach a GPU
device to the VM instance by specifying a GPU specification
or device.
System Configuration:
SSH Public
Key: After an SSH key is injected to your VM
instance, you can SSH in to the VM instance without entering
a password when the VM instance is running.
User Data:
Optional. Inject user-defined parameters or scripts to
customize configurations for the VM instance or to
accomplish specific tasks.
Console
Password: Set a console password for the VM
instance. The password must be 6 to 8 characters in
length.
Console
Mode: Set the console mode. Options: VNC,
SPICE, and VNC+SPICE. Default: VNC.
Figure 62. Create Ticket
The created ticket that applies for a VM instance will be sent to Frank
(Level 1 Approval) according to the custom process.Figure 63. Created Ticket
Frank (Level 1 Approval) approves a ticket.
Frank logs in to the Cloud through Project Login
(http://management_node_ip:5000/#/project). On the main menu of
ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Approval. On the Pending tab of the My
Approval page, select the ticket and click
Approve. On the Approve
Ticket dialogue box, enter a remark and click
OK.Figure 64. Frank Approves Ticket After a ticket is approved, it will be displayed on the
Resolved tab and sent to next process.
Ticket process becomes invalid.
When an approver of the ticket process is deleted or removed from the
project, the ticket process becomes invalid. All tickets within the ticket
process that have not finished will be rejected. Assume that Frank left the
Dev-Project-A project and Jack (Project Admin) removed Frank from
the project. Now, the ticket process becomes invalid, and the ticket
submitted by John is rejected. From the admin perspective, the ticket
process is in Invalid status.
Figure 65. Invalid Ticket Process At this point, the Cloud will report an error if John re-submit a
ticket. John needs to wait for admin to modify the ticket flow before
re-submitting a ticket.
Admin modifies the ticket flow.
Admin logs in to the Cloud. On the main menu of the ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > Process Management. On the Process Management page, select
the invalid ticket process and enter its details page. You can view the
invalid process in the current ticket. Then, click Actions > Modify Ticket Flow.Figure 66. Modify Ticket Flow On the Modify Ticket Flow page, you can delete or
add a flow in the process setting. In this scenario, delete Level 1 Approval
and click OK to save the modification. At this point,
the ticket process is in Valid status from the admin perspective.
Note:
If the ticket process is Valid before the modification,
after modifying the ticket flow, all tickets that adopt this
process are started according to the new ticket process.
If the ticket process is Invalid before the modification,
after modifying the ticket flow, the rejected tickets need to be
re-submitted manually.
John (Project Member) re-submits the ticket.
John logs in to the Cloud. On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > Ticket Approval > My Tickets. On the Closed tab of the My
Tickets page, select the rejected ticket and click
Resubmit.
Finish the ticket approval process.
After a ticket is re-submitted, it will be displayed on the
Submitted tab of the My
Tickets page. The re-submitted ticket follows the new ticket
process and goes from John (Project Member), to Jack (Project Admin), and
finally to admin.
After admin approves the ticket, the applied VM instance is deployed to the
project automatically.
After the process is over, the approver can view logs on the details page of
the ticket. If a ticket fails to be executed, you can troubleshoot the
exception according to the log.Figure 67. View Logs
So far, the whole custom process is over. John can freely use the applied VM
instance.
Admin deletes a ticket process.
In addition, when admin deletes a ticket process before the ticket is
finished in the approval process. The unfinished ticket will use the default
process.
Assume that John submits a ticket according to the ticket process. But,
before the ticket is finished in the approval process, admin deletes the
ticket process of John's project. The ticket submitted by John will
automatically use the default process.Figure 68. Default Process
3rd-Party Authentication
Preparation
To use the 3rd-party authentication feature, you need to make the following
preparations:
Prepare servers to be added in advance. If you have two servers, you can
seamlessly switch between the primary and secondary switch.
The admin installs the latest version of ZStack Cloud. For more information, see User Guide.
The admin purchases the Plus License of Tenant Management, in addition to
the Base License.
AD Users Create VM Instances
About this task
ZStack Cloud supports seamless access to 3rd-party
authentication systems. Through the service, related users can directly log in to
the Cloud and manage cloud resources. In this scenario, we will introduce how an AD
user logs in to the Cloud and creates a VM instance. The detailed steps are as
follows:
Admin adds an AD authentication server to the Cloud.
An AD user logs in to the Cloud.
An AD user creates a VM instance.
The following table lists the assumed customer scenario.
configuration
AD Attribute
Primary Server IP/Domain
172.24.254.21
SSL/TLS Encryption
Not Selected
Primary Server Port
389
Base DN
dc=adtest,dc=zs
User DN
CN=Administrator,CN=Users,DC=adtest,DC=zs
Password
password
Filter Policy
Enabled
Filter Mechanism
Blocklist
Filter Rule
(&(name=filterName)(description=departure))
Local Attribute
AD Attribute
Login Attribute
cn
User Name
cn
Name
name
Mobile Phone
telephoneNumber
Email
mail
Identifier
employeeID
Description
description
Local Attribute
AD Attribute
Organization Mapping Method
Group
Name
cn
Description
description
Procedure
Admin adds an AD authentication server to the Cloud.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > 3rd-Party Authentication. On the 3rd-Party Authentication page,
click Add 3rd-Party Authentication Server to add a
3rd-Party authentication server.
On the displayed page, set the following parameters:
Type: Select AD.
Server Configurations: Set the basic information and
configuration of an AD server.
Set the following
parameters:
Name: Enter a name for the AD
server.
Description: Optional. Enter a
description for the AD server.
Type: AD is
displayed.
Primary Server IP/Domain: Enter an IP
address or domain of the primary server.
Primary Server Port: Enter the
corresponding port of the primary server.
SSL/TLS Encryption: Choose whether to
select SSL/TLS encryption. By default, the SSL/TLS encryption is
selected.
If selected, the SSL/TLS encryption is used, which uses
port 636 by default and supports custom
modification.
If not selected, no encryption is used, which uses port
389 by default and supports custom modification.
Secondary Server IP/Domain: Optional.
Enter an IP address or domain of the secondary server.
Secondary Server Port: Optional. Enter
the corresponding port of the secondary server.
Configuration Info: To configure related
range information of synchronizing AD users, set the following
parameters:
Base DN: Enter a base DN to
specify the root for search AD users and organization
structures and defining the range of synchronizing
them.
User DN: Enter a user DN. A
particular user who owns all user permissions to check
the base DN range. It can be used to access AD servers
and obtain associated data.
Password: Specify the login
password associated with the user DN.
Filter Policy: Choose whether to
filter user information during synchronization. By
default, the filter is disabled.
Filter Mechanism: Choose to apply
the filtering mechanisms of blocklist and allowlist.
Note:
If you select Blocklist, when synchronizing
user information, the user information configured
in the filter rule will not be synchronized to the
Cloud.
If you select Allowlist, when synchronizing
user information, only the user information
configured in the filter rule can be synchronized
to the Cloud.
Filter Rule: Enter a filter rule
for the authentication server.
Note:
The filter rule length is subject to the
configurations of AD servers. Exceeding the length
will filter rules not to take effect. Make sure
that the user-defined length falls within the
length.
After the AD server configurations are completed,
click Next and the Cloud automatically tests the
connection and goes to the next step, or you can manually click
Test Connection to test the configuration
accuracy and connection of AD servers.
If the connection test succeeds, you can click
Next to configure other
parameters.
If the connection test fails, you can edit the configuration
according to the error messages on the upper-right corner until
the connection test succeeds.
Synchronize Mapping Rule: Specify login attribute, user
mapping rule, and synchronize organization mapping.
Set
the following parameters:
Login Attribute: Specify AD user
attributes for Cloud logins.
For example, if cn is used as the
login attribute, AD users can use the value (such as John)
matching cn as their login name in the Cloud.
User Mapping Rule: Select or enter a rule
to map AD user attributes to Cloud local attributes. Set the
following parameters:
User Name: Specify a rule to map
AD usernames to Cloud usernames.
For example: If a
User Name maps cn, the User Name whose user is
created in the Cloud can use the value (such as
John) matching cn to log in to the
Cloud.
Note: The user name of ZStack Cloud users cannot be
duplicated. If the synchronized AD users has the
identical user name with that of Cloud users, the
Cloud will automatically adds a random code in the
user name of the synchronized AD users.
Name: Specify a rule to map the
name of AD users to that of Cloud users.
For example:
If a Name maps name, the Name whose user is created
in the Cloud can use the value (such as Jack)
matching name.
Mobile Phone: Optional. Specify a
rule to map the mobile phone of AD users to that of
Cloud users.
For example: If a Mobile Phone maps
telephoneNumber, the Mobile Phone whose user is
created in the Cloud can use the value (such as
13800000000) matching telephoneNumber.
Email: Optional. Specify a rule
to map the email of AD users to that of Cloud
users.
For example: If a Email maps mail, the
Email whose user is created in the Cloud can use the
value (such as xxx@xxx.xx) matching mail.
Identifier: Optional. Specify a
rule to map the identifier of AD users to that of Cloud
users.
For example: If a Identifier maps
employeeID, the Identifier whose user is created in
the Cloud can use the value (such as 001) matching
employeeID.
Description: Optional. Specify a
rule to map the description of AD users to that of Cloud
user.
For example: If a Description maps
description, the Description whose user is created
in the Cloud can use the value (such as dev-John)
matching description.
Custom Attribute: You can
customize a rule to map SSO attributes of a
SSO user to Cloud local attributes.
System User Attribute:
Specify a system user attribute, which can be
identical with the original attribute, such as
Identifier.
AD/LDAP User Attribute:
Specify an AD/LDAP user attribute, such as
employeeID.
Synchronize Organization Mapping: Choose
whether to synchronize organization. By default this option is
disabled. If enabled, AD organizations in the user-based DN
range will be synchronized to the organization list in the
Cloud.
Organization Mapping Method:
Select a organization mapping method.
Group: Subtrees of an organization tree are
distinguished by Group parameters, and AD groups
will be synchronized to the organizational list in
the Cloud (Recommended).
OU: Subtrees of an organization structure tree
can be distinguished by OU parameters, and AD
groups will be synchronized to the organizational
list in the Cloud.
Organization Mapping Rule:
Name: Specify a rule to
map the name of AD organizations to that of Cloud
organizations.
For example: If an organization
name maps cn, the organization name whose
organization is created in the Cloud can use the
value (such as dev-department) matching
cn.
Description: Optional.
Specify a rule to map the description of AD
organizations to that of Cloud
organizations.
For example: If an organization
description maps description, the organization
description whose organization is created in the
Cloud can use the value (such as dev-backend)
matching description.
Figure 70. Synchronize Mapping Rule
Click Next, and the Cloud
automatically tests whether the login attribute, user mapping rule, and
synchronize organization mapping can be successfully created. After the
test succeeds, the Cloud automatically adds the mapping rules.
Note: Make
sure that all AD attributes are specified. Otherwise, the test may
fails. If the test fails, you need to edit the mapping rule
configurations according to the error messages until the mapping
rules are successfully added.
Preview: Confirm the relevant information and
configurations of the AD server to be added. You can edit the configuration
by clicking the edit icon.
Figure 71. Preview
Click Complete to add an AD
server, create SSO users, and add organizations.
An AD user logs in to the Cloud.
Add the AD user to the project and assign permissions to it. Then, an AD user
logs in to the Cloud through Project Login with a Chrome browser or FireFox
browser: http://management_node_ip:5000/#/project. On the
Project Login page, select AD/LDAP
User and enter the corresponding username and password.
Figure 72. AD User Log in to the Cloud
Note:
3rd-party users are the same as local Cloud users except for the
login method. You can perform basic operations on 3rd-party
users in the tenant management, such as join project, join
department, modify permission.
You need to add a 3rd-party user to a project and assign
permissions to it before login. Otherwise, a blank page will be
displayed after logging in.
An AD user creates a VM instance.
An AD user logs in to the Cloud. On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, you can create
a VM instance quickly through the fast creation method. For more
information, see Create a VM Instance (Fast Creation).
What to do next
So far, we have introduced how AD users create VM
instances.
LDAP Users Create VM Instances
About this task
ZStack Cloud supports seamless access to 3rd-party
authentication systems. Through the service, related users can directly log in to
the Cloud and manage cloud resources. In this scenario, we will introduce how a LDAP
user logs in to the Cloud and creates a VM instance. The detailed steps are as
follows:
Admin adds an LDAP authentication server to the Cloud.
A LDAP user logs in to the Cloud.
A LDAP user creates a VM instance.
The following table lists the assumed customer scenario.
configuration
Attribute
Primary Server IP/Domain
172.20.198.123
SSL/TLS Encryption
Not Selected
Primary Server Port
389
Base DN
dc=mevoco,dc=com
User DN
cn=Manager,dc=mevoco,dc=com
Password
password
Filter Policy
Enabled
Filter Mechanism
Blocklist
Filter Rule
(&(name=filterName)(description=departure))
Local Attribute
LDAP Attribute
Login Attribute
cn
User Name
cn
Name
cn
Mobile Phone
mobile
Email
mail
Identifier
employeeNumber
Description
description
Procedure
Admin adds an LDAP authentication server to the Cloud.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > 3rd-Party Authentication. On the 3rd-Party Authentication page,
click Add 3rd-Party Authentication Server to add a
3rd-Party authentication server.
On the displayed page, set the following parameters:
Type: Select LDAP.
Server Configurations: Set the basic information and
configuration of a LDAP server.
Set the following parameters:
Name: Enter a name for the LDAP
server.
Description: Optional. Enter a
description for the LDAP server.
Type: LDAP is
displayed.
Primary Server IP/Domain: Enter an IP
address or domain of the primary server.
Primary Server Port: Enter the
corresponding port of the primary server.
SSL/TLS Encryption: Choose whether to
select SSL/TLS encryption. By default, the SSL/TLS encryption is
selected.
If selected, the SSL/TLS encryption is used, which uses
port 636 by default and supports custom
modification.
If not selected, no encryption is used, which uses port
389 by default and supports custom modification.
Secondary Server IP/Domain: Optional.
Enter an IP address or domain of the secondary server.
Secondary Server Port: Optional. Enter
the corresponding port of the secondary server.
Configuration Info: To configure related
range information of synchronizing LDAP users, set the following
parameters:
Base DN: Enter a base DN to
specify the root for search LDAP users and organization
structures and defining the range of synchronizing
them.
User DN: Enter a user DN. A
particular user who owns all user permissions to check
the base DN range. It can be used to access LDAP servers
and obtain associated data.
Password: Specify the login
password associated with the user DN.
Filter Policy: Choose whether to
filter user information during synchronization. By
default, the filter is disabled.
Filter Mechanism: Choose to apply
the filtering mechanisms of blocklist and allowlist.
Note:
If you select Blocklist, when synchronizing
user information, the user information configured
in the filter rule will not be synchronized to the
Cloud.
If you select Allowlist, when synchronizing
user information, only the user information
configured in the filter rule can be synchronized
to the Cloud.
Filter Rule: Enter a filter rule
for the authentication server.
Note:
The filter rule length is subject to the
configurations of LDAP servers. Exceeding the
length will filter rules not to take effect. Make
sure that the user-defined length falls within the
length.
After the LDAP server configurations are completed, click
Next and the Cloud automatically tests the
connection and goes to the next step, or you can manually click
Test Connection to test the configuration
accuracy and connection of LDAP servers.
If the connection test succeeds, you can click
Next to configure other
parameters.
If the connection test fails, you can edit the configuration
according to the error messages on the upper-right corner until
the connection test succeeds.
Synchronize Mapping Rule: Specify login attribute and
user mapping rule.
Set the following parameters:
Login Attribute: Specify LDAP user
attributes for Cloud logins.
For example, if cn is used as the
login attribute, LDAP users can use the value (such as John)
matching cn as their login name in the Cloud.
User Mapping Rule: Select or enter a rule
to map LDAP user attributes to Cloud local attributes. Set the
following parameters:
User Name: Specify a rule to map
LDAP usernames to Cloud usernames.
For example: If a
User Name maps cn, the User Name whose user is
created in the Cloud can use the value (such as
John) matching cn to log in to the
Cloud.
Note: The user name of ZStack Cloud users cannot be
duplicated. If the synchronized LDAP users has the
identical user name with that of Cloud users, the
Cloud will automatically adds a random code in the
user name of the synchronized LDAP
users.
Name: Specify a rule to map the
name of LDAP users to that of Cloud users.
For
example: If a Name maps cn, the Name whose user is
created in the Cloud can use the value (such as
Jack) matching cn.
Mobile Phone: Optional. Specify a
rule to map the mobile phone of LDAP users to that of
Cloud users.
For example: If a Mobile Phone maps
mobile, the Mobile Phone whose user is created in
the Cloud can use the value (such as 13800000000)
matching mobile.
Email: Optional. Specify a rule
to map the email of LDAP users to that of Cloud
users.
For example: If an Email maps mail, the
Email whose user is created in the Cloud can use the
value (such as xxx@xxx.xx) matching mail.
Identifier: Optional. Specify a
rule to map the identifier of LDAP users to that of
Cloud users.
For example: If an Identifier maps
employeeNumber, the Identifier whose user is created
in the Cloud can use the value (such as 001)
matching employeeNumber.
Description: Optional. Specify a
rule to map the description of LDAP users to that of
Cloud user.
For example: If a Description maps
description, the Description whose user is created
in the Cloud can use the value (such as dev-John)
matching description.
Custom Attribute: You can
customize a rule to map SSO attributes of a
SSO user to Cloud local attributes.
System User Attribute:
Specify a system user attribute, which can be
identical with the original attribute, such as
Identifier.
AD/LDAP User Attribute:
Specify an AD/LDAP user attribute, such as
employeeNumber.
Figure 74. Synchronize Mapping Rule
Click Next, and the Cloud automatically tests
whether login attribute and user mapping rules can be successfully
created. After the test succeeds, the Cloud automatically adds the
mapping rules.
Note: Make sure that all LDAP attributes are specified.
Otherwise, the test may fails. If the test fails, you need to edit
the mapping rule configurations according to the error messages
until the mapping rules are successfully added.
Preview: Confirm the relevant information and
configuration of the LDAP server to be added. You can edit the configuration
by clicking the edit icon.
Figure 75. Preview
Click Complete to add an
LDAP server and create SSO users.
A LDAP user logs in to the Cloud.
Add the LDAP user to the project and assign permissions to it. Then, a LDAP
user logs in to the Cloud through Project Login with a Chrome browser or
FireFox browser: http://management_node_ip:5000/#/project. On the
Project Login page, select AD/LDAP
User and enter the corresponding username and password.
Figure 76. LDAP User Logs in to the Cloud
Note:
3rd-party users are the same as local Cloud users except for the
login method. You can perform basic operations on 3rd-party
users in the tenant management, such as join project, join
department, modify permission.
You need to add a 3rd-party user to a project and assign
permissions to it before login. Otherwise, a blank page will be
displayed after logging in.
A LDAP user creates a VM instance.
A LDAP user logs in to the Cloud. On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, you can create
a VM instance quickly through the fast creation method. For more
information, see Create a VM Instance (Fast Creation).
What to do next
So far, we have introduced how LDAP users create VM
instances.
OIDC Users Create VM Instances
Prerequisites
Users of the OIDC authentication system are synced to the Cloud and configured with
relevant project and platform roles.
About this task
ZStack Cloud supports seamless access to OIDC/OAuth2/CAS
authentication systems. Through the service, related users can directly log in to
the Cloud without the password and manage cloud resources. In this scenario, we will
take an OIDC user as an example to introduce how OIDC/OAuth2/CAS users log in to the
Cloud without the password and create VM instances. The detailed steps are as
follows:
The OIDC authentication system admin configures the Cloud to be the client
of the authentication system.
Admin adds an OIDC authentication server to the Cloud.
An OIDC user logs in to the Cloud password-freely.
An OIDC user creates a VM instance.
Procedure
The OIDC authentication system admin configures the Cloud to be the client of
the authentication system.
The OIDC authentication system admin logs in to the corresponding
authentication system and configures the Cloud to be the client of the
authentication system. Then, the authentication system generates an unique
Client ID and Client Secret for the Cloud.
Admin adds an OIDC authentication server to the Cloud.
On the main menu of ZStack Cloud, choose Operational Management > Tenant Management > 3rd-Party Authentication. On the 3rd-Party Authentication page,
click Add 3rd-Party Authentication Server to add a
3rd-Party authentication server.
On the displayed page, set the following parameters:
Type: Select OIDC.
Server Configurations: Set the basic information and configuration of an
OIDC server.
Set the following parameters:
Name: Enter a name for the OIDC
server.
Description: Optional. Enter a
description for the OIDC server.
Type: OIDC is
displayed.
Redirect URL: The URL
used to redirect to the Cloud when the authentication server is
certified.
Redirect Template: The
redirect template used to realize a password-free login inside
the cloud platform system. You can modify the IP address and
port of this parameter when the Cloud is configured with a
reverse proxy.
Configuration Info: To configure the
required information of synchronizing an OIDC authentication
server, set the following parameters:
Client ID: Enter the unique ID
that the authentication system assigns to the
Cloud.
Client Secret: Enter the secret
that the authentication system assigns to the
Cloud.
Authorization Request URL: Enter
the request URL used to obtain an authorization grant in
authorization code mode.
Token Request URL: Enter the
request URL used to obtain an access token from the
authentication server.
Userinfo Request URL: The request
URL used to obtain the user information from the
authentication server.
Logout URL: The URL used to log
off sessions after logging out of the Cloud. When
logging in to the Cloud again, you need to re-enter the
authentication server. If left blank, the login
information will not be immediately cleared after
logging out of the Cloud, and you can still log in to
the Cloud without a password as long as the session is
valid.
Figure 77. OIDC Server Configuration
Synchronize Mapping Rule: Specify user mapping rules for an OIDC
authentication server.
Set the following parameters:
User Mapping Rule: Through the mapping
rule, the SSO user has local user attributes after it is
synced to the Cloud. The rule is used to map SSO
attributes of an SSO user to Cloud local attributes.
User Name: Specify a rule to map
the attribute of OIDC users to the username of Cloud
users. The username is the unique identification of a
user. Make sure that the username that you fill in also
has a unique identity in the authentication
system.
For example: If a User Name maps username,
the User Name whose user is synced to the Cloud can
use the value (such as John) matching
username.
Name: Specify a rule to map the
attribute of OIDC users to the name of Cloud
users.
For example: If a Name maps name, the Name
whose user is created in the Cloud can use the value
(such as Jack) matching name.
Mobile Phone: Optional. Specify a
rule to map the attribute of OIDC users to the mobile
phone of Cloud users.
For example: If a Mobile Phone
maps telephoneNumber, the Mobile Phone whose user is
created in the Cloud can use the value (such as
13800000000) matching telephoneNumber.
Email: Optional. Specify a rule
to map the attribute of OIDC users to the email of Cloud
users.
For example: If an Email maps mail, the
Email whose user is created in the Cloud can use the
value (such as xxx@xxx.xx) matching mail.
Identifier: Optional. Specify a
rule to map the attribute of OIDC users to the
identifier of Cloud users.
For example: If an
Identifier maps employeeID, the Identifier whose
user is created in the Cloud can use the value (such
as 001) matching employeeID.
Description: Optional. Specify a
rule to map the attribute of OIDC users to the
description of Cloud users.
For example: If a
Description maps description, the Description whose
user is created in the Cloud can use the value (such
as dev-backend) matching description.
User Group: Optional. Specify a
rule to map the user group of an SSO
authentication server to the user group of the
Cloud.
For example: If a User Group maps
usergroup, the User Group created in the Cloud can
use the value (such as group-1, group-2) matching
usergroup.
Note: If the Cloud has multiple user
groups that share the same name as the mapped user
group, the SSO user will directly join the
existing user groups after logging in to the Cloud.
If you do not want the synced user to be added to
multiple user groups, you can edit the user group
name or delete unnecessary user groups.
Figure 78. Synchronize Mapping Rule
Preview: Confirm the relevant information and configuration of the OIDC
server to be added.
Figure 79. Preview
Click Complete to add an OIDC server and
synchronize SSO user information.
An OIDC user logs in to the Cloud password-freely.
After an OIDC authentication server is added to the Cloud, the Cloud
generates the Password-free Login URL. An OIDC user can log in to the
Cloud password-freely by click the corresponding icon after the admin of the
business application system configure the URL to the application system
(such as unified web portal).
Figure 80. Password-Free Login URL
An OIDC user creates a VM instance.
An OIDC user logs in to the Cloud. On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, you can create
a VM instance quickly through the fast creation method. For more
information, see Create a VM Instance (Fast Creation).
What to do next
So far, we have introduced how OIDC users create VM
instances.
Note: Notice that
project members can only view the organization structure where their
team belongs to.
