1 keystone middleware

1.1 工作流程

middleware在客户端和服务端之间，会拦截客户端请求并判断请求身份是否是正确合法的，若是，则继续将请求发给其他middleware或app

具体看，干了这些事 1将请求里的auth header去除，防止伪造认证 2从请求http header生成auth token 3验证token：若合法则在请求添加表示验证合法的header，然后将请求传下去，若不合法则reject请求或继续吧请求发给service，只是在headers里添加认证未通过的信息

 

1.2 模式

middleware有两种模式，一种是请求，一种是委托模式

请求模式：即上一段所述

委托模式：将认证过程放到service里，由service进行认证而不是keystone middleware

1.3 配置

可以配到其他service的paste配置文件的pipeline

对于拥有独立paste配置文件的service，在paste ini配的keystone middleware也可在service主配置文件进行配置。相比之下，优先生效的是paste ini，所以如果想让service主配置文件生效，必须在paste ini里删除相关配置

 

若在服务主配置文件中的[keystone_auth]下配了auth_type, 服务认证时会建立与keystone的连接，如果有多region，还需配region_name

 

1.4 性能

若每个request都认证会降低服务响应性能，keystone middleware支持缓存token（在内存中）以缓解此问题，问题是如果token过期但仍在缓存中，token可能会继续正常工作

 

token缓存配置项

memcached_servers: 缓存token的server。若swift使用memcachedring，该配置项无效

token_cached_time: token缓存时间

 

注意 若使用memcached，则需要安装python-memcached和pycrypto，这两个可能没在requirements.txt列出

 

安全配置项

memcache_security_strategy 可选配置 为MAC或ENCRYPT，否则报错，前者会认证token，后者认证后还会加密token

memcache_secret_key 可选 当memcache_security_strategy配置时，本配置必须配置否则报错

1.4 原理

middleware尝试在请求头里找X-Auth-Token或X-Storage-Token。若请求没带X-Auth-Token且中间件不是委托模式，则返回Unauthorized

认证结果用header X-Identity-Status表示，若认证通过则值为confirmed，若为委托模式且未认证通过，则值为invalid

如果请求头还有X-Service-Token，则当X-Auth-Token认证通过后还会校验X-Service-Token，如果通过，会在请求头设X-Service-Identity-Status为confirmed

当X-Service-Token未通过认证时，若delay_auth_decision为True，则X-Service-Identity-Status被设为invalid且不再给请求头添加选项，若为False，则直接返回HTTPUnauthorized

2 audit middleware

来自于keystone middleware，类似于keystone middleware，可捕获请求，处理然后继续

 

2.1 安装与使用

需要安装oslo.messaging,如果没装，audit吧audit结果记日志里

audit可在每个服务的api-paste.ini配置

audit应在keystone的authtoken后，以便利用环境变量

2.2 配置

配置audit middleware需要在服务api-paste.ini配置api_audit_map.conf，如上图

audit middleware可配置自己的notification driver，即可配不同的driver，如果需要和服务不同的driver，也可以手动配成其他，若配成messaging，其他transport的配置在组件中有专门的option可配，如“oslo_messaging_rabbit”

3 keystone架构

身份：包括用户名和组名，归属于domain，即user和group在domain不可重名，但在不同domain可以重名

资源：project 类似于user和group，domain内名称 不重复； domain 可近似看作user，group，project的容器

project可包含user和group，domain可包含project，user，group

3.1 鉴权方法（polocy）

rule认证 一般从用户元数据的'extras'里获取认证信息，然后用这信息去鉴权，比如给用户添加一个role意味着给用户元数据添加一个role

获取token可提供user名称或user id，若提供username，则还需要提供domain信息，因为user在不同domain间可重名，但id跨domain也不重复，所以如果提供user id，则不需要提供domain信息

3.2 作用域

比如token有作用范围，比如项目内token，域内token，系统token等

4 keystone

4.1 终端用户

可创建app凭据来通过keystone鉴权，用户可将角色委托给project，然后对app授权凭据约束，在凭据加入project信息，从而使用app凭据即可通过keystone认证，这可以避免认证显式传入密码

创建app凭证 openstack application credential create monitoring 此命令将创一个名为monitoring的app凭证，凭证的role根据当前user作用域创建，所以凭证的role和当前user对应的role相同，创建的凭证会生成一个密钥，也可以提供自定义密钥

给app创凭据提供的role是当前user的role列表的子集，如果删了app里加入的role，app凭据将可能无法正常通过认证

 

使用app认证的话，可在service配置文件配置，修改auth_type即可

app凭证rotate

app凭证相比于密码认证，减少了服务downtime，改密码会有一会downtime，app凭证可以rotate避免downtime，先创新的app凭证，再改配置里的app凭证id和secret，等service ok了，删除就app凭证，注意app凭证名称不可重复

4.2 系统管理员

4.2.1 概念

创建用户 openstack user create --password-prompt --email xxx

创project openstack project create testproject --domain testdomain

创domain openstack --os-identity-api-version=3 domain create testdomain

创role openstack role create testrole

将project和role分配给user openstack role add --project xxx --user user_name role_name

role通过policy.json管理，默认只有admiin role，所以默认情况可访问没有admin限制的project

组是user的集合，组可简化role授权管理，只需给group填一次role，group所有user都可受到该role影响

4.2.2 bootstrap keystone

keystone部署好了初始化需要新增第一个用户，role，project，用keystone-manage实现

4.2.3 管理project，user，role

user是project的成员，user可以是一个或几个project的成员，role定义了user可以干啥

删除user前，需要先删除user在其主project中于project的关系，再删user

role有继承role，类似于类的继承，如member是基role，派生role有compute-role，network-role，则给user-project分配了compute-role，同时也拥有了member role的权限