OpenStack Component Deployment-Add a custom Service to Keystone

Catalogue

The catalog Keystone certification process allows Keystone to provide validation capabilities for a new project Service finally

Keystone Certification Process User uses credentials (Username/password) to Keystone authentication and obtains a temporary token and Generic catalog (global catalog), and temporary tokens are stored in the keystone-client (cache UUID locally) and Keystone-backend. User uses this temporary Token to send to Keystone and obtains a tenants list that the user can access, and then sends a request to Keystone, indicating that the tenants Keystone you want to access will send a pipe to the user The Tenants Services list and the token (tenants token) User that allows access to this tenants will find services through this services and Generic catalog (global directory) mapping Endpoint, and through endpoint find the location of the actual Services component and then the User takes Tenant Token and endpoint to access the Real Service Group service component will hold this User-te Nnat Token to the Keystone to do further verification (Openstack to ensure that every step of the operation is safe) if passed 7. Validation, Keystone will return a series of confirmation and additional information (what the User wants to do) to the services final services to perform a series of operations so that Keystone provides validation capabilities for a new project Service in the new The Keytone authentication method is specified in the project's configuration file

[Keystone_authtoken]

Auth_uri = http://<keystone_service_ip>:5000
project_domain_id = default
project_name = Service
user_domain_id = default
password = Fanguiju
username = <new_service_name>
Auth_url = http://< keystone_service_ip>:35357
auth_plugin = password

the meaning of this configuration item:
Because most OpenStack services must access the Identity Service, you must configure the IP address of the Keystone server To is able to access it. You must also configure the Admin_tenant_name, Admin_user, and Admin_password options for each service to work.

In short, let each different Openstack service use a specific user registered in Keystone to access the Keystone service and request authentication services. The configuration item also specifies the project (resource) to which it belongs, which is the Tenant in the earlier version. This is set: The project belongs to the Tenant service. We'll use that later. So, first we need to register a user for this new project in Keystone.

fanguiju@fanguiju:~/devstack$ Keystone User-create--name <new_service_name>--pass fanguiju--enabled true

fanguiju@fanguiju:~/devstack$ OpenStack User List
+----------------------------------+----------+
| ID                               | Name     |
+----------------------------------+----------+
| 135b2cb86962401c82044fd4ca9daae4 | admin    |
| 40d75aebc9c34978b23081f8c8ca9af5 | <new_service_name>     |
| 626110b81b2b4509becafc1964121b7f | Nova     |
| 85c6b9fa9127439880276f070c60dad6 | Demo     |
| 887a5e92599847698c1f601d0f337421 | glance   |
| 9dc44b1518184c2cacecb2d2f9f8b050 | alt_ Demo |
| b340851dd5a24eb39a2383bb3f1ff36c | Cinder   |
+----------------------------------+----------+

Because the service for the new project belongs to the Tenant service, you need to register the service for the project in this Tenant

fanguiju@fanguiju:~/devstack$ OpenStack Service Create--name <new_service_name>--description "<new_service _name> Service "recovery +-------------+----------------------------------+ | Field |
Value | +-------------+----------------------------------+
| Description | <new_service_name> Service | | Enabled | True | | ID | C22EBCB4CDD24114A2D581CE18CDD0CA | | name | <new_service_name> | | Type |
Recovery | +-------------+----------------------------------+ fanguiju@fanguiju:~/devstack$ OpenStack Service list +---------- ------------------------+-------------+----------------+
| ID | Name |
Type | +----------------------------------+-------------+----------------+
| 1cfc85bed3e84f2b93c5a9b9c293e1ed | Cinder | Volume | | 348c1b372deb4c3fa817d340b439728b | EC2 | EC2 | | 3fa397c2b5d647389edae03515c64583 | Nova | Compute | | 41cfab784e6942189c8dc48fbda59c4e | Glance | Image | | 7b534b13bd024a04b44f6eeee882208a | Keystone | Identity | | 9b8de3d592054fc9b6b992be056ffd0a | nova_legacy | compute_legacy | | aed90494567e4deababddd494fc33338 | Cinderv2 | Volumev2 | | C22EBCB4CDD24114A2D581CE18CDD0CA | <new_service_name> |
Recovery | +----------------------------------+-------------+----------------+

Note : Name is the identity used for the display, and the actual effect between servces is Type. After registering in the Tenant service, you also need to create endpoint records so that the Serv of different projects The service that can be located between ices to the new project

fanguiju@fanguiju:~/devstack$ OpenStack Endpoint Create--region regionone <new_service_name>--publicurl ' http ://<new_service_ip>:8760/v1/$ (tenant_id) s '--internalurl ' http://<new_service_ip>:8760/v1/$ (tenant_ ID) s '--adminurl ' http://<new_service_ip>:8760/v1/$ (tenant_id) s ' +--------------+-------------------------- ----------------+
| Field |
Value | +--------------+------------------------------------------+
| Adminurl | http://<new_service_ip>:8760/v1/$ (tenant_id) s | | ID | 3c35ecc67e7444648dd079d5c0562f5b | | InternalUrl | http://<new_service_ip>:8760/v1/$ (tenant_id) s | | Publicurl | http://<new_service_ip>:8760/v1/$ (tenant_id) s | | Region | Regionone | | service_id | 513308f8e46944ac8baf1c9758062660 | | service_name | <new_service_name> | | Service_type |                       Recovery          |
 +--------------+------------------------------------------+

So far, the addition of the new project Service has not been completed, because the newly registered User in Keystone has no access to the Tenant so far, so it is not natural to get the Services list in Tenant. The ability to validate for new projects is not possible. Bind User to Tenant and Role

# get <new_service_id>/<service_id>/<member_id>
OpenStack user List     # <new_service_id >
Keystone tenant-list    # <service_id>
openstack role List     # <member_id>

# bind user to Relo Admin and Tenant service 
Keystone User-role-add--user <new_service_id>--role <member_id>--tenant & lt;service_id>
Keystone User-role-add--user <new_service_id>--role <admin_id>--tenant < Service_id>

Verifying Permissions for User

fanguiju@fanguiju:~/devstack$ source OPENRC <new_user> service fanguiju@fanguiju:~/devstack$ Keystone User-list                +----------------------------------+----------+---------+----------------------+
|   ID | name |        Enabled |
email | +----------------------------------+----------+---------+----------------------+
|  135b2cb86962401c82044fd4ca9daae4 |   admin |                      True | |
| 9dc44b1518184c2cacecb2d2f9f8b050 |   Alt_demo | True | alt_demo@example.com | |  b340851dd5a24eb39a2383bb3f1ff36c |   Cinder |                      True | |
|   85c6b9fa9127439880276f070c60dad6 |   Demo |   True | demo@example.com | |   40d75aebc9c34978b23081f8c8ca9af5 |   <new_service_user> |                      True | |
|  887a5e92599847698c1f601d0f337421 |   Glance |                      True | |
|   626110b81b2b4509becafc1964121b7f |   Nova |                      True |
| +----------------------------------+----------+---------+----------------------+ 

Using <new_user> also has access to the full user list, indicating that the user has admin privileges. finally

Summary :
1. The Openstack service requires a User registered in Keystone to access the Keystone service
2. The Openstack service should belong to the Tenant service and belong to the services resource.
3. This User should have admin or member permissions on the Tenant service, so you need to bind the User/tenant service/role admin together.
4. For Openstack services to be accessible to each other, the URL of the service needs to be registered with the endpoint.