通过Ranger REST API实现用户权限管理-云原生多模数据库 Lindorm(Lindorm)-阿里云帮助中心

本文档将演示如何通过 Apache Ranger 的 REST API 对 Lindorm 计算引擎进行精细化的权限管理。内容覆盖从创建用户和用户组，到定义并应用权限策略的全过程，旨在帮助您实现统一、安全且高效的权限管控。

核心概念

Ranger：一个开源的统一安全管理框架，为大数据生态组件提供集中式的权限管理、审计和数据加密功能。
用户/ 用户组：权限授权的基本单位。推荐将用户加入用户组，对用户组进行统一授权，以简化管理。
服务：Ranger 中用于表示一个被管控系统（如 Hive、HDFS）的逻辑对象。Lindorm 计算引擎的权限通过 ldps_service 进行控制。
策略：定义“谁能对什么资源做什么操作”的核心规则。它是 Ranger 实现权限控制的基石。

前提条件

在开始操作前，请确保满足以下条件：

已开通 Lindorm 计算引擎并启用了其内置的 Ranger 服务。具体开通步骤，请参见开通Ranger。
准备使用 root 账户及密码执行所有 API 操作。
已将执行 API 请求的客户端 IP 地址添加至 Lindorm 实例的白名单。

说明

本文档仅介绍 Ranger REST API 的基本用法。更详细的接口说明，请参考 Apache Ranger 官方 API 文档。

用户与用户组管理

创建用户

首先，在 Lindorm 控制台创建两个用于演示的普通用户：alice 和 jack。

说明

此时，这些用户仅被创建，尚未授予任何数据库的访问权限。详细创建步骤请参考文档：创建用户。

通过 API 查询用户信息

用户创建成功后，可通过 Ranger API 查询所有用户的详细信息，以验证创建是否成功。

执行查询命令：

# 将 <ranger_proxy_address> 和 <your_password> 替换为您的实际信息
curl -u root:<your_password> -s \
"http://<ranger_proxy_address>:6080/service/xusers/users" | jq .

返回结果示例：

从返回的 JSON 结果中，可以看到我们新创建的 alice 和 jack 用户。

{
  "startIndex": 0,
  "pageSize": 200,
  "totalCount": 10,
  "resultSize": 10,
  "sortType": "asc",
  "sortBy": "id",
  "queryTimeMS": 1776416860771,
  "vXUsers": [
  ...,
   {
      "id": 12,
      "createDate": "2026-04-21T03:39:14Z",
      "updateDate": "2026-04-21T03:39:14Z",
      "owner": "Admin",
      "updatedBy": "Admin",
      "name": "alice",
      "firstName": "alice",
      "password": "*****",
      "description": "alice",
      "groupIdList": [],
      "groupNameList": [],
      "status": 1,
      "isVisible": 1,
      "userSource": 0,
      "userRoleList": [
        "ROLE_USER"
      ]
    },
    {
      "id": 13,
      "createDate": "2026-04-21T03:39:14Z",
      "updateDate": "2026-04-21T03:39:14Z",
      "owner": "Admin",
      "updatedBy": "Admin",
      "name": "jack",
      "firstName": "jack",
      "password": "*****",
      "description": "jack",
      "groupIdList": [],
      "groupNameList": [],
      "status": 1,
      "isVisible": 1,
      "userSource": 0,
      "userRoleList": [
        "ROLE_USER"
      ]
    },
    ....
  ]
}

创建用户组并关联用户

在生产环境中，推荐通过用户组进行权限管理，而非对单个用户逐一授权。

创建用户组

我们创建一个名为 analyst 的用户组，专门用于数据分析。

执行创建命令：

curl -u root:xxxx \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "name": "analyst",
    "description": "analyst group",
    "isVisible": 1
  }' \
  "http://<ranger_proxy_address>:6080/service/xusers/groups"

查询并验证：

创建成功后，查询所有用户组，记下 analyst 组的 id（例如，id 为 2）。
```
curl -u root:<your_password> \
"http://<ranger_proxy_address>:6080/service/xusers/groups" | jq .
```

返回结果示例：

{
  "startIndex": 0,
  "pageSize": 200,
  "totalCount": 2,
  "resultSize": 2,
  "sortType": "asc",
  "sortBy": "id",
  "queryTimeMS": 1776746519096,
  "vXGroups": [
    {
      "id": 1,
      "createDate": "2026-03-20T03:17:00Z",
      "updateDate": "2026-03-20T03:17:00Z",
      "owner": "Admin",
      "updatedBy": "Admin",
      "name": "public",
      "description": "public group",
      "groupType": 0,
      "groupSource": 0,
      "isVisible": 1
    },
    {
      "id": 2,
      "createDate": "2026-04-21T02:39:07Z",
      "updateDate": "2026-04-21T02:39:07Z",
      "owner": "Admin",
      "updatedBy": "Admin",
      "name": "analyst",
      "description": "analyst group",
      "groupType": 0,
      "groupSource": 0,
      "isVisible": 1
    }
  ]
}

将用户添加到用户组

接下来，将用户 jack（假设其用户 ID 为 13）添加到 analyst 用户组（组 ID 为 2）。

执行更新命令：

curl -k -u root:xxxx \
  -H "Content-Type: application/json" \
  -X PUT \
  -d '{
    "id": 13,
    "name": "jack",
    "firstName": "Jack",
    "lastName": "Test",
    "loginId": "jack",
    "emailAddress": "jack@example.com",
    "status": 1,
    "isVisible": 1,
    "userRoleList": [
      "ROLE_USER"
    ],
    "groupIdList": [
      "2"
    ]
  }' \
  "http://<ranger_proxy_address>:6080/service/xusers/secure/users/13"

说明

这里groupIdList为analyst用户组的id，如果需要添加多个，用逗号隔开。

返回结果示例：

更新成功后，再次查询 jack 用户的信息，可以看到其 groupNameList 属性已更新。

{
      "id": 13,
      "createDate": "2026-04-21T03:39:14Z",
      "updateDate": "2026-04-21T04:27:33Z",
      "owner": "Admin",
      "updatedBy": "root",
      "name": "jack",
      "firstName": "Jack",
      "lastName": "Test",
      "emailAddress": "jack@example.com",
      "password": "*****",
      "groupIdList": [
        2
      ],
      "groupNameList": [
        "analyst"
      ],
      "status": 1,
      "isVisible": 1,
      "userSource": 0,
      "userRoleList": [
        "ROLE_USER"
      ]
    }

权限策略管理

Ranger Policy 是定义“谁能对什么资源做什么操作”的核心规则。完成用户和用户组的准备后，便可以开始定义权限策略。通过配置 Policy，管理员可以实现统一、细粒度的权限管理，并结合审计能力记录访问行为，满足数据安全、权限隔离和合规管理需求。

查看可用的 Service

首先，需要确定我们要为哪个 Service 配置策略。Lindorm 计算引擎的权限主要通过 ldps_service 进行控制。

执行查询命令：

curl -u root:xxxx   -X GET "http://<ranger_proxy_address>:6080/service/public/v2/api/service" | jq -r

返回结果示例：

在返回结果中，找到 name 为 ldps_service 的对象，它代表了 Lindorm 计算引擎的服务实例。

[
  {
    "id": 1,
    "guid": "f71fc829-369a-41d8-bb9d-6e1cd15de6a6",
    "isEnabled": true,
    "createdBy": "Admin",
    "updatedBy": "Admin",
    "createTime": 1767163047000,
    "updateTime": 1767163051000,
    "version": 2,
    "type": "hive",
    "name": "ldps_service",
    "displayName": "ldps_service",
    "tagService": "ldps_tag",
    "configs": {
      "password": "*****",
      "hadoop.security.authorization": "true",
      "ranger.plugin.audit.filters": "[ {'accessResult': 'DENIED', 'isAudited': true}, {'actions':['METADATA OPERATION'], 'isAudited': false}, {'users':['hive','hue'],'actions':['SHOW_ROLES'],'isAudited':false} ]",
      "jdbc.driverClassName": "org.apache.hive.jdbc.HiveDriver",
      "jdbc.url": "jdbc:hive2://ranger-hive:10000",
      "username": "_sys_ldps_internal_"
    },
    "policyVersion": 29,
    "policyUpdateTime": 1770277307000,
    "tagVersion": 8,
    "tagUpdateTime": 1770277307000
  },
  ...
]

通过serviceName来查看已有policy：

curl -u root:xxxx \
  -X GET "http://<ranger_proxy_address>:6080/service/public/v2/api/policy?serviceName=ldps_service"

返回结果示例：

[
  {
    "id": 1,
    "guid": "059c7570-4a45-4ddb-970d-303450c98aa2",
    "isEnabled": true,
    "version": 2,
    "service": "ldps_service",
    "name": "all - global",
    "policyType": 0,
    "policyPriority": 0,
    "description": "Policy for all - global",
    "isAuditEnabled": true,
    "resources": {
      "global": {
        "values": [
          "*"
        ],
        "isExcludes": false,
        "isRecursive": false
      }
    },
    "policyItems": [
      {
        "accesses": [
          {
            "type": "select",
            "isAllowed": true
          },
          {
            "type": "update",
            "isAllowed": true
          },
          {
            "type": "create",
            "isAllowed": true
          },
          {
            "type": "drop",
            "isAllowed": true
          },
          {
            "type": "alter",
            "isAllowed": true
          },
          {
            "type": "index",
            "isAllowed": true
          },
          {
            "type": "lock",
            "isAllowed": true
          },
          {
            "type": "all",
            "isAllowed": true
          },
          {
            "type": "read",
            "isAllowed": true
          },
          {
            "type": "write",
            "isAllowed": true
          },
          {
            "type": "repladmin",
            "isAllowed": true
          },
          {
            "type": "serviceadmin",
            "isAllowed": true
          },
          {
            "type": "tempudfadmin",
            "isAllowed": true
          },
          {
            "type": "refresh",
            "isAllowed": true
          }
        ],
        "users": [
          "root"
        ],
        "delegateAdmin": true
      }
    ],
    "serviceType": "hive",
    "isDenyAllElse": false
  },
  ...
]

理解 Policy 结构

一个完整的 Policy 由多个部分组成，核心字段解释如下：

Policy 核心字段

字段	是否必填	示例	说明	填写建议
`service`	是	`"ldps_service"`	Ranger 中的服务名。	填您在 Ranger 中为 Lindorm 计算引擎创建的 Service 名称。
`name`	是	`"policy_sales_select"`	策略的唯一名称。	自定义，建议命名能清晰体现授权内容。
`policyType`	是	`0`	策略类型，`0` 表示访问控制。	普通授权场景固定填 `0`。
`isEnabled`	是	`true`	是否启用此策略。	通常保持 `true`。
`isAuditEnabled`	是	`true`	是否对此策略相关的访问开启审计。	建议保持 `true` 以便追踪。
`resources`	是	见下文	[核心] 定义此策略要保护的资源对象。	在此配置库、表、列等信息。
`policyItems`	是	见下文	[核心] 定义授权规则，即“谁拥有什么权限”。	在此配置用户、组和具体权限。
`isDenyAllElse`	否	`false`	是否拒绝此策略之外的所有其他访问。	建议保持 `false`，以免误拦截正常访问。

resources 资源配置

字段	示例	说明	填写建议
`database.values`	`["ods"]`	要授权的数据库名列表。	填入目标数据库名。
`table.values`	`["*"]` 或 `["orders"]`	表名列表。	使用 `*` 代表库下所有表，或指定具体表名。
`column.values`	`["*"]`	列名列表。	若不做列级控制，通常填 `*` 代表所有列。
`isExcludes`	`false`	是否为排除模式（即授权除指定资源外的所有资源）。	通常保持 `false`。
`isRecursive`	`false`	是否递归应用到子资源（Hive 中较少使用）。	通常保持 `false`。

policyItems 授权配置

字段	示例	说明	填写建议
`users`	`["alice"]`	应用此规则的用户列表。	按用户授权时填写。
`groups`	`["analyst"]`	应用此规则的用户组列表。	按用户组授权时填写（推荐方式）。
`roles`	`[]`	应用此规则的角色列表。	通常可留空。
`accesses`	见下文	具体的权限列表。	在此填入 `select`、`create` 等权限。
`delegateAdmin`	`false`	是否允许被授权者将权限转授给他人。	建议保持 `false` 以遵循最小权限原则。

accesses 权限列表

权限类型 (Type)	含义	常见用途
`select`	查询	允许执行 `SELECT` 语句，读取表数据。
`update`	更新	允许修改数据。
`create`	创建	允许创建表、视图等数据库对象。
`drop`	删除	允许删除表、视图等数据库对象。
`alter`	修改结构	允许执行 `ALTER TABLE` 等修改表结构的操作。
`index`	索引	允许创建或删除索引。
`lock`	锁	允许执行锁相关的操作（较少使用）。
`all`	所有权限	赋予对资源的全部操作权限，通常仅用于管理员。

为单个用户创建 Policy

准备 Policy JSON 文件

创建一个名为 alice_policy.json 的文件，授予用户 alice 对 ods 数据库下所有表的 select 权限。

{
  "service": "ldps_service",
  "name": "policy_sales_db_select",
  "policyType": 0,
  "isEnabled": true,
  "isAuditEnabled": true,
  "resources": {
    "database": {
      "values": ["ods"],
      "isExcludes": false,
      "isRecursive": false
    },
    "table": {
      "values": ["*"],
      "isExcludes": false,
      "isRecursive": false
    },
    "column": {
      "values": ["*"],
      "isExcludes": false,
      "isRecursive": false
    }
  },
  "policyItems": [
    {
      "users": ["alice"],
      "groups": [],
      "roles": [],
      "accesses": [
        {
          "type": "select",
          "isAllowed": true
        }
      ],
      "delegateAdmin": false
    }
  ]
}

提交 Policy

通过REST API将该policy提交到Ranger使其生效：

curl -u root:xxxx \
  -H "Content-Type: application/json" \
  -X POST \
  -d @alice_policy.json \
  "http://<ranger_proxy_address>:6080/service/public/v2/api/policy"

提交成功后，用户 alice 便拥有了对 ods 数据库的只读权限。

为用户组创建 Policy

准备 Policy JSON 文件

创建一个名为 analyst_group_policy.json 的文件，为 analyst 用户组授予 ods 数据库的 select 权限。

{
  "service": "ldps_service",
  "name": "analyst_group_policy",
  "policyType": 0,
  "isEnabled": true,
  "isAuditEnabled": true,
  "resources": {
    "database": {
      "values": ["ods"],
      "isExcludes": false,
      "isRecursive": false
    },
    "table": {
      "values": ["*"],
      "isExcludes": false,
      "isRecursive": false
    },
    "column": {
      "values": ["*"],
      "isExcludes": false,
      "isRecursive": false
    }
  },
  "policyItems": [
    {
      "users": [],
      "groups": ["analyst"],
      "roles": [],
      "accesses": [
        {
          "type": "select",
          "isAllowed": true
        }
      ],
      "delegateAdmin": false
    }
  ]
}

提交 Policy

curl -u root:NcocfnHNiaIp \
  -H "Content-Type: application/json" \
  -X POST \
  -d @analyst_group_policy.json \
  "http://<ranger_proxy_address>:6080/service/public/v2/api/policy"

提交成功后，analyst 用户组下的所有成员（包括 jack）都将自动拥有对 ods 数据库的查询权限。

修改与删除 Policy

修改 Policy：
1. 通过 GET 请求查询并获取目标 Policy 的完整 JSON 内容。
2. 在本地修改 JSON 文件。
3. 使用 PUT 请求（URL 中需包含 Policy ID）将修改后的 JSON 内容提交回去。

删除 Policy：

通过 DELETE 请求并指定 Policy 的 ID 即可删除策略。

curl -u root:xxxx \
  -X DELETE \
  "http://<ranger_proxy_address>:6080/service/public/v2/api/policy/15"