The keystone of OpenStack learning

Keystone Project provides user management, rights Management, user authentication and other functions, but also provides Servicecatalog, which is the endpoint of all services in OpenStack. Endpoint is the base URL for the rest API. Keystone is the portal for OpenStack, and calling the OpenStack Rest API starts with Keystone.
Rest API Flow1) Call Keystone Tokens API (/v3/auth/tokens, POST), authenticate the user and create tokens. 2) The API will return token and service catalog 3) using token and endpoint in service catalog to invoke rest API (e.g. Nova API) 4) the REST API validates user-supplied tokens
Before calling the OpenStack Rest API, get a token from the Kestone tokens API, which is filled in the ' x-auth-token ' field of each Rest API request header. Token is a random string, generated by Kyestone, that represents a user who has passed the authentication (through which it can also get the user's various information, role, group, etc.). The token returned by Keystone has an expiration date, and after the expiration date, the rest API is invoked with this token and the validation fails. Kwargs.setdefault (' headers ', {}) [' x-auth-token '] = Self.auth_token
Using OpenStack commands (Nova, cinder,neutron,keystone), you need to provide these parameters (generally written in OPENRC file) os_username Os_password os_tenant_name Os_ Auth_url where Os_auth_url is the endpoint of Keystone REST API. This information is used to authenticate users in the Keystone.

need to certify the linkVarious services in OpenStack require authentication (authentication) to be used. The services in OpenStack are primarily database services, REST API services, and RPC services (using the underlying messaging system, such as RABBITMQ). Most of the services in OpenStack are used to provide RPC services, and RPC server.
Database service:Authentication is performed by MySQL, which invokes the database service to provide credentials (credential). Database services are primarily used internally by OpenStack systems and are not available to external users, and are typically deployed in the management network. Provided in the configuration file, such as nova.conf sql_connection = Mysql://root:stackdb@127.0.0.1/nova?charset=utf8 The concept of a management network in the An introduction to OpenStack Learning's vernacular OpenStack.
RPC Service:All RPC services are provided by RPC server and are available to users in the form of RPC APIs. The call to RPC API is also required for authentication, which is done by the underlying messaging system (such as RABBTIMQ, Qpid). The RPC API is primarily used internally by OpenStack systems and is not available to external users, and is typically deployed in the management network. There will be credentials for the RPA API in the configuration file, such as Rabbit_password Rabbit_userid in Nova.con rabbit_hosts
REST API Service:The Rest API Service provides the implementation of the rest API. OpenStack's Rest API has two types of users: OpenStack internal users (OpenStack projects are accessed through the rest API, such as the Api,nova that Nova calls Cinder, which is the internal user of the Cinder Rest API). Internal users generally use the internal endpoint address to call rest, internally used endpoint deployed in the management network; external users, OpenStack end users (end user) or system Administrator (Admin), generally use public Endpoint address to call rest.
Both users need to get tokens through the Keystone API when they call the rest API, and then fill in this token with the REST API request. Credential information for internal users is written in the configuration file, such as nova.conf Admin_password = Admin_user = Nova admin_tenant_name = Service Auth_protocol Auth_port
Auth_host General internal users will use user credentials with Admin role. If the Nova user in the service has admin role
External users call the rest API to also provide user credentials, such as the os_xxx provided earlier in this article.
How the rest API is certifiedThe rest API uses tokens from the request to authenticate the user. In the rest service configuration file, a method for authenticating tokens is given. As in Nova Api-paste.ini [Filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
Similar configurations are available in other rest service configuration files. Filter_factory checks if the token in the request is correct. Authenticated tokens are cached locally, filter_factory also checks if the authenticated token has expired or expires (revoked or expired)
authentication and generation of Keystone tokensThere are two ways to generate tokens for Keystone: UUID and PKI. Token authentication also has two ways of doing this. Token generation is implemented in Keystone. Token authentication at Keystoneclient implementation (Keystoneclient.middleware.auth_token:filter_factory) is currently Keystone by default using PKI token mode.
UUID TokenThe UUID token generation call UUID.UUID4 (). Hex UUID Token authentication Uuid_token authentication calls Keystone Rest api:get/v2.0/tokens/$TOKEN. The call is a rest call, with additional overhead.
PKI TokenToken generation calls Def cms_sign_token (text, Signing_cert_file_name, signing_key_file_name)
Token authentication calls the DEF cms_verify (formatted, signing_cert_file_name, ca_file_name) PKI token authentication without the need to invoke the Keystone REST API, Instead, local authentication is based directly on the certificate file and the key file, and performance is better than UUID token authentication.
This two function is defined in Python-keystoneclient keystoneclient/common/cms.py the two sets of implementations will invoke OpenSSL's corresponding command to implement, please refer to the code. OpenSSL cms-sign OpenSSL cms-verify
Keystone need to configure Signing_cert_file_name and signing_key_file_name to generate PKI tokens. The rest API needs to be configured with Signing_cert_file_name and signing_key_file_name to validate PKI tokens. The 2 sets of files in the build and verify need to be consistent.
PKI token generation and authentication is based on the CMS (cryptographic Message Syntax) algorithm. Http://www.ietf.org/rfc/rfc3370.txt
python clientOpenStack provides a variety of Python clients to simplify user calls to the OpenStack rest API. The main Python client has python-keystoneclient python-glanceclient python-novaclient python-cinderclient python-swiftclient Python-neutronclient ...
Various commands in OpenStack (such as Keystone,glance,nova,cinder,neutron ...) is provided by the Python client. The calling command needs to be provided: Os_username Os_password os_tenant_name Os_auth_url
version of the RESR API:Because the OpenStack rest API evolves, the rest API introduces a version concept to ensure compatibility with existing code. There are currently 3 versions of the Nova Rest API, V1.1,v2,v3. The rest API for each project provides an interface for querying API versions, as in Nova, you can query all API versions supported in Nova with Get/.
With the Python client, you can specify an API version, such as Python-novaclient, which can be used with the export os_compute_api_version=1.1 if not specified, using the default API version Default_os_ Compute_api_version = "1.1"
Keystone REST API version:Keystone REST API also has multiple versions. Because each Python client needs to get tokens through Keystone Rest, the Python client also determines which version of the Keystone Rest API to use. The Keystone REST API version is determined in python-novaclient based on the user-supplied Os_auth_url os_auth_url=http://localhost:5000/v2.0 The 2.0 version of the Keystone Rest API is used.
From the implementation of the code, the current Python client only supports v1.0 and V2.0 's Keystone Rest API, and there is no support for v3.0. if self.version = = "v2.0": Self._v2_auth (Auth_url) Else:self._v1_auth (Auth_url)