Openstack组件 — Keystone认证功能实现原理

目录

  • 目录
  • 前言
  • Keystone安装列表
  • Keystone架构
    • Keystone的管理对象
      • 一个理解Keystone管理对象功能的例子
      • Keystone管理对象之间的关系
  • Keystone V3的新特性
    • V3的改进
  • Authorization授权功能的应用
  • Authentication认证功能的应用过程

前言

Keystone实现始终围绕着Keystone所实现的功能来展开,所以在理解其实现之前,建议大家尝试通过安装Keystone这一个过程来感受Keystone在Openstack架构中所充当的角色。下面给出了Keystone-M的安装过程。

Keystone安装列表

Openstack组件部署 — Overview和前期环境准备
Openstack组建部署 — Environment of Controller Node
Openstack组件部署 — Keystone功能介绍与认证实现流程
Openstack组件部署 — Keystone Install & Create service entity and API endpoints
Openstack组件部署 — keystone(domain, projects, users, and roles)

Keystone架构

Keystone的管理对象

User:指使用Openstack service的用户,可以是人、服务、系统,但凡使用了Openstack service的对象都可以称为User。

Project(Tenant):可以理解为一个人、或服务所拥有的 资源集合 。在一个Project(Tenant)中可以包含多个User,每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中,在Cinder创建卷也要指定到某个Project中。User访问Project的资源前,必须要与该Project关联,并且指定User在Project下的Role。

Role:用于划分权限。可以通过给User指定Role,使User获得Role对应的操作权限。Keystone返回给User的Token包含了Role列表,被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role _member_ 。

Policy:OpenStack对User的验证除了OpenStack的身份验证以外,还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操作权限。对于Keystone service来说,Policy就是一个JSON文件,默认是/etc/keystone/policy.json。通过配置这个文件,Keystone Service实现了对User基于Role的权限管理。

Token:是一个字符串表示,作为访问资源的令牌。Token包含了在 指定范围和有效时间内 可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机,在Swift和Glance中一个tenant可以是一些镜像存储,在Network中一个tenant可以是一些网络资源。Token一般被User持有。

Credentials:用于确认用户身份的凭证

Authentication:确定用户身份的过程

Service:Openstack service,即Openstack中运行的组件服务。

Endpoint:一个可以通过网络来访问和定位某个Openstack service的地址,通常是一个URL。比如,当Nova需要访问Glance服务去获取image 时,Nova通过访问Keystone拿到Glance的endpoint,然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类:

  • admin url –> 给admin用户使用,Post:35357
  • internal url –> OpenStack内部服务使用来跟别的服务通信,Port:5000
  • public url –> 其它用户可以访问的地址,Post:5000

public url可以被全局访问,private url只能被局域网访问,admin url被从常规的访问中分离。

一个理解Keystone管理对象功能的例子

如果把宾馆比作为Openstack,那么宾馆的中央管理系统就是Keystone,入住宾馆的人就是User 。在宾馆中拥有很多不同的房间,房间提供了不同的服务(Service)。在入住宾馆前,User需要给出身份证(Credential),中央管理系统(Keystone)在确认User的身份后(Authenticaiton),会给你一个房卡(Token)和导航地图(Endpoint)。不同VIP(Role)级别的User,拥有不同权限的房卡(Token),如果你的VIP(Role)等级高,你可以享受到豪华的总统套房。然后User拿着房卡(Token)和地图(Endpoint),就可以进入特定的房间去享受不同的Services。每一个服务(Services)中都拥有着一些特定资源(Project),例如:按摩服务中可以使用的精油种类和数量。User可以根据自己的权限来使用这些资源。

组件 类比
Openstack 宾馆
Keystone 中央管理系统
Project 旅游项目,拥有宾馆的某些资源
User 旅客
Credentials 旅客的身份证
Authentication 确定旅客身份的过程
Token 房卡
Role VIP等级
Endpoint 服务提供场所的地址
Service 宾馆可以提供的服务类别

Keystone管理对象之间的关系

Openstack组件 — Keystone认证功能实现原理_第1张图片

Keystone V3的新特性

这节的内容引用自IBM developerWorks

  • Tenant 重命名为 Project
  • 添加了 Domain 的概念
  • 添加了 Group 的概念

在本系列的Openstack-M版本中就使用了Keystone-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 不同,使得对云服务进行管理更加便捷。
类比操作系统中的用户组,是批量便捷操作的体现。

Authorization授权功能的应用

  • 授权(Authorization):授予用户在一个服务中所拥有的权限

V3的组织结构
Openstack组件 — Keystone认证功能实现原理_第2张图片
一个 Domain 包含有 3 个 Project,可以通过 Group1 将 Role Sysadmin直接赋予 Domain1,那么 Group1 中的所有用户将会对 Domain1 中的所有 Projects 都拥有管理员权限。也可以通过 Group2 将 Role Engineer 只赋予 Project3,这样 Group2 中的 User 就只拥有对 Project3 相应的权限,而不会影响其它 Projects。

不妨回顾一下,在Openstack组件部署 — keystone(domain, projects, users, and roles)一篇中,我们在domain default内创建了用于管理的project admin、User adminRole admin,并且将Role admin赋予了Project admin中的User admin。使得User admin拥有了管理员的权限。当然我们在这个操作中,并没有使用到Group的功能,仍然直接对Tenant中的User分配了角色。

openstack domain create --description "Default Domain" default
openstack project create --domain default --description "Admin Project" admin
openstack user create --domain default --password-prompt admin
openstack role create admin
openstack role add --project admin --user admin admin  #User admin与Project admin关联,并指定该用户在该租户下的角色Role admin,这样用户admin才能够访问租户admin的资源
  • 1
  • 2
  • 3
  • 4
  • 5

Authentication认证功能的应用过程

  • 身份认证(Authentication):令牌Token的发放和校验

Openstack组件 — Keystone认证功能实现原理_第3张图片

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的交互也是如此。
所以Keystone在Openstack中所处的位置如下图所示:

Openstack组件 — Keystone认证功能实现原理_第4张图片

你可能感兴趣的:(openstack)