关于 OpenStack 的 Keystone

本文最近更新于 2021 年 03 月 24 日

OpenStack 是什么？

OpenStack 是一个与 Eucalyptus，AWS（Amazon web Services） 类似的 IaaS 框架，目前它包括三个主要的项目：Nova，Swift，Glance。

Nova：主要是为虚拟服务器提供自动创建和管理，负责管理所有的资源、网络、认证以及可扩展性。与 Amazon 的 EC2 和 Rackspace 的云服务器类似。

Swift：提供对象 blob 存储，该项目类似于 Rackspace 的云文件存储和 Amazon 的 S3。

Glance：是一个镜像项目，为 Nova 的虚拟机镜像提供发现，检索和存储功能。

Keystone 是什么？

Keystone（OpenStack Identity Service）是 OpenStack 框架中，负责身份验证、服务规则和服务令牌的功能， 它实现了 OpenStack 的 Identity API。Keystone 类似一个服务总线， 或者说是整个 Openstack 框架的注册表， 其他服务通过 Keystone 来注册其服务的 Endpoint（服务访问的 URL），任何服务之间相互的调用， 需要经过 Keystone 的身份验证， 来获得目标服务的 Endpoint 来找到目标服务。

为什么需要使用 Keystone？

最简单的鉴权方式是通过用户名和密码或者用户名和 keys 等，然后经由数据库检查。但是在 OpenStack 的世界，独立的服务非常多，所以我们不得不重新思考和设计鉴权方法。主要的问题是我们不可能使用一个用户实体应用于各个场景。例如，一个用户希望经由 Nova 取得鉴权，然后在 Glance 中创建/获取 images，或者在 Quantum 中建立网络。这就需要一个集中式的鉴权系统。

一些概念（引用 Aaron 的理解）：

Keystone 里面的概念很多，有：User，Credentials，Authentication，Token，Tenant，Service，Endpoint，Role。在这么多概念中，其实最主要的就是 User 和 Tenant 。由于一些安全，服务问题，才引发了其它的概念。

那什么叫做 User ，Tenant 呢？这里我举个比较好理解的例子。我们去宾馆住的时候，我们自己就相当于 User ，而宾馆就是 Tenant 。这是最简单的情况，宾馆值提供房间，我们只需要住房。

随着后来生活物质等的提高，这种现象就变了。我们去宾馆住的时候，很多东西都不一样，比如，开房间要身份证，房间的钥匙是一个可以当卡刷的牌子，我们进出宾馆的时候需要用自己的钥匙来开启宾馆的大门；还有就是，宾馆不仅仅是用来住的了，它可以给我们提供饮食，娱乐，健身等各种服务；而且服务层次的不同，房间也不同，房间里面的配置豪华程度也不一样。在这种情况下，描述我们和宾馆之间的关系就复杂一些了，这就引发了一些新的概念。

举完这个例子，Keystone 中的各种概念就可以和例子中的事物相挂钩了。

绑定关系：

Tenant 是各个服务中的一些可以访问的资源集合，User 默认的总是绑定到某些 Tenant 上。

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

Role 可以理解为一些 User 的分组，每一个 Role 会有一些资源的权限（例如 Nova 中的虚拟机、Glance 中的镜像），即 User 可以被添加到任意一个全局的或 Tenant 内的 Role 中。

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

Service 即服务，如 Nova、Glance、Swift。

在上文中谈到的 Role，实际上也是可以绑定到某个 Service 的。例如，当 Swift 需要一个管理员权限的访问进行对象创建时，对于相同的 Role 我们并不一定也需要对 Nova 进行管理员权限的访问。为了实现这个目标，我们应该创建两个独立的管理员 Role，一个绑定到 Swift，另一个绑定到 Nova，从而实现对 Swift 进行管理员权限访问不会影响到 Nova 或其他服务。

Endpoint 是一个服务的“访问点”。如果需要访问一个服务，则必须知道他的 Endpoint，因此，在 Keystone 中包含一个 Endpoint 模板，这个模板提供了所有存在的服务 Endpoint 信息。一个 Endpoint template 包含一个 URLs 列表，列表中的每个 URL 都对应一个服务实例的访问地址，并且具有 public、private 和 admin 这三种权限。public url 可以被全局访问（如 https://compute.example.com），private url 只能被局域网访问（如 https://compute.example.local），admin url 被从常规的访问中分离。

工作流程：

Now we have the global list of services that exist in our farm and we can bind tenants to them. Every tenant can have its own list of service instances and this binding entity is named the endpoint, which “plugs” the tenant to one service instance. It makes it possible, for example, to have two tenants that share a common image store but use distinct compute servers.

我们有了一个 Service 列表，并且将一些 Tenant 绑定在上面。每一个 Tenant 会有自己的 Service 实例列表（endpoint）。

This is a long list of entities that are involved in the process but how does it actually work?

1.To access some service, users provide their credentials to Keystone and receive a token. The token is just a string that is connected to the user and tenant internally by Keystone. This token travels between services with every user request or requests generated by a service to another service to process the user’s request.

2.The users find a URL of a service that they need. If the user, for example, wants to spawn a new VM instance in Nova, one can find an URL to Nova in the list of endpoints provided by Keystone and send an appropriate request.

3.After that, Nova verifies the validity of the token in Keystone and should create an instance from some image by the provided image ID and plug it into some network.

• At first Nova passes this token to Glance to get the image stored somewhere in there.

• After that, it asks Quantum to plug this new instance into a network; Quantum verifies whether the user has access to the network in its own database and to the interface of VM by requesting info in Nova.

All the way this token travels between services so that they can ask Keystone or each other for additional information or some actions.Here is a rough diagram of this process:

2016/12/22 #东京 发布
2017/01/13 #东京 更新