keystone架构分析

Keystone基本概念介绍1. UserUser即用户，他们代表可以通过keystone进行访问的人或程序。

Users通过认证信息（credentials，如密码、API Keys等）进行验证。

2. TenantTenant即租户，它是各个服务中的一些可以访问的资源集合。

例如，在Nova 中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Quantum中一个tenant可以是一些网络资源。

Users默认的总是绑定到某些tenant上。

3. RoleRole即角色，Roles代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。

Users可以被添加到任意一个全局的或租户内的角色中。

在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role 规定的权限。

4. ServiceService即服务，如Nova、Glance、Swift。

根据前三个概念（User，Tenant 和Role）一个服务可以确认当前用户是否具有访问其资源的权限。

但是当一个user尝试着访问其租户内的service时，他必须知道这个service是否存在以及如何访问这个service，这里通常使用一些不同的名称表示不同的服务。

在上文中谈到的Role，实际上也是可以绑定到某个service的。

例如，当swift需要一个管理员权限的访问进行对象创建时，对于相同的role我们并不一定也需要对nova进行管理员权限的访问。

为了实现这个目标，我们应该创建两个独立的管理员role，一个绑定到swift，另一个绑定到nova，从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。

5. EndpointEndpoint，翻译为“端点”，我们可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。

因此，在keystone中包含一个endpoint模板（endpoint template，在安装keystone的时候我们可以在conf文件夹下看到这个文件），这个模板提供了所有存在的服务endpoints信息。

一个endpoint template包含一个URLs列表，列表中的每个URL都对应一个服务实例的访问地址，并且具有public、private和admin这三种权限。

public url可以被全局访问（如），private url只能被局域网访问（如http://compute.example.local），admin url被从常规的访问中分离。

2 关于keystone Managerkeystone-manage is the command line tool that interacts with the keystone service to initialize and update data within Keystone. Generally, keystone-manage is only used for operations that can not be accomplished with through the keystone REST api, such data import/export and schema migrations.3,关于keyston的admin-api和service-apiThe service API is defined to be a subset of the Admin API and, by default, runs on port 5000.4,关于keyston的架构Keystone ArchitectureMuch of the design is precipitated from the expectation that the auth backends for most deployments will actually be shims in front of existing user systems.The ServicesKeystone is organized as a group of internal services exposed on one or many endpoints. Many of these services are used in a combined fashion by the frontend, for example an authenticate call will validate user/tenant credentials with the Identity service and, upon success, create and return a token with the Token service.IdentityThe Identity service provides auth credential validation and data about Users, Tenants and Roles, as well as any associated metadata.In the basic case all this data is managed by the service, allowing the service to manage all the CRUD associated with the data.In other cases, this data is pulled, by varying degrees, from an authoritative backend service. An example of this would be when backending on LDAP. See LDAP Backend below for more details.TokenThe Token service validates and manages Tokens used for authenticating requests once a user/tenant’s credentials have already been verified.CatalogThe Catalog service provides an endpoint registry used for endpoint discovery.PolicyThe Policy service provides a rule-based authorization engine and the associated rule management interface.Application ConstructionKeystone is an HTTP front-end to several services. Like other OpenStack applications, this is done using python WSGI interfaces and applicationsare configured together using Paste. The application’s HTTP endpoints are made up of pipelines of WSGI middleware, such as:These in turn use a subclass of posingRouter to link URLs to Controllers (a subclassof mon.wsgi.Application). Within each Controller, one or more Managers are loaded (for example,see keystone.catalog.core.Manager), which are thin wrapper classes which load the appropriate service driver based on the keystone configuration.∙Identity∙keystone.identity.core.TenantController∙erController∙keystone.identity.core.RoleController∙Catalog∙keystone.catalog.core.ServiceController∙keystone.service.VersionController∙Token∙keystone.service.TokenController∙Misc∙keystone.service.ExtensionsControllerAt this time, the policy service and associated manager is not exposed as a URL frontend, and has no associated Controller class.Service BackendsEach of the services can configured to use a backend to allow Keystone to fit a variety of environments and needs. The backend for each service is defined in the keystone.conf file with the key driver under a group associated with each service.A general class under each backend named Driver exists to provide an abstract base class for any implementations, identifying the expected service implementations. The drivers for the services are:∙keystone.identity.core.Driver∙keystone.token.core.DriverIf you implement a backend driver for one of the keystone services, you’re expected to subclass from these classes. The default response for the defined apis in these Drivers is to raisea keystone.service.TokenController.KVS BackendA simple backend interface meant to be further backended on anything that can support primary key lookups, the most trivial implementation being an in-memory dict.Supports all features of the general data model.SQL BackendA SQL based backend using SQLAlchemy to store data persistently. The keystone-manage command introspects the backends to identify SQL based backends when running “db_sync” to establish or upgrade schema. If the backend driver has a method db_sync(), it will be invoked to sync and/or migrate schema.PAM BackendExtra simple backend that uses the current system’s PAM service to authenticate, providing a one-to-one relationship between Users and Tenants with the root User also having the ‘admin’ role.Templated BackendLargely designed for a common use case around service catalogs in the Keystone project, a Catalog backend that simply expands pre-configured templates to provide catalog data.Example paste.deploy config (uses $ instead of % to avoid ConfigParser’s interpolation):[DEFAULT]catalog.RegionOne.identity.publicURL =http://localhost:$(public_port)s/v2.0catalog.RegionOne.identity.adminURL =http://localhost:$(public_port)s/v2.0catalog.RegionOne.identity.internalURL =http://localhost:$(public_port)s/v2.0 = 'Identity Service'LDAP BackendThe LDAP backend stored Users and Tenants in separate Subtrees. Roles are recorded as entries under the Tenants.。