Keystone(OpenStack Identity Service)是 OpenStack 框架中负责管理身份验证、服务规则和服务令牌功能的模块。用户访问资源需要验证用户的身份与权限，服务执行操作也需要进行权限检测，这些都需要通过 Keystone 来处理。Keystone类似一个服务总线， 或者说是整个Openstack框架的注册表， 其他服务通过keystone来注册其服务的Endpoint（服务访问的URL），任何服务之间相互的调用， 需要经过Keystone的身份验证， 来获得目标服务的Endpoint来找到目标服务。
openstack是一个SOA架构，各个项目独立提供先关的服务，且互不依赖，如nova提供计算服务，glance提供镜像服务等。防止耦合性，且扩展性不高实际上所有的组件都依赖keystone，它有两个功能：
（1）用户管理：验证用户身份信息合法性
（2）服务目录管理：提供各个服务目录的（Service Catalog:包括service和endpoint）服务，无论任何服务或者客户访问openstack都要访问keystone获取服务列表，以及每个服务的endpoint
KEYSTONE基本概念
User
User即用户，他们代表可以通过keystone进行访问的人或程序。Users通过认证信息（credentials，如密码、API Keys等）进行验证。
Tenant
Tenant即租户，它是各个服务中的一些可以访问的资源集合。例如，在Nova中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。
Role
Role即角色，Roles代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role规定的权限。
Service
Service即服务，如Nova、Glance、Swift。根据前三个概念（User，Tenant和Role）一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时，他必须知道这个service是否存在以及如何访问这个service，这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role，实际上也是可以绑定到某个service的。例如，当swift需要一个管理员权限的访问进行对象创建时，对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标，我们应该创建两个独立的管理员role，一个绑定到swift，另一个绑定到nova，从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。
Endpoint
Endpoint，翻译为“端点”，我们可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。因此，在keystone中包含一个endpoint模板（endpoint template，在安装keystone的时候我们可以在conf文件夹下看到这个文件），这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表，列表中的每个URL都对应一个服务实例的访问地址，并且具有public、private和admin这三种权限。
public url可以被全局访问（如http://compute.example.com），端口 5000
private url只能被局域网访问（如http://compute.example.local），端口 5000
admin url被从常规的访问中分离 端口：35357
Credentials
用于确认用户身份的凭证。说白了就是“信物”，可以是：
（1）：用户名和密码
（2）：用户名跟API Kye（秘钥） #（1）（2）用户第一次确认身份的方法
（3）：一个keystone分配的身份的token #（3）用户已经确认身份后的方法 （token是有时间限制的）
Auhentication
（1）：用户身份验证的过程。keystone服务通过检查用户的Credentials来确定用户的身份
（2）：第一次验证身份是使用用户名与密码或者用户名与API Key的形式。当用户的Credentials被验证后，keystone会给用户分配一个Authentication token 供该用户的后续请求操作（返回的token中就包含User的Role列表）
Token
（1）：是一串数字字符串，当用户访问资源时需要使用的东西，在keystone中主要是引入令牌机制来保护用户对资源的访问，同时引入PKI、PKIZ、fernet、UUID其中一个随机加密产生一串数字，对令牌加以保护
（2）：token并不是长久有效的，是有时效性的，在有效的时间内可以访问资源。
Policy
（1）：对于keystone service 来说，Policy就是一个JSON文件，rpm安装默认是在/etc/keyston/policy.json。通过配置这个文件，keystone实现了对User基于Role的权限管理（User <-- Role（ACL） <--Policy）
（2）：Policy就是用来控制User对Project（tenant）中资源的操作权限
Project（Tenant）
（1）：Project（Tenant）是一个人或服务所拥有的资源集合。不同的Project之间资源是隔离的，资源可以设置配额
（2）：Project（Tenant）中可以有多个User，每一个User会根据权限的划分来使用Project（Tenant）中的资源
（3）：User在使用Project（Tenant）的资源前，必须要与这个Project关联，并且制定User在Project下的Role，一个assignment(关联) 即：Project-User-Role
Service
即服务，如Nova，Glace，等各个组件
Keystone管理对象之间的关系
在Openstack-M版本中就使用了Keystone-V3。V3在V2的基础上引入了域和用户组的概念，将 Tenant 改称为 Project，V3将逐步替代V2。
V3的组织结构
V3的改进
问题1：在Keystone V2中，资源分配是以Tenant为单位的，这不太符合现实世界中的层级关系。如一个公司在 Openstack中拥有两个不同的项目，他需要管理两个Tenant来分别对应这两个项目，并对这两个Tenant中的用户分别分配角色。由于在Tenant之上并不存在一个更高层的概念，无法对 Tenant 进行统一的管理，所以这给多 Tenant 的用户带来了不便。
解决：V3 利用 Domain 的概念实现真正的多租户(multi-tenancy)架构，Domain 担任 Project 的高层容器。云服务的客户是 Domain 的所有者，他们可以在自己的 Domain 中创建多个 Projects、Users、Groups 和 Roles。通过引入 Domain，云服务客户可以对其拥有的多个 Project 进行统一管理，而不必再向过去那样对每一个 Project 进行单独管理。
简而言之，Domain的引入是为了将多个Project进行封装，成为单一实体再交付给相应的一个客户使用。
问题2：在 Keystone V2中，用户的权限管理是以每一个用户为单位，需要对每一个用户进行角色分配，并不存在一种对一组用户进行统一管理的方案，这给系统管理员带来了额外的工作和不便。
解决：V3引入了Group的概念，Group 是一组 Users 的容器，可以向 Group 中添加用户，并直接给 Group 分配角色，那么在这个 Group 中的所有用户就都拥有了 Group 所拥有的角色权限。通过引入 Group 的概念，Keystone V3 实现了对用户组的管理，达到了同时管理一组用户权限的目的。这与 V2 中直接向 User/Project 指定 Role 不同，使得对云服务进行管理更加便捷。
类比操作系统中的用户组，是批量便捷操作的体现。
Keystone 和其它 OpenStack service之间的交互和协同工作：首先User向Keystone提供自己的Credentials(凭证：用于确认用户身份的数据，EG. username/password)。Keystone会从SQL Database中读取数据对User提供的Credentials进行验证，如验证通过，会向User返回一个Token，该Token限定了可以在有效时间内被访问的 OpenStack API Endpoint和资源 。此后User所有的Request都会使用该Token进行身份验证。如用户向Nova申请虚拟机服务，Nova会将User提供的Token发送给Keystone进行Verify验证，Keystone会根据Token判断User是否拥有执行申请虚拟机操作的权限，若验证通过那么Nova会向其提供相对应的服务。其它Openstack和Keystone的交互也是如此。