访问权限冲突定义_一文读懂F5 REST API的细粒度角色访问控制

↑ 点击上方“小咩社长”关注我

阅读提示｜本文大概4718字 阅读需要12分钟

写在前面：

前两天一个保险的客户联系我说有个需求，问通过调用F5 REST API可否实现？：

需要把F5负载均衡上面的配置相关的信息，包含每个VirtualServer(业务)相关联的Pool、会话保持、iRules、SSL Profile中的SSL证书过期时间等配置信息输出给CMDB部门做统一的配置维护、SSL证书过期时间管理

F5只给CMDB服务端调用F5 REST API查看指定资源对象的配置的权限，不允许创建、修改、删除资源对象等高风险操作

在聊F5 RESTful API的细粒度角色访问控制之前，先搬运一下简书上AWeiLoveAndroid写的一篇关于RESTful API的介绍，内容好，简单罗列下关键的几个资源对象的介绍？

什么是REST API：

要理解RESTful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。

资源(Resources)ier，统一资源标识符所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI(统一资源标识符)指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。

URI：Uniform Resource Identifier，统一资源标识符

URL：Uniform Resource Location统一资源定位符

表现层(Representation)

"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"(Representation)。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

状态转化(State Transfer)：

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"(State Transfer)。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源(也可以用于更新资源)，PUT用来更新资源，DELETE用来删除资源。

综合上面的解释，我们总结一下什么是RESTful架构：

(1)每一个URI代表一种资源；

(2)客户端和服务器之间，传递这种资源的某种表现层；

(3)客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

由于篇幅有限，本篇文章将着重介绍通过F5 RESTful API访问资源对象的资源划分和的用户访问权限控制部分。为了更直观的演示，通过使用浏览器访问F5 RESTful API 接口获取VirtualServer相关的配置信息及SSL证书信息。生产上建议使用F5 SDK的方式。

需求一：

通过F5 RESTful API去查询每个VirtualServer(业务)相关联的Pool、会话保持、iRules、SSL Profile中的SSL证书过期时间等配置信息

上下滑动查看F5 RESTful API获取信息，如图所示，串联起了一个VirtualServer相关的配置信息：对外发布的业务IP地址、关联的各种profile信息及SSL证书信息(Common Name、ExpirationDate)。

上下滚动查看更多

需求二：

CMDB服务端调用F5 REST API查看指定资源对象的配置的权限，不允许创建、修改、删除资源对象等高风险操作

F5的基于角色的访问控制(RBAC)机制允许 BIG-IP 管理员为用户分配适当的访问权限。例如，对于operator角色，只允许用户启用或禁用node和池Pool member，对于guest角色，只允许用户查看配置信息，不允许客户增删查改设备配置信息。

为了满足用户需求这里我们新建一个foo用户，用户角色为testRole，访问方式和资源在testResourceGroup中定义，然后从testRole中引用，不允许执行其他操作，如PATCH、DELETE等操作，只允许“GET”，并且只给foo用户访问/mgmt/tm/ltm/virtual/和/mgmt/tm/sys/的权限

使用curl命令创建用户foo，密码是Foo,描述是Foo Bar角色是所有分区的guest

PS*需要注意的是当角色与细粒度 RBAC 之间存在访问权限冲突时，选择更严格的授权

curl -sku admin: https:///mgmt/tm/auth/user -X POST -H "Content-Type: application/json" \

-d '{"name":"foo", "password":"foo", "description":"Foo Bar", "partitionAccess":[ { "name":"all-partitions", "role":"guest"} ] }'

在 v13.1.0中，一个新创建的本地用户被自动添加到 iControl _ REST _ api _ user 中，它不需要任何设置就可以访问 iControl REST。为了避免分配多个权限，需要从/mgmt/shared/authz/roles/iControl_REST _ api_user中删除用户引用。

从/mgmt/shared/authz/roles/iControl_REST_api_user 获取数据并将其重定向到一个文件

curl -sku admin: https:///mgmt/shared/authz/roles/iControl_REST_API_User \ | python -m json.tool > file

编辑该文件。该文件包含一行用户“ foo” ，如下所示，删除包括开头和结尾大括号加逗号的行,保存文件

"name": "iControl_REST_API_User", "userReferences": [ {"link": "https://localhost/mgmt/shared/authz/users/foo" }, ....

通过将文件放置到端点来覆盖当前数据

curl -sku admin: https:///mgmt/shared/authz/roles/iControl_REST_API_User -X PUT -d@file

创建一个自定义资源组

资源组由一组资源和方法组成。在本例中，资源组名为“ testResourceGroup” ，它允许角色对资源/mgmt/tm/ltm/和/mgmt/tm/sys/执行 GET 请求。“ testResourceGroup”稍后将在定制角色中使用。

curl -sku admin: https:///mgmt/shared/authz/resource-groups -X POST -H "Content-Type: application/json" \ -d '{"name":"testResourceGroup", "resources":[ {"restMethod":"GET", "resourceMask":"/mgmt/tm/ltm/**" }, {"restMethod":"GET", "resourceMask":"esourceMask":"/mgmt/tm/sys/**" } ]}'

返回的JSON对象如下所示：

{"id": "fe7a1ebc-3e61-30aa-8a5d-c7721f7c6ce2", "name": "testResourceGroup", "resources": [ {"resourceMask": "/mgmt/tm/ltm/**", "restMethod": "GET"},{"resourceMask":"/mgmt/tm/sys/**", "restMethod": "GET" } ], "generation": 1, "lastUpdateMicros": 1521682571723849, "kind": "shared:authz:resource-groups:roleresourcegroupstate", "selfLink": "https://localhost/mgmt/shared/authz/resource-groups/fe7a1ebc-3e61-30aa-8a5d-c7721f7c6ce2"}

请注意，资源组条目是由“ id”而不是“ name”键控的。

用用户“ foo”和资源组“ testResourceGroup”创建角色“ testRole”。这使用户成为角色“ testRole”的成员

curl -sku admin:https:///mgmt/shared/authz/roles -X POST -H "Content-Type: application/json" \ -d '{"name":"testRole", "userReferences":[ {"link":"https://localhost/mgmt/shared/authz/users/foo"} ], "resourceGroupReferences":[{"link":"https://localhost/mgmt/shared/authz/resource-groups/fe7a1ebc-3e61-30aa-8a5d-c7721f7c6ce2"}]}'

下面的 F5 RESTful 调用演示了结果

curl-D-skufoo:Foohttps:///mgmt/tm/ltm/virtual/virtual|grepHTTPHTTP/1.1 200 OKcurl-D-skufoo:Foohttps:///mgmt/tm/sys|grepHTTPHTTP/1.1 200 OKcurl-D-skufoo:Foohttps:///mgmt/tm/ltm/virtual-XPATCH-d'{"test":"test"}'|grepHTTPHTTP/1.1401F5AuthorizationRequired

原文连接

/s/articles/icontrol-rest-fine-grained-role-based-access-control-30773

- EOF -

推荐阅读点击标题可跳转

1、【更新】F5 接入安全策略限制

2、【玩转k8s系列之入门篇】搭建k8s基础环境

3、浅谈AppleCare+ 延保政策发布！裸奔党的福音

觉得本文对你有帮助，请分享给更多人

扫码关注「小咩社长」

如果觉得《访问权限冲突定义_一文读懂F5 REST API的细粒度角色访问控制》对你有帮助，请点赞、收藏，并留下你的观点哦！