CEPH客户端权限管理和授权流程

Posted 2023-04-28

参考技术A ceph对客户端的授权是由mon节点进行授权的，mon节点对客户端进行身份认证并颁发秘钥(key，这个key就是/etc/ceph/ceph.client.admin.keyring)。因此为了避免单点，应该设置多个mon节点减少故障和应对认证性能瓶颈。

此时客户端和mon节点上都有key，当客户端向mon节点申请授权时，mon节点会生成一个session key，并用key对这个session key进行加密，然后加密后的session key发送给客户端，客户端使用mon颁发给它的key对加密后的session key进行解密，解密成功后，客户端会使用解密以后的session key向mon节点请求可以通往osd服务的门票，mon节点就会颁发一个使用secret加密的ticket给客户端，这个secret是mon和osd共享的，客户端就可以拿着这个用secret加密后的ticket去请求osd，osd看到ticket，用和mon节点共享的secret解密，解密成功后就认为客户端身份合法，于是客户端就验证通过了

ceph用户权限管理

ceph的认证，请查看ceph对客户端授权流程部分

#ceph用户管理，可以使用ceph auth -h进行命令查询,在任意有ceph客户端的节点执行，type表示种类(mon,osd,mds)，id表示用户id或者名称，以下是增删改查

添加用户：

ceph  auth add type.id 各种权限

ceph auth get-or-create type.id 各种权限

ceph auth get-or-create-key  type.id 各种权限

删除用户：ceph  auth del type.id

修改用户：ceph  caps type.id 各种权限

获取用户权限：ceph  auth get type.id

获取所有用户及其权限列表：ceph  auth list 

ceph的认证

#列出所有用户，

ceph@ceph-node1:~$ ceph auth list

mds.ceph-mgr1

key: AQDFZCZh/Z28CBAA4ZZ97KwsjQZ9WQ+iPfK/7w==

caps: [mds] allow

caps: [mon] allow profile mds

caps: [osd] allow rwx

osd.0

key: AQCCuSNhbNc5HRAADPrQOkORhBD/h9nJ3EVf+Q==

caps: [mgr] allow profile osd

caps: [mon] allow profile osd

caps: [osd] allow *

osd.1

key: AQCbuSNhHaVFORAAd5tG77DQqjG2R1FIOxIbbg==

caps: [mgr] allow profile osd

caps: [mon] allow profile osd

caps: [osd] allow *

#将秘钥保存在auth_list.key文件中

ceph@ceph-node1:~$ ceph auth list -o auth_list.key

#添加用户 有三种方法：均可-o file来指定file保存信息

ceph auth add  创建用户不反回key

ceph auth get-or-create,，后者创建用户，返回用户和key，如果用户已经存在则返回也返回用户和key

ceph auth get-or-create-key，后者创建用户，返回key

ceph@ceph-node1:~$ ceph auth add client.jerry mon "allow rw" osd "allow rwx pool=mypool"

added key for client.jerry

ceph@ceph-node1:~$ ceph auth get-or-create  client.tom mon "allow rw" osd "allow rwx"

[client.tom]

key = AQDU6ixhU9W9FBAA7UEV6KP6qfqAmaRThNIq4A==

ceph@ceph-node1:~$ ceph auth get-or-create-key client.peter mon "allow rw"  osd "allow rwx"

AQBm7CxhMVXjJxAA7aoY+cZcG9aK7qLoU4X2Rw==

#验证用户  ceph auth get  type.id

ceph@ceph-node1:~$ ceph auth get client.jerry

[client.jerry]

key = AQAl6SxhGOaXCRAAVVxDWTDxS8HVN8ZdzqZCkQ==

caps mon = "allow rw"

caps osd = "allow rwx pool=mypool"

exported keyring for client.jerry

#获取单个用户信息

ceph@ceph-node1:~$ ceph auth print-key  client.tom

AQDU6ixhU9W9FBAA7UEV6KP6qfqAmaRThNIq4A==ceph@ceph-node1:~$

#修改用户能力caps，设置新能力会完全覆盖当前的能力，因此如果要保留之前的caps，修改的时候需要加上已有的能力和新的能力

ceph@ceph-node1:~$ ceph auth  get client.jerry

[client.jerry]

key = AQAl6SxhGOaXCRAAVVxDWTDxS8HVN8ZdzqZCkQ==

caps mon = "allow rw"

caps osd = "allow rwx pool=mypool"

exported keyring for client.jerry

ceph@ceph-node1:~$ ceph auth  caps client.jerry mon "allow rw" osd "allow rw pool=mypool" 

updated caps for client.jerry

ceph@ceph-node1:~$ ceph auth  get client.jerry

[client.jerry]

key = AQAl6SxhGOaXCRAAVVxDWTDxS8HVN8ZdzqZCkQ==

caps mon = "allow rw"

caps osd = "allow rw pool=mypool"

exported keyring for client.jerry

#删除用户

ceph@ceph-node1:~$ ceph auth del client.tom

updated

用户的备份与恢复

通过秘钥环进行备份和恢复

#秘钥环：就是存放key，secrets，certificate的keyring file集合文件，可以保存一个或多个的认证信息，每个key都有一个实体名称加权限

备份：

#创建keyring

keyring命名格式： 集群.Type.username.keyring

ceph@ceph-mon1:~$ ceph-authtool --create-keyring ceph.client.user1.keyring

creating ceph.client.user1.keyring

#验证keyring，此时为空

ceph@ceph-mon1:~$ cat ceph.client.user1.keyring

ceph@ceph-mon1:~$ file ceph.client.user1.keyring

ceph.client.user1.keyring: empty

#导出keyring，后面的信息总是会覆盖前面的信息，正常情况，需要每天备份

ceph@ceph-mon1:~$ ceph auth get client.jerry -o  ceph.client.user1.keyring

exported keyring for client.jerry

ceph@ceph-mon1:~$ ceph auth get client.admin -o  ceph.client.user1.keyring

exported keyring for client.admin

如果怕被覆盖，直接追加也可以的，就不会被覆盖了

ceph@ceph-mon1:~$ ceph auth get client.peter >> ceph.client.user1.keyring

也可以先将一个用户导入另外一个用户的key，然后再导出

ceph@ceph-mon1:~$  ceph auth get-or-create-key client.tom mon "allow rw"  osd "allow rwx"

ceph@ceph-mon1:~$ ceph-authtool --create-keyring ceph.client.tom.keyring

creating ceph.client.tom.keyring

ceph@ceph-mon1:~$ ceph-authtool --create-keyring ceph.client.peter.keyring

creating ceph.client.peter.keyring

ceph@ceph-mon1:~$ ceph-authtool --create-keyring ceph.client.bootstrap-mgr.keyring

creating ceph.client.bootstrap-mgr.keyring

ceph@ceph-mon1:~$ ceph auth get client.bootstrap-mgr -o ceph.client.bootstrap-mgr.keyring

exported keyring for client.bootstrap-mgr

ceph@ceph-mon1:~$ ceph auth get client.peter  -o ceph.client.peter.keyring

exported keyring for client.peter

ceph@ceph-mon1:~$ ceph-authtool -l ./ceph.client.peter.keyring

[client.peter]

key = AQBm7CxhMVXjJxAA7aoY+cZcG9aK7qLoU4X2Rw==

caps mon = "allow rw"

caps osd = "allow rwx"

ceph@ceph-mon1:~$ ceph-authtool ./ceph.client.peter.keyring  --import-keyring ./ceph.client.bootstrap-mgr.keyring

importing contents of ./ceph.client.bootstrap-mgr.keyring into ./ceph.client.peter.keyring

ceph@ceph-mon1:~$ ceph auth get client.tom -o ./ceph.client.tom.keyring

exported keyring for client.tom

ceph@ceph-mon1:~$ ceph-authtool ./ceph.client.peter.keyring  --import-keyring ./ceph.client.tom.keyring

importing contents of ./ceph.client.tom.keyring into ./ceph.client.peter.keyring

ceph@ceph-mon1:~$ ceph-authtool -l ./ceph.client.peter.keyring

[client.bootstrap-mgr]

key = AQCnpyNh+uC4IRAAXOaV1+MzQYV/afCY3ty6LQ==

caps mon = "allow profile bootstrap-mgr"

[client.peter]

key = AQBm7CxhMVXjJxAA7aoY+cZcG9aK7qLoU4X2Rw==

caps mon = "allow rw"

caps osd = "allow rwx"

[client.tom]

key = AQDvky9hYFwgHRAAt3KpcdXHVRk7vnNCgPHnqg==

caps mon = "allow rw"

caps osd = "allow rwx"

恢复用户：

#为了演示效果先删除用户peter，再恢复用户peter

ceph@ceph-mon1:~$ ceph auth del client.peter

updated

ceph@ceph-mon1:~$ ceph auth list|grep peter

installed auth entries:

ceph@ceph-mon1:~$ ceph auth import -i ceph.client.user1.keyring

imported keyring

ceph@ceph-mon1:~$ ceph auth list|grep peter

client.peter

installed auth entries:

在 keycloak 和 spring rest api 中管理用户权限

【中文标题】在 keycloak 和 spring rest api 中管理用户权限

【英文标题】：Managing user permissions in keycloak and spring rest api

【发布时间】：2018-11-13 06:56:34

【问题描述】：

TL;DR

目的：管理api权限： OIDC 授权直接授权流程 用户联合和身份验证源：LDAP 权限存储：旧数据库 客户端管理和身份验证：Keycloak 问题：在 Keycloak 和 rest api 上管理用户权限的最佳做法是什么？

上下文

我们正在实现一个带有 spring 的 rest API，供移动应用程序和 SPA 使用。我们的用户帐户、权限、规则……以及所有数据都存储在一个自定义数据库中，供不同的单体应用程序使用。为了保护我们的 API，我们决定使用 Keycloak。

keycloak 服务器配置了用于用户联合的现有 LDAP 和用于移动客户端应用程序的“Direct grand flow”。对于第一个用例（身份验证），一切正常。

现在我们必须按如下方式管理用户权限：

客户端应用程序应该知道用户显示/隐藏功能的权限

api 应该能够验证用户使用不同端点的权限

用户权限是基于数据库中的一些规则，经常变化

据我了解，keycloak 可以使用硬编码或基于用户的策略来处理授权和细粒度权限，但不能以原生方式插入不同的授权源。因此，我想到了使用 Keycloak SPI 构建自定义角色映射器，从我将开发的自定义 api 中检索用户权限，然后将它们映射到访问令牌。

因此，我的访问令牌应如下所示：

"resource_access": 
    “My-client”: 
      “permissions”: [
        “Show-products”,
        “Buy-something”,
        “Display-prices”
      ]
    
  ,
  "username": “myUser”

然后移动应用程序应该能够根据令牌知道用户权限，并且我的无状态服务器端（API）应该能够在每次调用时访问用户权限以使用 spring 注释检查它们：

@PreAuthorize("hasRole('Show-products')")

问题

在第一次尝试后，我的解决方案似乎运行良好，但我仍然对这个选择存在一些安全问题，因为它不符合 keycloak 标准，并且在 keycloak 映射器中包含对不同后端的休息调用。

所以我想知道：

将用户权限放在访问令牌声明上是否安全？ 如何保护对外部系统的 keycloak 访问（休息调用）以 检索权限？ 我是否应该依靠令牌声明来验证每个用户的权限？ 在我的资源服务器中请求？ 是否有任何其他干净的解决方案/最佳实践来处理用户 在 keycloak 中来自外部源的权限？

免费信息

我正在使用：

Springboot 1.5.13.RELEASE Keycloak-adapter-bom 3.4.3.Final 独立 keycloak 服务器 3.4.3.Final

【问题讨论】：

嗨@wadi3，你实现了吗？

【参考方案1】：

关于您的问题：

- 将用户权限放在访问令牌声明上是否安全？

是的，功能可以（并且应该）在访问令牌上，并且您可以在业务层中做出一些决定（基于角色/访问声明）。但是请记住，令牌仅是 base 64 编码，并且可以被其他人复制并查看，因此它不应该包含秘密或特别机密的信息，通常你会在那里放置足够的关于用户的信息，以及它的一些当前权限/功能/声明。

如何保护 keycloak 访问外部系统（休息调用）以检索权限？

这取决于它是否需要从您的网络外部访问。如果没有，您可以让它不受保护（并且从外部不可用/或仅可用于某些特定 IP）。如果它可以从外部获得/或者您想用 keycloack 保护它，您可以拥有“机密”或“仅限承载”类型的客户端。我建议您研究 CORS 和令牌共享，这样您就可以将您已经创建的“访问令牌”用于其他端点，而无需再次进行身份验证。

我应该依靠令牌声明来验证资源服务器中每个请求的用户权限吗？

不完全确定您的意思。在 keycloak 中，资源服务器没有像典型的 oAuth2 舞蹈那样进行额外的资源授权（除非您的策略执行器被激活，但我相信您没有采用这种方法，而是使用映射器 SPI @auth 服务器来获得正确的角色?)

在 oAuth2 中，“资源服务器”有 2 个职责：1-提供资源和 2-执行额外的授权步骤。在 keycloak 世界中，这两个步骤由不同的参与者完成。第 1 步由您的应用程序完成，第 2 步仅在 keycloak 也激活策略执行时完成（这意味着 Keycloak 是身份验证服务器，从 oAuth2 角度来看也是“资源服务器”的一部分）

现在回到您的问题，如果资源服务器只是指您的应用程序提供内容，那么是的，您可以在那里使用声明，请记住声明（以及整个访问令牌）是由生成并数字签名的身份验证服务器，因此您可以在您的应用中毫无问题地使用这些声明（否则也不知道该怎么做）。

是否有任何其他干净的解决方案/最佳实践可以在 keycloak 中处理来自外部源的用户权限？

很难说，你可能已经注意到了；针对您的特定用例的网络文档非常有限；所以那里没有很多最佳实践的工作，你唯一真正的选择是使用带有自定义策略 SPI 的策略，这会带来其他挑战。我会说你的解决方案很好。

最好的问候。

【讨论】：

您能否准确说明功能、声明和权限之间的区别？ AFAIK 权限在 Keycloak 中非常具体，它们似乎需要authorization request。但是，我不确定应该在哪里设置能力（全局范围？）和权限之间的限制，因此我想澄清这一点。