First knowledge of Keystone

Objective

The concept of OpenStack does not speak much, because it does not understand. Only know Keystone, what other services are doing, how to use, there is no driving force to understand, so consciously shut up, only paste a more interesting picture.

The OpenStack community is very active, a lot of developers, code and documentation updates are also very frequent, in recent days to see the document in the process of the document content adjustment, although the official web documents very much, but feel a little scattered, coupled with the V2 and V3 versions coexist, some concepts and design is evolving, New scholars at the beginning is not easy to get a clue, the following on this period of learning Keystone Some of the experience to do a summary.

The Chinese meaning of "keystone" is the Keystone Stone, which is the most middle stone above the stone arch, and the stones on both sides will not fall off.

Keystone, a member of the OpenStack family, became a core service in the 2012 version of the Essex, which unifies the internal identity, Catalog, token, and policy services to provide additional services to OpenStack. The two most important features are user authentication and what the user is allowed to do, another feature is cataloging the service, what services are available, and what their access points are.

Basic concepts

The core concepts of Keystone include: User, Project (tenant), Domain,token, role, service, endpoint, etc., V3 version renaming V2 version of tenant to project, The domain concept is also added.

Here is the domain model I summarized:

• The user represents a user, has associated usernames and passwords, and other data such as email
• Project includes some infrastructure resources, and remember someone who says project (formerly tenant) is like a hotel with a variety of facilities
• Domain is a new addition to V3, similar to namespaces, where the user name, project, group name can be the same between different domain names. But domain and role names must be globally unique.
• Role is a character, such as Admin,member, the name can be casually up, called "Her Majesty" is not a problem, but each service has the right to explain the definition of the role, the following will further explain this
• Group also seems to be V3 new concept, can group users, directly to group permissions, there is a GBP (Group based policy). Group is not required in Keystone.
• Token is the token, the user authentication is assigned to a token, and later holding the token can be within the scope of the activity, that is, the token not only has identity information, such as user role, but also the scope of action, usually project and domain, and the token has a validity period, expired expiration If the middle performance is not good, may also be early revoked (revoke)

Further explain the relationship between the above concepts: role is relative, a user can have different role in different project, you must specify domain or project when granting role to user or group, domain is the biggest concept now, Can include Project,user, etc., in two domain can build two sets of names exactly the same, but different functions of the system.

Catalog is a directory or registry that provides service indexing services, tells users what services they have, and how they can find them (endpoint). In the cloud, different services may be scattered around the corner, or a service may provide a nearby service access point depending on the region. Keystone supports two ways to register the catalog, one is a template file, the other is the SQL storage method, the former reference Keystone source directory Etc/default_ Catalog.templates, which needs to be registered via API after Keystong startup.

There is a key concept not mentioned, is policy, understand it took me several bags of smoke. The following statement may not be entirely correct, but it still speaks for the moment.

Policy provides the RBAC (Role based access control) feature, which is managed by each service itself and consists of a set of rule, each service defining its own rule. When the user accesses the API provided by the service, tell the services what role you are, but the service itself interprets the meaning of role. For example, the British Queen to a Commonwealth country, people look at the Fuhrer came, hurriedly give you the popular drink spicy, good wine to serve, basically you want to do what you do, but, if the Queen to an Arab country, people may be the most polite to you, you can do to listen to others, and even the door is not allowed to enter, You are not welcome at all.

One thing Keystone do is that all back-end provider are configurable, and users can customize the provider. For policy, each service defaults to the Oslo-incubator policy engine, which reads the Policy.json file to resolve the corresponding relationship between action and role, and determines whether the user has permission to perform the appropriate action. The implementation of Oslo-incubator is in openstack/common/policy.py.

In the V3 version, Keystone provides an API for operating policy, which is stored in DB and may be prepared for future centralized control permissions. But for now, this feature is not really used.

Keystone Middleware-auth_token

This thing has not been studied carefully, here and there.

Keystone for each service to provide certification services, how to use the various services? A tall on the way is to use Auth_token, put into the pipeline, each service itself is responsible for Auth_token installation and configuration. In fact, HTTP interceptors, intercept every HTTP request, check the head token information, extract the user, role and other information, if the verification passed, release, otherwise refused the request.

Certification process

Paste the flow chart can be seen everywhere, to tell the truth, there is a step did not understand, trouble sensible to speak

Is the 4th step, endpoint to Keystone process, inside said there is "Does it allow that service usage" process, this Keystone how to judge? Other not much to say, very well understood.

Uuid&pki

Keystone tokens are available in two formats: UUID and PKI. UUID is a fixed-length random string, PKI full name is public key Infrastructure, this concept should belong to the category of encryption, not Keystone original, details please Niang or Google.

Both formats have pros and cons, the biggest difference is that the UUID must be keystone each time to be certified, and the PKI is self-contained, the service can itself according to the standard algorithm to check the signature, the benefit is to improve the validation efficiency, Keystone does not become the bottleneck for the entire openstack. But PKI token also poses a problem, because PKI tokens contain a lot of metadata and information such as catalog, it will be very large, not only to bring network overhead, and may exceed some server restrictions, throw exceptions. Here's how to verify your PKI signature and how to resolve tokens too large.

Insert a sentence, last night wrote here when the night is 12 o'clock, suddenly unable to save the article, then a refresh, CSDN directly return 500, internal upgrade ... Fortunately throw away not much, otherwise white code has so many words, will not cry to die.

PKI offline authentication

In the test environment, the private key and self-signed certificate are generated through Keystone-manage pki_setup, for the concepts of public key, private key, certificate and so on, please refer to my forwarded previous article "CentOS6.5 OpenSSL encryption and decryption and CA self-signed certificate in detail", It's not explained here anymore.

The PKI token of Keystone is actually the signature of JSON data containing metadata, such as users, roles, catalog, etc., with its own private key and CA certificate, with the following commands:

OpenSSL Cms-sign-signer/etc/keystone/ssl/certs/signing_cert.pem-inkey/etc/keystone/ssl/private/signing_key.pem- Outform Pem-nosmimecap-nodetach-nocerts-noattr < Metadata.json

If you do not redirect, you can use the-in and-out parameters to generate a CMS-formatted file. The cipher generated by the above command is token.

Verify token legality is to take Keystone's certificate and CA's signing certificate to check, the command is:

OpenSSL Cms-verify-certfile/etc/keystone/ssl/certs/signing_cert.pem-cafile/etc/keystone/ssl/certs/ca.pem-inform Pem-nosmimecap-nodetach-nocerts-noattr < Cms_token

If the command returns successfully, you can see the original metadata.

However, the token from the Keystone API does not conform to the CMS standard, can not directly invoke the above command, need to do a conversion, refer to the Keystone Source:

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py

def token_to_cms (signed_text):    copy_of_text = signed_text.replace ('-', '/')    lines = ['-----BEGIN cms-----']    lines + = Textwrap.wrap (Copy_of_text, +)    lines.append ('-----END CMS-----\ n ')    return ' \ n '. Join (lines)

That is to replace the original token with some characters, plus a CMS comment at both ends, and then fold the token string by 64 characters per line. This is OK if you call the above verification command again. Token is too big.

This problem in the Keystone community also has a lot of discussion, give a variety of solutions, here summarizes I see a few, for your reference

• Use a UUID Token, nonsense ~
• Replace the original token with the MD5 value of the PKI token in the X-auth-token attribute of the HTTP request header. I've verified that work is fine, but I lost the metadata that was originally included.
• Turn off catalog, give metadata weight loss, verify with this url:v3/auth/tokens? Nocatalog
• Using zlib to compress tokens, the provider to configure tokens in keystone.conf is: Provider=keystone.token.providers.pkiz.provider

Keystone installation configuration on Ubuntu

It is said that Ubuntu is a good Linux distribution for OpenStack support, but the Keystone version installed directly using Apt-get Install is older, related to Ubuntu repository, which I later installed directly from the source.

Environment Ubuntu 14.04 LTS, steps are as follows:

git clone http://github.com/openstack/keystone.gitpython setup.py install

Some python dependencies need to be installed in advance, such as Python-dev, Python-setuptools, Python-pip

Install configuration Mysql,keystone default to use Sqllite, I switch to MySQL, more familiar with some

sudo apt-get install python-mysqldb mysql-server

Configure MySQL Permissions

mysql> CREATE DATABASE keystone;mysql> GRANT all on keystone.* to ' Keystone ' @ '% ' identified by [Your_keystone_passwo RD];  Flush privileges;

Copy the configuration files from the Keystone source directory etc directory to the/etc/keystone directory, modify the configuration file suffix

Modify the main configuration keystone.conf, mainly changed several places, database connection, token provider, [signing] segment all open except the first

? connection=mysql://keystone:[password]@127.0.0.1/keystone?provider=keystone.token.providers.pki.provider

Initialize database, execute: keystone-manage Db_sync, possibly Python dependent, installation

Initialize SSL, create the Keystone user first, and then execute the Pki_setup

sudo groupadd keystonesudo useradd-g Keystone Keystonesudo chown-r keystone:keystone/etc/keystonesudo keystone-manage p Ki_setup--keystone-user Keystone--keystone-group Keystone

Finally start Keystone

Keystone-all [--debug]

Using the command line

Keystone has two clients, one is python-keystoneclient and the other is OpenStack client. The former does not currently support V3 APIs and is officially recommended for OpenStack client.

Installation method:

wget Http://tarballs.openstack.org/python-openstackclient/python-openstackclient-0.4.0.tar.gzsudo python setup.py Install

You need to take some parameters when executing OpenStack client commands, or you can set the environment variable

Export Os_identity_api_version=3export os_auth_url=http://localhost:5000/v3export os_token=netscreen export OS_URL= Http://localhost:35357/v3

You can then execute a command similar to the OpenStack user list, returning the result

Using Curl

Here are just a few examples, more references: http://docs.openstack.org/developer/keystone/api_curl_examples.html#

Curl-i   -H "Content-type:application/json"   -d ' {"auth": {"    identity": {      "Methods": ["Password"],      "Password": {        "user": {"          name": "admin",          "domain": {"id": "Default"}, "          password": "Secrete"        }      }    ,    "scope": {"      project": {        "name": "Demo",        "domain": {"id": "Default"}      }}}}  '   http://localhost:5000/v3/auth/tokens; echo

Return

Conclusion

It took two weeks to turn the Keystone over, only for technology selection. But if the RBAC is not based on OpenStack, only using Keystone to do a clustered application is meaningful, the answer is probably biased in favor of negation. "Cloud" for me is still floating high in the sky, remote unreachable, and later if there is a need to further study.

If there is any understanding error or selection suggestions, please advise, thank you.

First knowledge of Keystone