导航：首页 > 服务器 >

Openstack 中keystone组件的作用是什么

发表于：2026-11-04 作者：千家信息网编辑

千家信息网最后更新 2026年11月04日，今天就跟大家聊聊有关Openstack 中keystone组件的作用是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。UserUser即用户

千家信息网最后更新 2026年11月04日Openstack 中keystone组件的作用是什么

今天就跟大家聊聊有关Openstack 中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的交互也是如此。