共计 2287 个字符，预计需要花费 6 分钟才能阅读完成。
导读：本博文简要介绍 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 服务质量。
服务间访问流程如下：
- 创建 keystone client 对象。通过 keystone client 向 keystone 服务器发送认证请求，申请用户 token。
- 创建要访问的组件相应的 client 对象，根据对象找到其 endpoint 信息
- client 向 openstack 服务发送 http 请求，通过 auth_token 过滤器认证。认证通过后，openstack 调用相应的方法处理请求。
至此新员工 keystone 工作介绍就告一段落了。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-08/134168.htm
