1, Install and configure the keystone(controller) component of the service token function
Overview of Keystone
OpenStack identity services provide a single point of integration for managing authentication, authorization, and service catalogs.
Identification service is usually the first service with which users interact. After authentication, end users can use their identity to access other OpenStack services. Similarly, other OpenStack services use identity services to ensure that users are what they say and to discover where other services are deployed. Identity services can also be integrated with some external user management systems, such as LDAP.
Users and services can use the service directory managed by the identity service to locate other services. As the name suggests, a service directory is a collection of services available in an OpenStack deployment. Each service can have one or more terminals, and each terminal can be one of three types: admin, internal or public. In a production environment, for security reasons, different terminal types may be located on different networks exposed to different types of users. For example, the public API network can be seen from the Internet, so customers can manage their cloud. Managing the API network may be limited to operators within the organization that manages the cloud infrastructure. The internal API network may be limited to hosts that contain OpenStack services. In addition, OpenStack supports multiple regions for scalability. For simplicity, this guide uses the management network for all terminal types and the default RegionOne area. The regions, services and terminals created in the identity service together constitute the deployed service directory. Each OpenStack service in the deployment requires a service entry containing the corresponding terminal stored in the identity service. All this can be done after installing and configuring the identity service.
The identity service consists of the following components:
- Server: the centralized server provides authentication and authorization services using the RESTful interface.
- Drivers: drivers or service back ends are integrated into a centralized server. They are used to access identity information in an OpenStack external repository and may already exist in the infrastructure where OpenStack is deployed (for example, an SQL database or LDAP server).
- Modules: middleware modules run in the address space of OpenStack components that use identity services. These modules intercept service requests, extract user credentials, and send them to a centralized server for authorization. The integration between the middleware module and OpenStack components uses the Python Web server gateway interface.
yum install openstack-keystone httpd python3-mod_wsgi
:set nu G
The 2000 line configuration is too difficult to find a location,
Make a backup. After removing the comments, there are more than 40 lines. It's much easier to find the configuration
cp /etc/keystone/keystone.conf /etc/keystone/keystone.conf.bak grep -Ev '^$|#' /etc/keystone/keystone.conf.bak >/etc/keystone/keystone.conf vim /etc/keystone/keystone.conf
Add the following configuration, KEYSTONE_DBPASS replaces the password set for the database.
[database] connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone [token] provider = fernet
su -s /bin/sh -c "keystone-manage db_sync" keystone
Initialize Fernet key
keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone keystone-manage credential_setup --keystone-user keystone --keystone-group keystone
Boot identity service
Before Queens is released, keystone needs to run on two separate ports to accommodate the Identity v2 API, which usually runs a separate management only service on port 357. After deleting the v2 API, keystone can run on the same port of all interfaces.
keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne
Edit the / etc/httpd/conf/httpd.conf file and configure the ServerName option to reference the controller node:
tips: if the ServerName entry does not exist, you need to add it.
sudo sh -c 'echo "ServerName controller" >> /etc/httpd/conf/httpd.conf'
Create a link to the / usr/share/keystone/wsgi-keystone.conf file:
ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
The security deployment should configure the web server to use SSL or run after the SSL terminator.
Start the Apache HTTP service and configure it to start when the system boots:
systemctl enable httpd.service systemctl start httpd.service
Configure the management account by setting the appropriate environment variables:
export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=ADMIN_PASS export OS_AUTH_URL=http://controller:5000/v3 export OS_IDENTITY_API_VERSION=3
The values shown here are the default values created from the keystone manage boot.
Add ADMIN_PASS is replaced by [keystone manage bootstrap] in keystone install configure rdo
Create domains, projects, users, and roles
The "default" domain already exists in the keystone manage bootstrap step, but the formal method to create a new domain is:
openstack domain create --description "An Example Domain" example
Create a service item that contains a unique user for each service you add to the environment:
openstack project create --domain default \ --description "Service Project" service
General (non administrator) tasks should use non privileged items and users. For example, create myproject project and myuser.
To create a myproject project:
openstack project create --domain default \ --description "Demo Project" myproject
Create myuser user:
openstack user create --domain default \ --password-prompt myuser
Create myrole role:
openstack role create myrole
Add myrole role to myproject project and myuser user (associated project, user, role):
openstack role add --project myproject --user myuser myrole
You can repeat the above command to create other projects and users.
Unset temporary OS_AUTH_URL and OS_PASSWORD environment variable:
unset OS_AUTH_URL OS_PASSWORD
As an administrator user, request an authentication token:
openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue
As the myuser user user created in the previous section, request an authentication token:
openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name myproject --os-username myuser token issue
Create OpenStack client environment script
The previous part combines environment variables and command options to interact with the identity service through the openstack client. In order to improve the efficiency of client operation, openstack supports simple client environment scripts (also known as OpenRC files). These scripts typically contain common options for all clients, but also support unique options. For more information, see OpenStack end user guide.
Create client environment scripts for admin, demo projects, and users. These scripts will be referenced later to load the appropriate credentials for the client operation.
tips: the path of the client environment script is unlimited. For convenience, you can place scripts anywhere, but make sure they are accessible and in a secure location suitable for your deployment, as they do contain sensitive credentials.
Create and edit the admin openrc file and add the following (replace admin_pass with the password set by the admin user in the identity service):
export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=ADMIN_PASS export OS_AUTH_URL=http://controller:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2
Create and edit the demo openrc file and add the following (replace admin_pass with the password set by the demo user in the identity service):
export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=myproject export OS_USERNAME=myuser export OS_PASSWORD=DEMO_PASS export OS_AUTH_URL=http://controller:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2
To run the client as a specific project and user, simply load the associated client environment script before running. For example:
Load the admin openrc file and populate the environment variables to use the location of the identity service, admin project, and user credentials: