Restrict UDF Access to a Specific RAM User Without Package Authorization - DataWorks

Use this procedure when you need to restrict a user-defined function (UDF) to a single RAM (Resource Access Management) user while keeping it inaccessible to all other users in the same workspace. This is common for UDFs that implement data encryption or decryption algorithms.

Prerequisites

Before you begin, make sure you have the MaxCompute client (odpscmd) installed. For installation instructions, see Connect using the local client (odpscmd).

Test this configuration in a test workspace before applying it to a production workspace.

Why standard permission methods are insufficient

Standard permission control methods in DataWorks do not support granting access to a specific UDF for a single user:

Package-based authorization shares all objects in a package. Once a user with the developer role is granted package access, they have full permissions on all packages, functions, resources, and tables — not just the specific UDF. The following figure shows the permissions that the developer role has on a DataWorks workspace by default. The following figure shows the permissions that a RAM user has on a DataWorks workspace after being assigned the developer role. For example, if you assign the developer role to the RAM user RAM$xxxxx.pt@example.com:ramtest, that user has full permissions on all objects in the current workspace. For more information, see Access resources across projects using packages.
Custom User Roles (created in the DataWorks console under MaxCompute Management > Custom User Roles) can grant permissions on a table or workspace, but not on a specific UDF.

How the Deny-then-Allow pattern works

The only way to achieve UDF-level, per-user access control is to combine a role policy with a project policy:

Assign the developer role to all users, then apply a role policy to deny access to the UDF for everyone with that role.
Apply a project policy to allow access to the UDF for the specific RAM user you want to grant access.

Both of the following resources must be covered in the policies:

Resource	Description
`getregion` function	The UDF registered in the MaxCompute project
`getaddr.jar`	The JAR file the UDF depends on

Grant UDF access to a specific user

Step 1: Create a deny role for the UDF

On the MaxCompute client, create a role named denyudfrole:
```
create role denyudfrole;
```

Create a role policy file with the following content. This policy denies read and list access to both the UDF and its dependent JAR for anyone assigned this role:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["odps:Read", "odps:List"],
      "Resource": "acs:odps:*:projects/sz_mc/resources/getaddr.jar"
    },
    {
      "Effect": "Deny",
      "Action": ["odps:Read", "odps:List"],
      "Resource": "acs:odps:*:projects/sz_mc/registration/functions/getregion"
    }
  ]
}

Upload the role policy file from your local path:

put policy /Users/yangyi/Desktop/role_policy.json on role denyudfrole;

Verify the role policy was applied correctly:
```
get policy on role denyudfrole;
```
The output should show both Deny statements for getaddr.jar and getregion.
Assign denyudfrole to the RAM user. Because this user already has the developer role (role_project_dev), adding denyudfrole overrides their default access to the UDF:
```
grant denyudfrole to RAM$xxxx.pt@example.com:ramtest;
```

Step 2: Verify the deny role is working

Log in to the MaxCompute client as the RAM user. Run whoami; to confirm the current user:
Run show grants; to check the user's roles and permissions: The output should show two roles: role_project_dev (the default developer role) and denyudfrole.
Confirm the RAM user no longer has read access to getregion or its dependent JAR: If the deny role is working correctly, the output confirms that the read permission on the UDF getregion is denied.

Step 3: Configure the project policy to allow the specific user

Create a project policy file with the following content. Replace the Principal values with the RAM user you want to grant access to:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "RAM$yangyi.pt@example.com:yangyitest",
      "Action": ["odps:Read", "odps:List", "odps:Select"],
      "Resource": "acs:odps:*:projects/sz_mc/resources/getaddr.jar"
    },
    {
      "Effect": "Allow",
      "Principal": "RAM$xxxx.pt@example.com:yangyitest",
      "Action": ["odps:Read", "odps:List", "odps:Select"],
      "Resource": "acs:odps:*:projects/sz_mc/registration/functions/getregion"
    }
  ]
}

Upload the project policy file:

put policy /Users/yangyi/Desktop/project_policy.json;

Verify the project policy was applied:
```
get policy;
```
Log in as the RAM user and confirm the updated permissions with whoami; and show grants;:
Run a SQL node to confirm that only the specified RAM user can access the UDF and its dependent JAR:
- The specified RAM user can access the UDF:
- The specified RAM user can access the dependent JAR:

What's next

To apply this pattern to other UDFs, repeat the procedure and update the Resource values in both the role policy and project policy files.
To revoke access from the specified user, remove the corresponding Allow statements from the project policy and re-upload the file.
For cross-workspace resource sharing, see Access resources across projects using packages.
For general permission management, see Authorize users.