Openstack组件实现原理 — Keystone认证功能
目录
- 目录
- 前言
- 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管理对象之间的关系
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的组织结构
一个 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 admin和Role 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的资源Authentication认证功能的应用过程
- 身份认证(Authentication)：令牌Token的发放和校验
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中所处的位置如下图所示：
