文章目录

  • 简单说说keystone
  • 深入了解keystone
  • user
  • credentials
  • authentication
  • token
  • project
  • service
  • endpoint
  • role
  • keystone基本架构


简单说说keystone

keystone是OpenStack的核心组件之一,为OpenStack大家族中的其他组件提供统一的身份认证服务,包括身份认证、令牌发放和校验服务列表、定义用户权限等。OpenStack中所有服务的授权和认证都需要经过keystone,因此keystone是OpenStack中第一个需要安装的核心组件。

keystone的具体功能如下:

  • 管理用户及其权限
  • 维护各种服务的endpoint
  • 认证和鉴权

深入了解keystone

想要清楚认识keystone,一定要关注这些概念

user

OpenStack的用户其实与Linux的用户非常类似,理解的时候也可以通过类比来理解。
我们都知道root用户,OpenStack中的root叫做admin,admin就相当于OpenStack中的root用户一样,有着最高的权限,可以在系统中为所欲为,我们部署OpenStack服务时总是要先执行这一步:

source openrc

其实openrc文件里的内容就是这样的:

export OS_USERNAME=admin
export OS_PASSWORD=admin
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_AUTH_URL=http://controller1:35357/v3
export OS_IDENTITY_API_VERSION=3

执行这一步就是为了以admin用户的身份在命令行界面登录OpenStack平台,之后我们可以随便在OpenStack中创建用户、服务、项目、endpoint等,就是因为我们有最高权限。

说完了root,再来说说Linux的系统用户。我们在部署绝大多数OpenStack服务时都是按照一定顺序的:

  • 在数据库创建对应的库和用户
  • 在OpenStack平台上创建对应的用户,服务,endpoint
  • 安装对应的软件包,按需修改配置文件
  • 同步数据库的内容
  • 启动服务

在Linux中安装一个软件一般也会在系统中创建一个同名或类似名称的系统用户,这是因为在Linux中一切皆文件,一个软件本质就是很多个文件,那么它们必然需要一个用户来读、写和执行,我们不能允许软件调用root用户来帮它做这些,那么软件只能自己创建一个自己的用户了,这样谁都不会吵架。同样的思想也适用于OpenStack,于是就有了这些服务的用户。

最后就是普通用户了,云计算要求多租户架构,这么多租户访问我们的OpenStack平台想要使用服务,那么他们首先要一人有一个用户,然后才能登陆进来选择服务。
这么想的话是不是一切都很清楚了。

credentials

还是类比Linux,用户有用户密码,有密钥,系统用户没有自己的密码但是也有它们的验证方式,其实这就是一个用户向系统证明我是谁的凭证,相信大家在生活中都不陌生。
而在OpenStack中,这个凭证就叫做证书。
想像一下这样一个场景,我要回家,在小区门口我被门卫拦了下来,我需要向其证明我是这个小区的业主,我可以刷脸、可以报我的名字、可以出示我的房产证,等等方式。
OpenStack的证书也有多种形式,可以是用户名、Token、API key或其他高级方式。

authentication

继续类比Linux,我们都做过密钥登录的设置,一开始Linux默认使用密码登录,当我们修改并生效了配置文件远程登录就不再能使用密码,而是必须使用密钥,在这里密码和密钥就是认证方式。
一般来说OpenStack的认证方式是用户在访问OpenStack时首先向keystone提交用户名和密码两个证书,keystone验证通过后会给用户签发一个token。

token

token是由数字和字母组成的字符串。当用户认证成功后keystone会生成一个token分配给用户,token就是用户的令牌,就好像员工的工牌。
我们再想像这样一个场景,我的公司有很多组,我是一个运维组的组员,现在我戴着工牌在公司里乱走,公司的每一间办公室都需要刷工牌进入,我走到开发组的门口,刷了一下工牌,提示我不能进,我又走到CEO办公室门前,刷了一下工牌,还是不能进,终于我走到运维组门前,刷了一下工牌,进去了。

这个场景就与OpenStack验证模式非常类似,用户登录后验证并没有结束,相反刚刚开始。keystone发放的这个token会作为用户访问其他服务的证书,,每当用户想要访问一个服务,就需要刷一下工牌,然后交给keystone验证一下用户是否有权使用这个服务。
注意token的有效期默认是24小时。

project

在OpenStack中,项目和租户是一个概念。项目指公有云里以企业或组织名义建立的用户,也可以是一些用户的集合,项目就是管理用户的单元。
比如一个企业想要租十台服务器,来到了我们平台,于是我们就为其创建一个项目,之后他们可以自由将自己的员工用户添加到该项目中,并给与不同的权限,这些用户可以自由管理他们租的这十台服务器。

由此可以看出重要的一点:
资源属于项目,而不属于用户,用户只有挂在项目里才能访问项目资源!
而且一个用户可以属于多个项目。

service

对此我们并不陌生,不管是在Linux还是在OpenStack中,我们都部署过很多服务,要关注的是每个服务都会提供若干个endpoint,用户通过这些endpoint访问资源执行操作。

endpoint

endpoint是一个可以通过网络访问的地址,通常是一个URL,也就是网址。每个部署在OpenStack上的服务都通过endpoint提供自己的API,用户可以去访问这些网址来使用服务。
那么联想到刚才token上所说的认证过程,网址就在这里,keystone想要确保有权限的用户才能访问服务的话,就必须将这些endpoint管理起来,为它们挡住没有权限的用户的访问。

role

还是类比linux,Linux有三种权限:读,写,执行。在确定某个用户对某个文件的权限时只需要确认用户有这三个中的哪几个权限。相比Linux,OpenStack中用户可以做的操作更多,但是思想还是一样的。
keystone可以定义角色,默认的角色只有这两种:

openstack role list
	+----------------------------------+----------+
	| ID                               | Name     |
	+----------------------------------+----------+
	| 4f55c7680f1944e683dd9e2f95a89675 | admin    |
	| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
	+----------------------------------+----------+

admin是管理员,member是租户。

角色中的admin和用户中的admin意义不同,角色admin是管理员,它更类似一个权限,就好像Windows中有些操作必须有管理员权限才能做一样。OpenStack默认配置只区分admin和非admin角色,想要创建新的角色可以通过:

openstack role add

这个命令来完成,但是新创建的角色没有任何权限,想要赋予其任何权限需要编辑policy.json文件,这个文件决定了角色对服务持有什么样的权限。每个服务都有这样一个文件,其中编辑了每个角色对本服务的权限。

创建好我们需要的角色之后,就可以通过OpenStack的web页面为用户分配角色,而且一个用户可以获得多个角色,之后用户就能得到角色的权限了。

keystone基本架构

keystone可以分为4部分:

  1. token:生成和管理token
  2. catalog:存储和管理其他服务和其endpoint
  3. identity:管理租户、用户、角色的信息并负责验证
  4. policy:管理访问资源

现在我们来做一个简单的操作

source openrc 
openstack image list
+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 448c0e06-3307-4691-ac76-2409d7f7b09e | cirros | active |
+--------------------------------------+--------+--------+

并且来分析在其中keystone起到了什么作用。

  1. admin用户请求登录,并且向keystone提供用户名和密码
  2. keystone经过认证,通过了admin的登录请求,并授予其一个token
  3. admin在成功登录OpenStack平台后想要查看image,于是访问glance的endpoint
  4. glance向keystone询问admin身份是否有效
  5. glance查看/etc/glance/policy.json判断admin是否有权限查看image
  6. 判断通过,glance向admin返回image列表

不只是查看image,用户在OpenStack中的每次操作都遵循这种流程,区别只在于调用的服务不同。