代码改变世界

Openstack组件部署 — Keystone功能介绍与认证实现流程

2016-06-13 02:02  云物互联  阅读(242)  评论(0)  编辑  收藏  举报

目录

前文列表

Openstack组件部署 — Overview和前期环境准备
Openstack组建部署 — Environment of Controller Node

Keystone认证服务

Keystone是Identity Service认证服务的Alias。为一个架构组件或服务或抽象对象取别名或项目名，在我看来就是老外的一个代码组织习惯，尤其常见于开源项目。Openstack学习之路从认识每一个功能组件开始，当然这会引入许多可能陌生的概念，在学习的过程中认识、理解、Kill all this，这是将会非常有意思的事情。

官档：The OpenStack Identity service provides a single point of integration for managing authentication, authorization, and service catalog services. Other OpenStack services use the Identity service as a common unified API. Additionally, services that provide information about users but that are not included in OpenStack (such as LDAP services) can be integrated into a pre-existing infrastructure.
In order to benefit from the Identity service, other OpenStack services need to collaborate with it. When an OpenStack service receives a request from a user, it checks with the Identity service whether the user is authorized to make the request.

粗译：Openstack身份认证服务提供了一个整合管理身份认证、授权、服务目录的point(Keystone组件基本就是围绕着这个point来展开)。其他的Openstack服务会使用Identity service的这个point来作为统一的API(这些API会被存放带一个服务目录中)。除此之外，Identity service还能够提供用户的相关信息，但这个信息并不会被包含在Openstack中，这些用户信息会被预先整合到一个基础架构中(例如LDAP service或SQL Database这些能够提供用户集中管理服务的组件)。
Identity service带来的好处在于，其他的Openstack需要通过Identity service来进行集中协调。当一个Openstack服务接收到一个用户的请求时，那么Openstack就会通过Identity service来检查这个用户是否有权限来发出这个请求。

**总而言之**Keystone这个子项目为Openstack通过了Account、Authentication、Authorization服务——简称3A。在安装OpenStack Identity service后，其他的OpenStack service必须要在Identity service中注册才能被使用。Identity可以追踪每一个OpenStack service的安装，并在系统网络中定位这个service的位置。

有了Identity service，Openstack就能够很好的对多个不同组件或者不同的用户进行协调和管理，在一个复杂的大型SOA软件系统中，需要Keystone这样的角色来支撑系统的松耦合架构设计。

我们要享受看官档的这个过程(os : 不要打我)

Identity service功能列表：

  • 身份认证(Authentication)：令牌的发放和校验
  • 用户授权(Authorization)：授予用户在一个服务中所拥有的权限
  • 用户管理(Account)
  • 服务目录(Service Catalog)：包含可用服务的API point

Keystone认证服务中的概念

User(用户)：一个People or System or Service在OpenStack中的数字表示。用于身份认证，也能够通过为登录到Openstack的用户分配令牌环，以此获得访问资源的权限。同一个用户可以被关联到给若干个租户，就像用户可以隶属于若干个不同的组。

Tenant(租户)：一个资源或对象的抽象表示。租户可以包含多个用户，不同租户之间相互隔离。根据service运行的需求，租户可以映射为账户、组织、项目或服务。

Role(角色)：可定制化的包含有特定用户权限的权限集合，可以关联到若干个User-Tenant对，来为User-Tenant对赋予权限。

Token(令牌)：用于限定User-Tenant对进行OpenStack API和资源访问的字符串表示。一个临牌会持续一段时间有效，也可以随时撤销。

Credentials(凭证)：用于确认用户身份的数据，例如：Username/Password

Authentication(检验)：是确定用户身份的过程。

Service(服务)：Openstack service，即Openstack中运行的组件服务。

Endpoint(端点)：一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。使用RESTful的设计思想，详见RESTful_URI资源 。

Keystone Client(Keystone CLI)：Keystone的命令行工具，可以完成诸如创建用户，角色，服务和端点等绝大多数的Leystone管理功能，是非常常用的CLI接口。

Keystone的验证过程

这里写图片描述
这里是一个用户创建实例的Keystone认证流程。

  • User wants to launch an instance 用户希望通过Service来启动一个实例

    • User –> Credentials are sent –> Keystone
    • User <– Temporary Token is created <– Keystone
    • User <– Generic catalog is sent <– Keystone
      User希望启动一个instance，首先User将自己的Credentials发送给Keystone，Keystone通过这个Credentials来确定User的身份。在User身份验证通过后，Keystone会将一个与User相对应的Temporary Token(含有对这个User的权限控制)和Generic catalog返回给User。

  • User requests all the tenants 用户请求获得所有租户的列表

    • User –> The Temporary Token is provided along the request –> Keystone
    • User <– A list of tenants is sent <– Keystone
      User将包含有Temporary Token的请求发送给Keystone，请求访问tenants(这个Token决定了User是否有权限访问tenants，或者有访问那些tenants的权限)，Keystone或根据Temporary Token来返回一个相应的tenants列表给User。

  • Keystone provides user with a list of services Keystone为用户提供一个Service的列表

    • User –> Credentials are sent with desired tenants –> Keystone
    • User <– Keystone sends a list of available services <– Keystone
    • User <– The tenant token is provided <– Keystone
    • User –> User determines the correct endpoint to launch a service–> Endpoint
    • User –> The token is provided along the request –> Endpoint
      User将Credentials发送给被包含在Keystone中的特定tenants，在通过验证后Keystone会将一个有效的服务列表和Tenant token返回给User(User在拥有了Tenant token之后才能够访问tenant所包含的service)。在用户在启动一个service之前，还需要确定这个service的位置，即User首先需要获取这个service正确的Endpoint。所以User需要将包含有与service对应的Tenant Token的请求发送到Endpoint，以此来确定service的位置。

  • The service verifies the user’s token Service验证用户提供的Tenant Token

    • Endpoint –> Is the Token correct? –> Keystone
    • Endpoint –> Does it allow that service usage? –> Keystone
      Endpoint将User发送的Tenant Token转发到Keystone之后，需要Keystone去确定两件事情。1.这个Tenant Token是否正确；2.用户是否能通过这个Tenant Token去访问指定service？

  • Keystone provides extra infos along the token Keystone提供附加信息和Tenant Token给Service

    • Keystone –> user’s tenant is authorized to access the service –> Service
    • Keystone –> the token matches with the request –> Service
    • Keystone –> That token belong to thr user –> Service
    • Service –> the service validates the request against its own policy –> Service
      在确定了上述两个问题后，Keystone将结果(1.User的tenant有权访问service；2.Tenant Token与User请求匹配；3.这个Tenant Token属于发出请求的User)发送给service。在service确定能够被User所操作之前，service还需要先确定User请求的操作内容。

  • The service executes the request Service执行用户的请求

    • the service create a new instance
      service执行用户新建了一个instance的请求。

  • The service reports the status back to the user 服务将执行结果状态返回给用户

    • The instance has been created
    • The instance is reacheable here
      告诉User instance已经创建好了。

注意：在上述过程中，常见的灰触发两个ERROR
1. 如果User发出的请求中所包含的Token在经过Keystone的验证后无效(Invalid)，则会出发401错误代码。
2. 如果Token有效，但Keystone却不能提供服务，则会返回503错误代码。

简单来说

  1. User 使用凭证(username/password) 到 keystone 验证并获得一个临时的 Token 和 Generic catalog(全局目录)
    ，临时的 Token 会存储在 keystone-client(cache UUID locally) 和 keystone-backend 中。
  2. User 使用这个临时 Token 发送给 keystone 并获得一个该 User 能访问的 Tenants 列表
  3. User 再跟 keystone 发送一个请求，表明希望访问的 Tenants
  4. keystone 就会向 User 发送一个管理这个 Tenants 的 Services 列表和允许访问这个 Tenants 的 Token (Tenants Token)
  5. User 会通过这个 Services 和 Generic catalog(全局目录) 映射找到 Services 的 endpoint，并通过 endpoint 找到实际 Services 组件的位置
  6. 然后 User 再拿着 Tenant Token 和 endpoint 来访问实际上的 Service 组件
  7. Service 组件会拿着这个 User-Tennat Token 对到 keystone 做进一步的验证(Openstack 要保证每一步操作都是安全的)
  8. 如果通过了 7. 的验证的话，keystone 会返回一系列的确认信息和附加信息(User 希望操作的内容)给 Services
  9. 最后 Services 执行一系列的操作