Galaxy NG 中的 RBAC¶

基础¶

权限¶

GalaxyNG 中的每个对象默认至少创建四个权限：- 添加：授予添加该类对象的能力 - 删除：授予删除该类对象的能力 - 查看：授予查看该类对象的能力 - 更新：授予更新该类对象的能力

还可以为对象创建其他自定义权限。例如，namespace 对象具有我们定义的“上传到命名空间”自定义权限，允许用户将集合上传到特定命名空间。

角色¶

角色是可以分配给组的权限组。GalaxyNG 附带一组预定义的角色，但是用户也可以根据需要定义自己的角色，其中包含任何一组权限。

角色分配¶

角色可以在两个级别分配：模型（全局）和对象。

模型角色是全局的，并授予对系统中给定类的所有对象的权限。例如，授予模型级别的 namespace_owner 角色将允许用户更新系统中的所有命名空间。

对象级别角色用于特定对象。它们允许系统中的用户获得特定对象的权限。例如，向用户授予命名空间foo上的 namespace_owner 角色将允许用户更新命名空间foo，而不是其他命名空间。

角色可以通过两种方式之一分配：在每个用户级别或每个组级别。目前，仅支持组角色。为了授予权限，管理员必须创建一个具有所需角色集的组，然后将需要这些权限的用户添加到该组。例如，管理员可以创建一个“内容管理员”组，该组具有创建和更新新集合、命名空间和 EE 的全局角色。这将允许管理员通过将新用户添加到“内容管理员”组来授予他们管理内容所需的所有权限。

未使用的权限¶

并非所有权限都强制执行。集合和执行环境等内容类型不需要任何特殊权限即可查看，因此不会强制执行集合和 EE 的查看权限。

超级用户¶

拥有 Django 超级用户权限的用户自动拥有系统中的所有权限，并且可以执行应用程序允许的任何操作。

技术细节¶

为了使所有这些都能正常工作，我们使用了两个外部库，它们为现有的 Django RBAC 系统添加了一些附加功能。

Pulp RBAC¶

Pulp RBAC 允许我们创建将 django 权限集组合在一起的角色，并将其全局或针对特定对象分配给用户和组。

DRF 访问策略¶

DRF 访问策略 (https://rsinger86.github.io/drf-access-policy/) 允许我们创建 DRF 权限类，这些类读取 JSON 或 Python 对象并返回用户是否具有执行某些操作的权限。DRF 访问策略语句如下所示

[
        {
            "action": ["list", "retrieve"],
            "principal": "authenticated",
            "effect": "allow",
        },
        {
            "action": "destroy",
            "principal": "*",
            "effect": "deny",
        },
        {
            "action": "create",
            "principal": "authenticated",
            "effect": "allow",
            "condition": "has_model_perms:galaxy.add_namespace"
        },
        {
            "action": "update",
            "principal": "authenticated",
            "effect": "allow",
            "condition": "has_model_or_obj_perms:galaxy.change_namespace"
        },
    ]

此访问策略允许已认证的用户查看内容，拥有galaxy.add_namespace权限的用户创建新的命名空间，拥有change_namespace权限的用户更新命名空间，并拒绝所有人删除命名空间。

我们的访问策略定义可以在galaxy_ng/galaxy_ng/app/access_control/statements中找到。

请注意，我们从未在任何访问策略中直接引用角色。相反，权限是根据用户拥有的权限授予的。通过查找用户的角色并验证他们是否拥有执行某些操作所需权限集的角色来检查这些权限。

加载 DRF 访问策略¶

访问策略在galaxy_ng/galaxy_ng/app/access_control/access_policy.py中加载。目前有两组访问策略，一组用于洞察模式，它禁用洞察模式不允许的功能；另一组用于独立模式，它启用用户管理和集合同步等功能。加载应用程序时，访问策略基类会检查应用程序是否在洞察模式或独立模式下运行，并加载相应的访问策略。

Pulp 访问策略¶

Pulp API 端点的访问策略可以通过设置与 Pulp viewset 具有相同 URL 模式的访问策略来定义在我们的访问策略中。此访问策略将应用于组角色 API。

'groups/roles': [
    {
        "action": ["list", "retrieve"],
        "principal": "authenticated",
        "effect": "allow",
        "condition": "has_model_perms:galaxy.view_group"
    },
    {
        "action": "create",
        "principal": "authenticated",
        "effect": "allow",
        "condition": "has_model_perms:galaxy.change_group"
    },
    {
        "action": "*",
        "principal": "admin",
        "effect": "allow"
    }
],

Pulp viewset URL 模式松散地基于它们的 API 路径，但这并非总是如此。确定哪个 viewset 名称适用于 API 端点的最佳方法是在此处添加一个打印语句 https://github.com/ansible/galaxy_ng/blob/63803c3c8f40450b7e9e5abcc63121487f80ab33/galaxy_ng/app/access_control/access_policy.py#L81 并查看viewname的值。