您好,登录后才能下订单哦!
今天就跟大家聊聊有关Openstack 中keystone组件的作用是什么,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
User即用户,他们代表可以通过keystone进行访问的人或程序。Users通过认证信息(credentials,如密码、API Keys等)进行验证。
Tenant即租户,它是各个服务中的一些可以访问的资源集合。例如,在Nova中一个tenant可以是一些机器,在Swift和Glance中一个tenant可以是一些镜像存储,在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。
Role即角色,Roles代表一组用户可以访问的资源权限,例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中,用户的role权限作用于所有的租户,即可以对所有的租户执行role规定的权限;在租户内的role中,用户仅能在当前租户内执行role规定的权限。
Service即服务,如Nova、Glance、Swift。根据前三个概念(User,Tenant和Role)一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时,他必须知道这个service是否存在以及如何访问这个service,这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role,实际上也是可以绑定到某个service的。例如,当swift需要一个管理员权限的访问进行对象创建时,对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标,我们应该创建两个独立的管理员role,一个绑定到swift,另一个绑定到nova,从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。
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,等各个组件
在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的交互也是如此。
看完上述内容,你们对Openstack 中keystone组件的作用是什么有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。