Bookmark this page

Chapter 2. Managing Application Projects in a Multitenant Cloud

Abstract

Goal	Create and configure projects with secure user access and sufficient resources to support cloud user application deployment requirements.
Objectives	Describe the use of OpenStack domains and projects to segregate applications and users, and create projects and user environments. Manage users and groups accessed from an enterprise identity management directory, and assign users with selected roles and privileges to projects. Manage resource quotas for an individual project, to ensure sufficient resource availability and protection from misuse.
Sections	Creating a Project Environment for Managing Applications and Resources (and Guided Exercise) Providing Cloud User Access to Projects (and Guided Exercise) Configuring Resource Limits in Projects (and Guided Exercise)
Lab	Managing Application Projects in a Multitenant Cloud

Creating a Project Environment for Managing Applications and Resources

Objectives

After completing this section, you should be able to describe the use of OpenStack domains and projects to segregate applications and users, and create projects and user environments.

Introduction to the Identity Service

The Red Hat OpenStack Platform (RHOSP) Identity service handles user and service authentication and authorization for all OpenStack activities. The service is organized by regions, then domains, and finally projects and subprojects. A region, for the purpose of this discussion, is the typical single-site Identity service (Keystone) deployment. A region contains domains, which are collections of user accounts, projects, and shared resources. Projects are collections of resources and users with roles. They provide an environment for building and deploying applications.

Domain operators use domains and projects to manage and limit resources for applications built to share the same resources and security requirements. Separate projects are used to isolate applications and their resources from each other. Cloud users are assigned only to the projects containing the applications they are developing, maintaining, and deploying.

Domain operators comprehend project structures, including Hierarchical Multitenancy (HMT), which is commonly used by cloud providers and telcos to delegate subprojects to clients and to manage overall resources from a parent project.

In a default, initial OpenStack deployment, the only existing user account is admin, assigned the system-scope admin role in the Default domain's admin project. Only a system-scope admin can create domain operator accounts, create domains, and assign domain-scope admin roles. All other course users were created in advance in the classroom build, and stored in the LDAP server on the utility node. Using an external LDAP provider with the organization's accounts is a typical identity management scenario, in which the human resources group handles user account creation, and OpenStack admins manage project and role assignments.

As a domain operator, you are assigned to one or more domains with a domain-scope admin role. Domain operators create projects, add members, and assign project-scope member roles. You can also delegate project management by assigning a project member with a project-scope admin role to a specific project. That member can add other members with roles, but only to that project.

Note

Roles are covered in detail in the the section called “Providing Cloud User Access to Projects” section.

The Identity service provides users with the privileges to execute commands on Red Hat OpenStack. The Identity service provides API client authentication and exposes one or more service endpoints. For example, a user authenticates via the Identity API endpoint before requesting other OpenStack services, such as listing or creating project resources.

Users set environment variables to declare the overcloud Identity service URL, domain, and project to use when using the command line. Users must source the correct environment file before performing OpenStack commands. The following example shows part of the admin-rc file created by the overcloud deployment:

[user@demo ~]$ cat admin-rc
...output omitted...
export OS_USERNAME=admin
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_AUTH_TYPE=password
export OS_PASSWORD=redhat

The following is another example, for the operator1 user:

[user@demo ~]$ cat operator1-finance-rc
...output omitted...
export OS_PASSWORD=redhat
export OS_PROJECT_DOMAIN_NAME=Example
export OS_PROJECT_NAME=finance
export OS_REGION_NAME=regionOne
export OS_USERNAME=operator1
export OS_USER_DOMAIN_NAME=Example

The admin user is in the Default domain, and operator1 is in the Example domain.

Managing OpenStack Domains and Projects

A project is a collection of resources, such as networks, images, and instances, and belongs to a domain. Projects can be nested using the HMT feature of the Identity service. HMT allows subprojects to inherit role assignments from a parent project, although the Dashboard is not currently capable to display project nesting. Typically, project resources are not accessible to users outside of the project which owns the resources, unless the resources are explicitly shared. However, users can have roles in multiple projects, and can switch between projects as needed. Projects ensure that users have access to a single OpenStack environment at a time, to avoid interfering with other project resources.

Domain operators may assign a project for a group within an organization, a specific developer, or for one or more specific applications. To configure a project, a domain operator creates the project, applies the required quotas, and assigns users to the project with appropriate roles.

Default Domains, Projects, and Users

RHOSP is installed with a default domain, named Default, containing two default projects, named admin and service. The Default domain is intended only as initial access to create other domains and site-wide shared resources. The Default domain is not intended as a location for new projects. Always create a new domain, such as the Example domain in this course, and log in as a domain-scope admin in that new domain, before creating new projects.

Use the Default domain admin project to create site-wide shared resources that all projects across domains can see and use, such as flavors, images, and external networks. Red Hat recommends against launching any instances using the admin project. The admin project admin user has unlimited site-level privileges. This admin user can create domains, groups, and users, and apply site-, domain- and project-scope roles to groups and users.

The service project holds one service account for each installed OpenStack service, named the same as the service. Normal users are restricted from being members in the service project. The service project is restricted from allowing normal user members. Service accounts are assigned both the system-scope admin role and the special service role. Service accounts are used to authenticate the service when user first makes a service request, to ensure that the user is connecting to a legitimate, registered service API. Service account responsibilities vary for each service, and are defined in that service's policies configured for the service role.

Domains and Their Use Cases

Domains represent collections of projects, users, and resources; these collections are owned by only one domain. Domains define a space to isolate resources, and can only be created by the cloud administrator. The Default admin project is special, in that resources created within it are shared for site-wide use. An advantage of domains is that a user assigned the domain-scope admin role can manage the whole domain. That user manages domain resources, such as projects and users, and delegates roles. Red Hat recommends restricting the default domain for only service accounts and creating separate domains, with separate identity management back ends, for normal user accounts.

Note

Resources, such as networks, disks, and instances, can belong to only a single domain. Resources are not shared across domains, and cannot be moved to another domain. Moving resources requires deleting them in one domain and creating them again in another.

User accounts can only belong to a single domain. However, users can be assigned roles in another domain's projects.

The domain operator may assign domains for an organization, a customer, or an operator. Red Hat OpenStack Platform separates these domains by the authentication method back end, such as Microsoft Active Directory Domain Service (AD DS), Red Hat Identity Management (IdM), or LDAP. Red Hat OpenStack Platform uses these authentication back ends for user account authentication (identity), and retains authorization management (access) for the authenticated users in the Identity service database.

For example, a cloud provider hosts various customers, and each customer requires a different authentication back end. The customers' cloud resources are segregated using domains. RHOSP helps customers choose between the various authentication back ends supported by the cloud provider. Domains also help the cloud provider to host all the customers using a single OpenStack environment.

Note

Domains cannot be created in the OpenStack Dashboard. When OpenStack recognizes that multiple domains exists, and the current user has sufficient privileges in multiple domains, the fields for assigning domains for projects becomes available.

Creating and Deleting Domains Using the OpenStack CLI

The following steps outline the process for creating and deleting a domain using the OpenStack unified CLI.

Execute the source command against the identity environment file so that the OpenStack unified command-line tool can communicate with the OpenStack services. To create a domain, the user must have the system-scope admin role.

Create the domain using the openstack domain create command. The command takes the domain name as an argument. You can use the --description option to specify the description for the domain, but this is optional. The domain is enabled by default; to start with the domain disabled use the --disable option.

Delete the domain using the openstack domain delete command. This command takes the domain name or ID as an option.

Use the openstack domain list command to list all domains, and to verify that the domain was deleted.

Creating and Deleting Projects

Any user assigned a site or domain admin role can create and delete projects. Projects have resource quotas, which are configured at project creation, or modified as needed. Project quotas that are not explicitly set during project creation will use default quota settings. When a project is deleted, only the project's user assignments and some resources are removed. Project resources should be removed before the project is deleted.

Creating and Deleting Projects Using the OpenStack CLI

To create a project, you need the domain-scope admin role. Source the identity environment file of a user with this assigned role, to have sufficient privilege when communicating with the OpenStack services.

Create the project using the openstack project create command. This command takes the project name as an argument. You can use the description option to specify a description for the project, but this is optional. The project is enabled by default, but you can use the disable option to start with the project disabled.

[user@demo ~(admin)]$ openstack project create \
> --description "Demo Org Project" --domain demo-org demo-project

Delete the project using the openstack project delete command. This command takes the project name or ID as an option. You can delete multiple projects at the same time with a space-separated list.

[user@demo ~(admin)]$ openstack project delete \
> --domain demo-org demo-project

Use the openstack project list command to list all currently available projects and verify that you deleted the project.

[user@demo ~(admin)]$ openstack project list
...output omitted...

Creating and Deleting Projects Using the Dashboard

To create a project, open the Dashboard in a web browser and log in as a user with the domain-scope admin role. Navigate to Identity → Projects and then click Create Project.

In the Project Information tab, enter a project name in the Name field, and optionally enter a description in the Description field. Select Enabled to enable the project, or clear it to leave the project disabled.

Click Create Project to create the project.

Figure 2.1: Creating projects on the Dashboard

To delete a project with the Dashboard, navigate to Identity → Projects, and select the project to be deleted. Click Delete Projects, and then click Delete Projects again to confirm the deletion.

References

Additional information is available in the section on Project Management in the Users and Identity Management Guide for Red Hat OpenStack Platform, at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/users_and_identity_management_guide/index

Discuss Red Hat OpenStack Administration I: Core Operations for Domain Operators

Go to community

Red Hat OpenStack Administration I: Core Operations for Domain Operators (CL110)

Haley_Ruccio

1 sie 2023

Learn to operate a Red Hat® OpenStack Platform private cloud and manage domain resources to secure and deploy modern, scalable cloud applications, networks and storageRed Hat OpenStack Administration I: Core Operations for Domain Operators (CL110) teaches you how to operate and manage a production Red Hat OpenStack Platform (RHOSP) single-site overcloud. You will learn how to create secure project environments in which to provision resources and manage security privileges that cloud users need to deploy scalable cloud applications. You will learn about OpenShift integration with load balancers, identity management, monitoring, proxies, and storage. You will also develop more troubleshooting and Day 2 operations skills in this course.This course is based on Red Hat OpenStack Platform 16.1.Course content summaryStudents in the Red Hat OpenStack Administration I: Core Operations for Domain Operators (CL110) course will focus on performing both routine and specialized tasks that are necessary to manage a production OpenStack overcloud domain. Students will manage OpenStack using both web-based and command-line interfaces. Essential skills covered in the course include the following:Launch instances to satisfy various use case examples.Manage domains, projects, users, roles, and quota in a multitenant environment.Manage networks, subnets, routers, and floating IP addresses.Manage instance security with group rules and access keys.Create and manage block, object and shared storage within OpenStack.Perform instance launch customization with cloud-init.Deploy scalable applications using stack templates.Audience for this courseThis course is designed for cloud users who deploy application instances and stacks, domain operators who manage resources and security for cloud users, and any other cloud personnel interested in, or responsible for, maintaining applications on private or hybrid OpenStack clouds. Any cloud persona, or personnel with roles that include performing technology evaluation, should attend this course to learn RHOSP operation and application deployment methods.Prerequisites for this courseBecome a Red Hat Certified System Administrator (RHCSA) or demonstrate equivalent experienceIf you are not a RHCSA, you can take a skill assessment to gauge your level of knowledge.

Welcome to the Red Hat OpenStack Administration I (CL110) group in the Red Hat Learning Community!

Syed

31 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course CL110! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to CL110.Read more about Red Hat OpenStack Administration I: Core Operations for Domain Operators here.

Revision: cl110-16.1-4c76154