一、Keystone学习笔记
1、背景
1.1 背景简述
随着云计算的愈发火热，参与到其中的人越来越多，不管是*部门还是世界的各家大小公司，纷纷参与到了这股浪潮中。而用户作为消费者选择云平台，主要是因为云计算相对于传统的方式可以带给自己费用上的节省，能获得快捷服务的体验，越来越多的用户选择云产品，意味着将会有越来越多的数据存储在“云端“，安全性如何保证无疑会成为为摆在云服务提供商以及终端用户面前一个非常现实的问题。
对于任何一个任何的软件来说，安全都是一个无法忽略的问题，没有哪个软件不考虑安全性因素，当然也没有哪一款软件可以解决所有的安全性问题。那么对于提供云基础架构服务的openstack来说，安全性的设计是一个重要的考虑点。
1.2 因素
1.2.1 数据安全
云服务提供商需要保证用户的数据不被窃取或是丢失，强加密及密钥管理是云计算系统用于保护数据安全的一种核心机制。加密的数据虽然不能保证不丢失，但对于无法获取明文的数据来输，危害相对就降低了很多；密钥管理则提供了对保护资源的访问控制。在keystone中主要是引入令牌机制来保护用户对于资源的访问，同时引入PKI（公钥基础实施）对令牌加以保护。
1.2.2 身份和访问管理安全
有效的身份和访问控制是云平台必不可少的一环，云计算中需要合理定义系统管理人员的控制边界，以防来自内部的攻击造成的危害。Keystone中通过Policy（访问规则）来做到基于用户角色的访问控制。
1.2.3 虚拟化安全
云计算离不开虚拟化，虚拟化技术在计算能力、网络、内存等方面的应用扩展了多租户下的云服务，那么如何有效的隔离众多的虚拟机，以防发生数据污染，不同敏感度和安全性要求的虚拟机如何共存等问题，对于虚拟化安全提出了很高的要求。
1.2.4 基础设施安全
基础设施安全包括服务器、存储、网络等核心的IT基础设施的安全，对于不同的基础设施引进不同安全控制机制，比如服务器层的安全控制机制：强认证、安全事件日志等，以此来提高基础设施的安全性。
2. keystone的基础架构
Keystone系统架构 
2.1 Keystone API
Keystone API与Openstack其他服务的API类似，也是基于ReSTFul HTTP实现的。Keystone API划分为Admin API和Public API,其中Public API不仅实现获取版本以及相应扩展信息的操作，同时包括获取Token以及Token租户信息的操作；Admin API主要提供服务开发者使用，不仅可以完成Public API的操作，同时对User、Tenant、Role和Service Endpoint进行管理操作。
2.2 Router
Keystone Router主要实现上层API和底层服务的映射和转换功能，包括四种Router类型。
（1） AdminRouter
负责将Admin API请求映射为相应的行为操作并转发至底层相应的服务执行；
（2） PublicRouter
与AdminRouter类似；
（3） PublicVersionRouter
对系统版本的请求API进行映射操作；
（4） AdminVersionRouter
与PublicVersionRouter类似。
2.3 Service
Keystone Service接收上层不同Router发来的操作请求，并根据不同后端驱动完成相应操作，主要包括四种类型；
（1） Identity Service
Identity Service提供认证凭证的验证服务，并依靠相应的后端驱动来获取User、Tenant、Role和Metadata等相关数据；Keystone支持Sql.Identity、kvs.Identity、pam.Identity、ldap.Identity四种后端驱动，系统默认的是Sql.Identity；
（2） Token Service
Token Service提供令牌相关的管理操作，当前的Keystone对于Token Service
支持Sql.Token、Memcache.Token、Kvs.Token三种后端驱动，系统默认的是
Kvs.Token；
（3） Catalog Service
Catalog Service提供service和Endpoint相关的管理操作，目前支持三种后端驱动：Sql.Catalog、Kvs.Catalog、Templated.TemplatedCatalog三种后端驱动，系统默认的是Templated.TemplatedCatalog；
（4） Policy Service
Policy Service提供一个基于规则的授权驱动，当前支持一种简单的规则匹配，即给定一个匹配列表，来确认凭证中是否包含相应的规则，并根据匹配情况决定最后的授权。
2.4 Backend Driver
Backend Driver具有多种类型，不同的Service选择不同的Backend Driver。
3. 相关概念
Keystone主要有两个功能：用户管理和服务目录管理；
3.1 User
User即用户，他们代表可以通过keystone进行访问的人或程序。Users通过认证信息（credentials，如密码、API Keys等）进行验证。
3.2 Tenant
Tenant即租户，它是各个服务中的一些可以访问的资源集合。例如，在Nova中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。
3.3 Role
Role即角色，Roles代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role规定的权限。
3.4 Service
Service即服务，如Nova、Glance、Swift。根据前三个概念（User，Tenant和Role）一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时，他必须知道这个service是否存在以及如何访问这个service，这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role，实际上也是可以绑定到某个service的。例如，当swift需要一个管理员权限的访问进行对象创建时，对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标，我们应该创建两个独立的管理员role，一个绑定到swift，另一个绑定到nova，从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。
3.5 Endpoint
Endpoint，翻译为“端点”，我们可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。因此，在keystone中包含一个endpoint模板（endpoint template，在安装keystone的时候我们可以在conf文件夹下看到这个文件），这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表，列表中的每个URL都对应一个服务实例的访问地址，并且具有public、private和admin这三种权限。public url可以被全局访问（如http://compute.example.com），private url只能被局域网访问（如http://compute.example.local），admin url被从常规的访问中分离。
4、 用户管理
Keystone身份验证流程 
5、 服务管理
openstack service create --name keystone --description="OpenStack Identity" identityopenstack endpoint create --publicurl http://controller:5000/v2.0 --internalurl http://controller:5000/v2.0 --adminurl http://controller:35357/v2.0 --region RegionOne identity6、 连接openstack服务到keystone
主要配置paste.ini文件，使keystone可以和其他服务进行互动；
步骤如下
6.1 设置证书
6.2 设置租户、用户、角色
6.3 设置服务
6.4 设置auth_token中间件