OpenStack Keystone架构一:Keystone基础

简介:

一 什么是keystone

keystone是OpenStack的身份服务,暂且可以理解为一个'与权限有关'的组件。


二 为何要有keystone

Keystone项目的主要目的是为访问openstack的各个组件(nova,cinder,glance...)提供一个统一的验证方式,具体的:

openstack是由众多组件构成的一套系统,该系统的功能是对外提供服务,因而我们可以将其定义为一个‘庞大的软件’,没有软件不考虑安全因素,Keystone对于通常的应用场景所不同的是他要解决分布式环境下的统一认证。


三 keystone的功能

openstack是一个SOA架构,理论上各子项目独立提供相关服务,互不依赖,且是分布式的。如nova提供计算服务,glance提供镜像服务等。

实际上所有的组件都依赖keystone(单点的),它集成了三个功能:

(1)管理身份验证(managing authentication):验证用户身份

  (2) 授权(authorization):基于角色role的权限管理

(3)服务目录(catalog of services):提服务目录(ServiceCatalog:包括service和endpoint)服务,类似于UDDI服务的概念,用户(无论是Dashboard, APIClient)都需要访问Keystone获取服务列表,以及每个服务的地址(Openstack中称为Endpoint)


四 keystone概念详解

第一部分

User:使用Openstack组件的客户端可以是人、服务、系统,任何的客户端来访问openstack组件,都需要有一个用户名。

Credentials:是用于确认用户身份的凭证,说白了就是‘信物’,具体可以是:

  1. 用户名和密码

  2. 用户名和API key

  3. 一个 Keystone 分配的身份token

Authentication

  1. 是验证用户身份的过程。Keystone 服务通过检查用户的 Credential 来确定用户的身份。

  2. 最开始,使用用户名/密码或者用户名/API key作为credential。当用户的credential被验证后,Kestone 会给用户分配一个 authentication token 供该用户后续的请求使用。 

  3. Keystone中通过Policy(访问规则)来做到基于用户角色(Role)的访问控制。

Token

  1. 是一个数字字符串,访问资源时需要"亮出"你的令牌。在keystone中主要是引入令牌机制来保护用户对于资源的访问,同时引入PKI(公钥基础实施)对令牌加以保护。

  2. Token包含了在指定范围和有效时间内可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机,在Swift和Glance中一个tenant可以是一些镜像存储,在Network中一个tenant可以是一些网络资源。

Role

  1. 本质就是一堆ACL的集合,用于划分权限

  2. 可以通过给User指定Role,使User获得Role对应的操作权限。

  3. Keystone返回给User的Token包含了Role列表,被访问的Services会判断访问它的User和User提供的Token中所包含的Role,及每个role访问资源或者进行操作的权限。

  4. 系统默认使用管理Role admin和成员Role user(过去的普通用户角色是:_member_) 。

  5. user验证时必须带有Project(Tenant)

Policy

  1. 对于Keystone service来说,Policy就是一个JSON文件,默认是/etc/keystone/policy.json。通过配置这个文件,Keystone实现了对User基于Role的权限管理。

  2. OpenStack对User的验证除了OpenStack的身份验证以外,还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Project(Tenant)中资源的操作权限。

Project(Tenant)

  1. 是一个人、或服务所拥有的资源集合。不同的Project之间资源是隔离的,资源可以设置配额。

  2. 在一个Project(Tenant)中可以包含多个User,每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中,在Cinder创建卷也要指定到某个Project中。

  3. User访问Project的资源前,必须要与该Project关联,并且指定User在Project下的Role,一个assignment(关联)即:Project-User-Role

Service:即Openstack中运行的各个组件服务。

Endpoint

  1. 是一个可以通过网络来访问和定位某个Openstack service的地址,通常是一个URL

  2. 不同的region有不同的endpoint(我们可以通过endpoint的region属性去定义多个region)。

  3. 当Nova需要访问Glance服务去获取image 时,Nova通过访问Keystone拿到Glance的endpoint,然后通过访问该endpoint去获取Glance服务。

  4. Endpoint 分为三类:


    • admin url –> 给admin用户使用,Port:35357

    • internal url –> OpenStack内部服务使用来跟别的服务通信,Port:5000

    • public url –> 互联网用户可以访问的地址,Port:5000

Catalog:用户和服务可以使用使用keystone管理的catalog,定位到其他的服务,catalog一个openstack部署的相关服务的集合,每个服务都有一个或者多个endpoint(即可以访问的url地址),即catalog=services+endpoint。每个endpoint可以分为三种类型:

admin,internal,public,在生产环境中,不同endpoint类型位于不同的网络来为不同的用户使用(提高安全性),比如:

public API:对整个互联网可见,这样客户就可以方便的管理自己的云了。

admin API:应该严格限定只有管理云基础设施的组织内的运营商,才能使用该API

internel API:应该被限定只有那些安装有OpenStack服务的主机,才能使用该API

Service与Endpoint关系介绍:

  1. 在openstack中,每一个service都有三种endpoint. Admin, public, internal(创建完service后需要为其创建API EndPoint. )

  2. Admin是用作管理用途的,如它能够修改user/tenant(project)。

  3. public 是让客户调用的,比如可以部署在外网上让客户可以管理自己的云。

  4. internal是openstack内部调用的。

  5. 三种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放,public通常可以对外网开放,internal通常只能对安装有openstack对服务的机器开放。

 endpoint举例

Regions:

openstack支持多个可扩展的regions,OpenStack的支持可扩展的多个区域。为简单起见,一般使用管理网络ip地址作为所有endpoint类型(三种api)的ip,且所有的endpoint类型(三种api)都使用一个区域,即regionone区。

每个你部署的openstack服务都需要绑定endpoint(存储在keystone中)来提供服一个服务的入口,因而我们第一需要部署的组件就是keystone。

V3新增的概念:

  1. Tenant 重命名为 Project

  2. 添加了 Domain 的概念

  3. 添加了 Group 的概念

第二部分

keystone管理和保存了user信息,管理user相关的tenant,role,group和domain等;用户credential的存放,验证,token管理,下图是各部分关系

第三部分

  • User: has account credentials, is associated with one or more projects or domains

  • Group: a collection of users, is associated with one or more projects or domains

  • Project: unit of ownership in OpenStack, contains one or more users

  • Domain: unit of ownership in OpenStack, contains users, groups and projects

  • Role: a first-class piece of metadata associated with many user-project pairs.

  • Token: identifying credential associated with a user or user and project

  • Extras: bucket of key-value metadata associated with a user-project pair.

  • Rule: describes a set of requirements for performing an action.

注意:user2,user3,user4的关系同user1一样,也可以属于一个或者多个group,此处为了图示简洁,省去了它们的连线

 


五 keystone内包含的组件

keystone包含三类组件:

1 Server

使用RESTful接口(三种api)提供认证和授权服务的集中式server

2 Drivers

指的是被集成到server内的驱动或者服务后端,它们被用来在openstack组件之外的库中访问身份信息(言外之意:mysql并不属于openstack的组件/服务),并可能已经存在于openstack部署的架构中(比如, SQL databases or LDAP servers).

3 Modules

中间件运行在正在使用认证服务的openstack组件的地址空间,这些模块(中间件)拦截服务请求,提取用户的credentials,并且把它们发送给server去认证授权,在openstack中间件与openstack组件直接的整合操作使用Python Web Server Gateway Interface,即wsgi,详见http://www.cnblogs.com/linhaifeng/p/6268615.html


六 keystone与openstack其他服务的关系 

 


七 keystone与其他组件协同工作流程

keystone是用户与云平台交互的第一个服务,一旦认证通过,用户就会使用自己的身份来访问其他的opnestack服务,同样,被访问的openstack服务会去跟keystone再次确认用户(不能只能用户的片面之词)并且通过keystone可以发现其他服务(catalog的原因),keystone的还可以整合其他的用户管理系统,比如LDAP

 


八 keystone工作流程详解

(1) User从Keystone获取令牌以及服务列表;

(2) User访问服务时,亮出自己的令牌。

(3)相关的服务向Keystone求证令牌的合法性。

  1. 用户alice登录keystone系统(password或者token的方式),获取一个临时的token和catalog服务目录(v3版本登录时,如果没有指定scope,project或者domain,获取的临时token没有任何权限,不能查询project或者catalog)。

  2. alice通过临时token获取自己的所有的project列表。

  3. alice选定一个project,然后指定project重新登录,获取一个正式的token,同时获得服务列表的endpoint,用户选定一个endpoint,在HTTP消息头中携带token,然后发送请求(如果用户知道project name或者project id可以直接第3步登录)。

  4. 消息到达endpoint之后,由服务端(nova)的keystone中间件(pipeline中的filter:authtoken)向keystone发送一个验证token的请求。(token类型:uuid需要在keystone验证token,pki类型的token本身是包含用户详细信息的加密串,可以在服务端完成验证)

  5. keystone验证token成功之后,将token对应用户的详细信息,例如:role,username,userid等,返回给服务端(nova)。

  6. 服务端(nova)完成请求,例如:创建虚拟机。

  7. 服务端返回请求结果给alice。




本文转自 OpenStack2015 51CTO博客,原文链接:http://blog.51cto.com/andyliu/1902618,如需转载请自行联系原作者
相关文章
|
8月前
|
数据安全/隐私保护
(二)Open Stack(M)----Keystone安装和配置(下)
(二)Open Stack(M)----Keystone安装和配置(下)
63 0
|
4月前
|
关系型数据库 MySQL 数据库
云计算|OpenStack|社区版OpenStack安装部署文档(三 --- 身份认证服务keystone安装部署---Rocky版)
云计算|OpenStack|社区版OpenStack安装部署文档(三 --- 身份认证服务keystone安装部署---Rocky版)
58 0
|
11月前
|
分布式计算 安全 前端开发
【私有云架构】Openstack VS CloudStack:比较异同
【私有云架构】Openstack VS CloudStack:比较异同
|
11月前
|
存储 关系型数据库 MySQL
【私有云架构】Cloudstack 与 OpenStack:哪个更适合您?
【私有云架构】Cloudstack 与 OpenStack:哪个更适合您?
|
11月前
|
存储 Linux API
「网络架构」OpenStack 脊页网络(Spine Leaf Networking) 介绍
「网络架构」OpenStack 脊页网络(Spine Leaf Networking) 介绍
|
11月前
Openstack架构构建及详解(7)--Cinder组件
Openstack架构构建及详解(7)--Cinder组件
93 0
|
11月前
|
Windows
Openstack架构构建及详解(6)--Dashboard组件
Openstack架构构建及详解(6)--Dashboard组件
145 0
|
4天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
17天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
23 0
|
5天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。