Keystone初探

导读：本博文简要介绍openstack中keystone模块，受众是刚接触openstack的同学。

• 什么是keystone？
• 为什么要keystone?
• keystone为什么要设计成这样？
• keystone client有哪些命令？
• keystone 工作流程？

为了形象介绍keystone概念，我们假设OpenStack为一家新成立的公司，其主要业务是对外提供服务，具体服务请自行脑补^^.
新公司刚开业，为首之际当然是招聘员工。小型创业公司人手不要多，每个服务来一个就够用。经过一番拼搏，最后脱颖而出的有nova，glance，neutron等。公司老板想，人数不多嘛，大家互相见一见就认识了，不如就由nova负责他们的信息认证。
公司人手招够，开始对外服务，作为第一波顾客的我们来到OpenStack柜台。一看有客人到来，负责安全认证的nova赶紧上来问我们是谁，打哪而来，准备去哪。我们刚准备回答，glance楼上大喊一声将nova叫走。老板一看nova业务繁忙也确实忙不过来，是应该考虑再招一个人，这个人工作内容是什么呢，老板开始思考。无论如何，先招待第一波客人是关键，于是老板亲自来招待我们。首先当然是登记个人信息，注册一个账号。信息不用多，名字，密码，邮箱即可。老板想，最好是有这样的一个表让顾客申请，叫做user。

• admin 系统管理员
• test 普通User
• glance,nova OpenStack服务提供模块

此表设计当真简介明了，无差别对待员工和顾客，等等，这样怎么体现我们员工的优越性。得做点什么区分一下我们的员工和顾客。为了方便管理，最好有一张区别身份的表,就叫做tenant吧，nova啊,glance统统塞到service好了，留一个admin是我日后要找的管理员。

突然楼上nova电话打叫保安，好像是有一个顾客偷偷跑到他们后台办公地方。老板一想nova可是公司核心员工，所做的都关乎公司核心机密，怎么好让顾客能让公司里随便出入呢。一定要杜绝这个现象，要在顾客信息里加一栏权限。但是刚才客户表也填好了，也不好让顾客重新填。那就干脆重新弄一张表来记录用户的权限，就叫它role吧

每一个用户可以分配不同的角色， 如这里列出有member和admin。

老板终于解决了用户信息的问题，刚想坐下来喝杯茶休息一下，我们的glance又来了。glance问老板，我找不到nova了，老板想了下nova业务众多，给他分配的办公室也多，找起来是不方便。最好可以记录下每个员工的位置信息，这样新员工入职后，也方便老员工去找。最好是先记录每个员工是干什么的，再记录他们办公在哪，而且这两张表还要分开，因为办公室有可能更改。记录员工工作内容的就叫 service，记录员工工作地方的就叫endpoint好了。

这样一来，终于解决了用户信息，权限的问题，我们也方便去找哪个员工此时在哪。想到此时老板就对要招的新员工的工作有个定位了，他就是管理所有人信息，记录每个人的权限，记录每个员工的职位，以及办公地点。有了上述信息后，他就可以验证每个顾客和员工的身份信息。恩，他就叫keystone.

---

keystone正式加入Openstack后，第一天上班老板交给他一本岗位手册，上面告知它的工作内容是什么。首先他需要认证用户的身份合法并且具有执行相应操作的权限，其次用户在使用服务时，提供服务的人（比如nova）是其本人。最后Openstack各个组件间交互时，也要由他验证身份和权限。除此之外还要维护下表列出的一些表单，主要操作是增删改查。

type	Description	Add	Delete	Update	Get
user	用户，理解为公司内员工	create	delete	update/password-update	list/get
tenant	租户，理解为公司内不同的部门	create	delete	update	list/get
role	角色，理解为公司部门内不同的权限	create	delete		list/get
service	服务，用于注册服务	create	delete		list/get
endpoint	端点，用于记录服务地址	create	delete		list/get
ec2-credentials	信任证书	create	delete		list/get
user-role	绑定用户和权限的关系	add	remove	update	list

---

keystone工作一段时间后，发觉每次验证用户的账号密码，很是麻烦，效率太低，而且用户等待时间也过久，严重印象了服务质量。于是他向老板提出建议，能不能发一个token给验证过的用户，让用户在之后的一段时间里可以使用token作为身份信息，那这样验证起来效率就高很多。老板一听感觉还不错，就答应了。于是就有了这样的验证机制：

• admin_token认证
• 用户密码方式认证
  
  • 本地认证
  • Token认证
  • 外部认证

很快公司又出台了keystone工作流程以为提高keystone服务质量。
服务间访问流程如下：

1. 创建keystone client对象。通过keystone client向keystone服务器发送认证请求，申请用户token。
2. 创建要访问的组件相应的client对象，根据对象找到其endpoint信息
3. client向openstack服务发送http请求，通过auth_token过滤器认证。认证通过后，openstack调用相应的方法处理请求。

至此新员工keystone工作介绍就告一段落了。