This is an automated email from the ASF dual-hosted git repository.
kassiez pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new a02c7841854 [update] Update auth docs (#1485)
a02c7841854 is described below
commit a02c7841854b63a412730fc2d62dc427a60d2b57
Author: KassieZ <139741991+kass...@users.noreply.github.com>
AuthorDate: Mon Dec 9 20:44:19 2024 +0800
[update] Update auth docs (#1485)
## Versions
- [x] dev
- [x] 3.0
- [x] 2.1
- [ ] 2.0
## Languages
- [x] Chinese
- [x] English
## Docs Checklist
- [ ] Checked by AI
- [ ] Test Cases Built
---
.../auth/authentication-and-authorization.md | 502 ++++++++++-----------
.../admin-manual/auth}/encryption-function.md | 2 +-
.../admin-manual/auth}/encryption-function.md | 4 +-
.../admin-manual/auth}/encryption-function.md | 4 +-
.../admin-manual/auth}/encryption-function.md | 4 +-
sidebars.json | 6 +-
.../auth}/encryption-function.md | 2 +-
.../admin-manual/auth}/encryption-function.md | 2 +-
versioned_sidebars/version-2.1-sidebars.json | 6 +-
versioned_sidebars/version-3.0-sidebars.json | 6 +-
10 files changed, 269 insertions(+), 269 deletions(-)
diff --git a/docs/admin-manual/auth/authentication-and-authorization.md
b/docs/admin-manual/auth/authentication-and-authorization.md
index 093c32ac5c6..977680bec39 100644
--- a/docs/admin-manual/auth/authentication-and-authorization.md
+++ b/docs/admin-manual/auth/authentication-and-authorization.md
@@ -1,7 +1,7 @@
---
{
- "title": "Workload Group",
- "language": "en"
+ "title": "Authentication and Authorization",
+ "language": "en"
}
---
@@ -24,336 +24,336 @@ specific language governing permissions and limitations
under the License.
-->
-You can use Workload Groups to manage the CPU, memory, and I/O resources used
by queries and imports in the Doris cluster, and to control the maximum
concurrency of queries in the cluster. Permissions for Workload Groups can be
granted to specific roles and users.
+The Doris permission management system is modeled after the MySQL permission
management mechanism. It supports fine-grained permission control at the row
and column level, role-based access control, and also supports a whitelist
mechanism.
-Workload Groups are particularly effective in the following scenarios:
-1. For scenarios where performance stability is preferred, and it is not
required for query load to utilize all cluster resources, but stable query
latency is desired. In such cases, you can set hard limits on CPU/I/O for
Workload Groups.
-2. When overall cluster load is high and availability decreases, you can
restore cluster availability by degrading Workload Groups that consume
excessive resources. For example, reduce the maximum query concurrency and I/O
throughput for these Workload Groups.
+## Glossary
-Using hard limits for resource management usually results in better stability
and performance, such as configuring maximum concurrency for FE and setting
hard limits on CPU. Soft limits on CPU typically only have an effect when the
CPU is fully utilized, which can lead to increased latency due to resource
contention with other Doris components (RPC) and the operating system.
Configuring hard limits for Doris query loads can effectively mitigate this
issue. Additionally, setting maximum c [...]
+1. User Identity
-## Version Description
-Workload Group is a feature that has been supported since version 2.0. The
main difference between version 2.0 and 2.1 is that the 2.0 version of Workload
Group does not rely on CGroup, while the 2.1 version of Workload Group depends
on CGroup. Therefore, when using the 2.1 version of Workload Group, the
environment of CGroup needs to be configured.
+ Within a permission system, a user is identified as a User Identity. A User
Identity consists of two parts: `username` and `host`. The `username` is the
user's name, consisting of English letters (both uppercase and lowercase).
`host` represents the IP from which the user connection originates. User
Identity is represented as `username@'host'`, indicating `username` from `host`.
-#### Upgrade to version 2.0
-If upgrading from version 1.2 to version 2.0, it is recommended to enable the
WorkloadGroup after the overall upgrade of the Doris cluster is completed.
Because if you only upgrade a single Follower and enable this feature, as the
FE code of the Master has not been updated yet, there is no metadata
information for Workload Group in the Doris cluster, which may cause queries
for the upgraded Follower nodes to fail. The recommended upgrade process is as
follows:
-* First, upgrade the overall code of the Doris cluster to version 2.0.
-* Start using this feature according to the section ***Workload group usage***
in the following text.
+ Another representation of User Identity is `username@['domain']`, where
`domain` refers to a domain name that can be resolved into a set of IPs through
DNS. Eventually, this is represented as a set of `username@'host'`, hence
moving forward, we uniformly use `username@'host'` to denote it.
-#### Upgrade to version 2.1
-If the code version is upgraded from 2.0 to 2.1, there are two situations:
+2. Privilege
-Scenario 1: In version 2.1, if the Workload Group has already been used, you
only need to refer to the process of configuring cgroup v1 in the following
text to use the new version of the Workload Group.
+ Privileges apply to nodes, data directories, databases, or tables.
Different privileges represent different operation permissions.
-Scenario 2: If the Workload Group is not used in version 2.0, it is also
necessary to upgrade the Doris cluster as a whole to version 2.1, and then
start using this feature according to the section ***Workload group usage*** in
the following text.
+3. Role
-## Workload group properties
+ Doris allows the creation of custom-named roles. A role can be viewed as a
collection of privileges. Newly created users can be assigned a role,
automatically inheriting the privileges of that role. Subsequent changes to the
role's privileges will also reflect on the permissions of all users associated
with that role.
-* cpu_share: Optional, The default value is 1024, with a range of positive
integers. used to set how much cpu time the workload group can acquire, which
can achieve soft isolation of cpu resources. cpu_share is a relative value
indicating the weight of cpu resources available to the running workload group.
For example, if a user creates 3 workload groups rg-a, rg-b and rg-c with
cpu_share of 10, 30 and 40 respectively, and at a certain moment rg-a and rg-b
are running tasks while rg-c ha [...]
+4. User Property
-* memory_limit: Optional, default value is 0% which means unlimited, range of
values from 1% to 100%. set the percentage of be memory that can be used by the
workload group. The absolute value of the workload group memory limit is:
`physical_memory * mem_limit * memory_limit`, where mem_limit is a be
configuration item. The total memory_limit of all workload groups in the system
must not exceed 100%. Workload groups are guaranteed to use the memory_limit
for the tasks in the group in mos [...]
+ User properties are directly affiliated with a user, not the User Identity.
Meaning, both `user@'192.%'` and `user@['domain']` share the same set of user
properties, which belong to the user `user`, not to `user@'192.%'` or
`user@['domain']`.
-* enable_memory_overcommit: Optional, enable soft memory isolation for the
workload group, default is true. if set to false, the workload group is hard
memory isolated and the tasks with the largest memory usage will be canceled
immediately after the workload group memory usage exceeds the limit to release
the excess memory. if set to true, the workload group is hard memory isolated
and the tasks with the largest memory usage will be canceled immediately after
the workload group memory u [...]
+ User properties include but are not limited to: maximum number of user
connections, import cluster configurations, etc.
-* cpu_hard_limit: Optional, default value -1%, no limit. The range of values
is from 1% to 100%. In CPU hard limit mode, the maximum available CPU
percentage of Workload Group cannot exceed cpu_hard_limit value, regardless of
whether the current machine's CPU resources are fully utilized.
- Sum of all Workload Groups's cpu_hard_limit cannot exceed 100%. This is a
new property added since version 2.1.
-* max_concurrency: Optional, maximum query concurrency, default value is the
maximum integer value, which means there is no concurrency limit. When the
number of running queries reaches this value, new queries will being queued.
-* max_queue_size: Optional, length of the query queue. When the queue is full,
new queries will be rejected. The default value is 0, which means no queuing.
-* queue_timeout: Optional, query the timeout time in the queue, measured in
milliseconds. If the query exceeds this value, an exception will be thrown
directly to the client. The default value is 0, which means no queuing.
-* scan_thread_num: Optional, the number of threads used for scanning in the
current workload group. The default value is -1, which means it does not take
effect, the number of scan threads in the be configuration shall prevail. The
value is an integer greater than 0.
-* max_remote_scan_thread_num: Optional. The maximum number of threads in the
scan thread pool for reading external data sources. The default value is -1,
which means the actual number of threads is determined by the BE and is
typically related to the number of cores.
-* min_remote_scan_thread_num: Optional. The minimum number of threads in the
scan thread pool for reading external data sources. The default value is -1,
which means the actual number of threads is determined by the BE and is
typically related to the number of cores.
-* tag: Optional. Default is empty. Assigns a tag to the Workload Group. The
sum of resources for Workload Groups with the same tag cannot exceed 100%. If
multiple values are desired, they can be separated by commas. Detailed
description of the tagging function will follow.
-* read_bytes_per_second: Optional. Specifies the maximum I/O throughput when
reading internal tables in Doris. The default value is -1, which means there is
no limit on I/O bandwidth. Note that this value is not bound to disks but to
folders. For example, if Doris is configured with two folders for storing
internal table data, the maximum read I/O for each folder will not exceed this
value. If these two folders are configured on the same disk, the maximum
throughput control will be twice [...]
-* remote_read_bytes_per_second: Optional. Specifies the maximum I/O throughput
when reading external tables in Doris. The default value is -1, which means
there is no limit on I/O bandwidth.
+## Authentication and Authorization Framework
-Notes:
+The process of a user logging into Apache Doris is divided into two parts:
**Authentication** and **Authorization**.
-1. At present, the simultaneous use of CPU's soft and hard limits is not
supported. A cluster can only have soft or hard limits at a certain time. The
switching method will be described in the following text.
+- Authentication: Identity verification is conducted based on the credentials
provided by the user (such as username, client IP, password). Once verified,
the individual user is mapped to a system-defined User Identity.
+- Authorization: Based on the acquired User Identity, it checks whether the
user has the necessary permissions for the intended operations, according to
the privileges associated with that User Identity.
-2. All properties are optional, but at least one property needs to be
specified when creating a Workload Group.
+## Authentication
-3. It is important to note that the default CPU soft limit values differ
between cgroup v1 and cgroup v2. In cgroup v1, the default CPU soft limit value
is 1024, with a range of 2 to 262144. In contrast, cgroup v2 has a default CPU
soft limit value of 100, with a range of 1 to 10000.
+Doris supports built-in authentication schemes as well as LDAP authentication.
-If a value outside of this range is specified for the soft limit, it can lead
to a failure in modifying the CPU soft limit in the backend. Additionally, if
you set the default value of 100 in a cgroup v1 environment, it might cause the
priority of this workload group to be the lowest on the machine.
+### Doris Built-in Authentication Scheme
-## Grouping Workload Group By Tag
-The Workload Group feature divides the resource usage of a single BE. When a
user creates a Workload Group (Group A), its metadata is by default sent to all
BEs and threads are started on each BE, leading to the following issues:
-1. Multiple Clusters Issue: In a production environment, a Doris cluster is
typically divided into several smaller clusters, such as a local storage
cluster and a cluster with Compute Nodes for querying external storage. These
two clusters operate independently. If a user wants to use the Workload Group
feature, it would lead to the issue where the mem_limit of Workload Groups for
external storage and local storage cannot exceed 100%, even though these two
types of load are on completely [...]
-2. Thread Resource Management: The number of threads itself is a resource. If
a process's thread quota is exhausted, it will cause the process to crash.
Therefore, sending the Workload Group metadata to all nodes by default is also
unreasonable.
+Authentication is based on usernames, passwords, and other information stored
within Doris itself.
-To address these issues, Doris implements a grouping feature for Workload
Groups. The cumulative value of Workload Groups with the same tag cannot exceed
100%, but there can be multiple such tag groups within a cluster. When a BE
node is tagged, it will match the corresponding Workload Groups based on
specific rules.
+Administrators create users with the `CREATE USER` command and view all
created users with the `SHOW ALL GRANTS` command.
-Example:
-1. Create a Workload Group named tag_wg with the tag cn1. If none of the BEs
in the cluster have been tagged, the metadata for this Workload Group will be
sent to all BEs. The tag attribute can specify multiple values, separated by
commas.
-```
-create workload group tag_wg properties('tag'='cn1');
-```
-2. Modify the tag of a BE in the cluster to cn1. At this point, the tag_wg
Workload Group will only be sent to this BE and any BE with no tag. The
tag.workload_group attribute can specify multiple values, separated by commas.
- It is important to note that the alter interface currently does not support
incremental updates. Each time the BE attributes are modified, the entire set
of attributes needs to be provided. Therefore, in the statements below, the
tag.location attribute is added, with 'default' as the system default value. In
practice, the existing attributes of the BE should be specified accordingly.
-```
-alter system modify backend "localhost:9050" set ("tag.workload_group" =
"cn1", "tag.location"="default");
-```
+When a user logs in, the system verifies whether the username, password, and
client IP address are correct.
-Workload Group and BE Matching Rules:
-If the Workload Group's tag is empty, the Workload Group can be sent to all
BEs, regardless of whether the BE has a tag or not.
-If the Workload Group's tag is not empty, the Workload Group will only be sent
to BEs with the same tag.
+#### Password Policy
-You can refer to the recommended
usage:[group-workload-groups](./group-workload-groups.md)
+Doris supports the following password policies to assist users in better
password management.
-## Configure GGroup
+1. `PASSWORD_HISTORY`
-The 2.0 version of Doris uses scheduling based on Doris itself to implement
CPU resource limitations. However, starting from version 2.1, Doris defaults to
using CGroup-based CPU resource limitations. Therefore, if you wish to enforce
CPU resource constraints in version 2.1, the node where the BE (Backend) is
located must have the CGroup environment already installed.
+ Determines whether a user can reuse a historical password when resetting
their current password. For example, `PASSWORD_HISTORY 10` means the last 10
passwords cannot be reused as a new password. Setting `PASSWORD_HISTORY
DEFAULT` will use the value from the global variable `password_history`. A
setting of 0 disables this feature. The default is 0.
-Currently, supported CGroup versions are CGroup v1 and CGroup v2.
+ Examples:
-If users use the Workload Group software limit in version 2.0 and upgrade to
version 2.1, they also need to configure CGroup, Otherwise, cpu soft limit may
not work.
+ - Set a global variable: `SET GLOBAL password_history = 10`
+ - Set for a user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
-If using CGroup within a container, the container needs to have permission to
operate the host.
+2. `PASSWORD_EXPIRE`
-Without configuring GGroup, users can use all functions of the workload group
except for CPU limitations.
+ Sets the expiration time for the current user's password. For instance,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire after 10 days.
`PASSWORD_EXPIRE NEVER` indicates the password never expires. Setting
`PASSWORD_EXPIRE DEFAULT` will use the value from the global variable
`default_password_lifetime` (in days). The default is NEVER (or 0), indicating
it does not expire.
-1. Firstly, confirm that the CGgroup has been installed on the node where BE
is located.
-```
-cat /proc/filesystems | grep cgroup
-nodev cgroup
-nodev cgroup2
-nodev cgroupfs
-```
+ Examples:
-2. Check the cgroup version.
-```
-If this path exists, it indicates that cgroup v1 is currently active.
-/sys/fs/cgroup/cpu/
+ - Set a global variable: `SET GLOBAL default_password_lifetime = 1`
+ - Set for a user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+3. `FAILED_LOGIN_ATTEMPTS` and `PASSWORD_LOCK_TIME`
-If this path exists, it indicates that cgroup v2 is currently active.
-/sys/fs/cgroup/cgroup.controllers
-```
+ Configures the number of incorrect password attempts after which the user
account will be locked and sets the lock duration. For example,
`FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 DAY` means if there are 3
incorrect logins, the account will be locked for one day. Administrators can
unlock the account using the `ALTER USER` statement.
-3. Create a new directory named ```doris``` in CGroup path, user can specify
their own directory name.
+ Example:
-```
-// If using CGroup v1, then mkdir as follow:
-mkdir /sys/fs/cgroup/cpu/doris
+ - Set for a user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
-// If using CGroup v2, then mkdir as follow:
-mkdir /sys/fs/cgroup/doris
-```
+4. Password Strength
-4. It is necessary to ensure that Doris's BE process has read/write/execute
permissions for this directory
-```
-// If using CGroup v1, then do as follow:
-// 1.Modify the permissions of this directory to read, write, and execute
-chmod 770 /sys/fs/cgroup/cpu/doris
+ This is controlled by the global variable `validate_password_policy`. The
default is `NONE/0`, which means no password strength checking. If set to
`STRONG/2`, the password must include at least three of the following:
uppercase letters, lowercase letters, numbers, and special characters, and must
be at least 8 characters long.
-// 2.Assign the ownership of this directory to Doris's account
-chown -R doris:doris /sys/fs/cgroup/cpu/doris
+ Example:
+ - `SET validate_password_policy=STRONG`
-// If using CGroup v2, then do as follow:
-// 1.Modify the permissions of this directory to read, write, and execute
-chmod 770 /sys/fs/cgroup/doris
+For more help, please refer to [ALTER
USER](../../sql-manual/sql-statements/account-management/ALTER-USER.md).
-// 2.Assign the ownership of this directory to Doris's account
-chown -R doris:doris /sys/fs/cgroup/doris
+### LDAP-based Authentication Scheme
-```
+Please refer to [LDAP-based Authentication Scheme](./ldap.md).
-5. If CGroup v2 is being used in the current environment, the following
actions need to be taken. This is because cgroup v2 has stricter permission
controls, requiring write access to the cgroup.procs file in the root directory
in order to move processes between groups.
- This step can be skipped if using CGroup v1.
-```
-chmod a+w /sys/fs/cgroup/cgroup.procs
-```
+## Authorization
-6. Modify the configuration of BE and specify the path to cgroup
-```
-// If using CGroup v1:
-doris_cgroup_cpu_path = /sys/fs/cgroup/cpu/doris
+### Permission Operations
+- Create user: [CREATE
USER](../../../version-3.0/sql-manual/sql-statements/account-management/CREATE-USER.md)
+- Modify user: [ALTER
USER](../../sql-manual/sql-statements/account-management/ALTER-USER.md)
+- Delete user: [DROP
USER](../../sql-manual/sql-statements/account-management/DROP-USER.md)
+- Grant/Assign role:
[GRANT](../../sql-manual/sql-statements/account-management/GRANT-TO)
+- Revoke/Withdraw role:
[REVOKE](../../sql-manual/sql-statements/account-management/REVOKE-FROM.md)
+- Create role: [CREATE
ROLE](../../sql-manual/sql-statements/account-management/CREATE-ROLE.md)
+- Delete role: [DROP
ROLE](../../sql-manual/sql-statements/account-management/DROP-ROLE.md)
+- Modify role: [ALTER
ROLE](../../sql-manual/sql-statements/account-management/ALTER-ROLE.md)
+- View current user's permissions and roles: [SHOW
GRANTS](../../sql-manual/sql-statements/account-management/SHOW-GRANTS.md)
+- View all users' permissions and roles: [SHOW ALL
GRANTS](../../sql-manual/sql-statements/account-management/SHOW-GRANTS.md)
+- View created roles: [SHOW
ROLES](../../sql-manual/sql-statements/account-management/SHOW-ROLES.md)
+- Set user property: [SET
PROPERTY](../../sql-manual/sql-statements/account-management/SET-PROPERTY.md)
+- View user property: [SHOW
PROPERTY](../../sql-manual/sql-statements/account-management/SHOW-PROPERTY.md)
+- Change password: [SET
PASSWORD](../../sql-manual/sql-statements/account-management/SET-PASSWORD.md)
+- View all supported privileges: [SHOW PRIVILEGES]
+- View row policy: [SHOW ROW POLICY]
+- Create row policy: [CREATE ROW POLICY]
-// If using CGroup v2:
-doris_cgroup_cpu_path = /sys/fs/cgroup/doris
-```
+### Types of Permissions
-7. restart BE, in the log (be. INFO), you can see the words "add thread xxx to
group" indicating successful configuration.
+Doris currently supports the following permissions:
-:::tip
-NOTE:
-1. The current workload group does not yet support the deployment of multiple
BEs on a single machine.
-2. After the machine is restarted, the above cgroup configurations will be
cleared. If you want the above configurations to take effect after a reboot,
you can use systemd to set these operations as a custom system service, so that
the creation and permission assignments are automatically completed each time
the machine restarts.
-:::
+1. `Node_priv`
-## Note for Using Workload Groups in K8S
-The CPU management for Workloads is implemented based on CGroup. To use
Workload Groups within containers, you need to start the containers in
privileged mode so that the Doris processes inside the container have
permission to read and write CGroup files on the host.
+ Node modification permission. Includes adding, deleting, and offlining FE,
BE, BROKER nodes.
-When Doris runs inside a container, the CPU resources for Workload Groups are
allocated based on the container's available resources. For example, if the
host machine has 64 cores and the container is allocated 8 cores, with a CPU
hard limit of 50% configured for the Workload Group, the actual number of
usable cores for the Workload Group would be 4 (8 cores * 50%).
+ Root users have this permission by default. Users who possess both
`Grant_priv` and `Node_priv` can grant this permission to other users.
-Memory and I/O management for Workload Groups are handled internally by Doris
and do not rely on external components, so there is no difference in deployment
between containers and physical machines.
+ This permission can only be granted at the Global level.
-If you want to use Doris on K8S, it is recommended to use the Doris Operator
for deployment, as it can abstract away the underlying permission details.
+2. `Grant_priv`
-## Workload group usage
-1. First, create a custom workload group.
-```
-create workload group if not exists g1
-properties (
- "cpu_share"="1024",
- "memory_limit"="30%",
- "enable_memory_overcommit"="true"
-);
-```
-This is soft CPU limit. Since version 2.1, the system will automatically
create a group named ```normal```, which cannot be deleted.
-For details on creating a workload group, see
[CREATE-WORKLOAD-GROUP](../../sql-manual/sql-statements/Data-Definition-Statements/Create/CREATE-WORKLOAD-GROUP).
+ Permission modification authority. Allows execution of operations
including granting, revoking, adding/deleting/modifying users/roles.
-2. show/alter/drop workload group statement as follows:
-```
-show workload groups;
+ Before version 2.1.2, when granting permissions to other users/roles, the
current user only needed the respective level's `Grant_priv` permission. After
version 2.1.2, the current user also needs permission for the resource they
wish to grant.
-alter workload group g1 properties('memory_limit'='10%');
+ When assigning roles to other users, Global level `Grant_priv` permission
is required.
-drop workload group g1;
-```
-to view the workload group, you can visit doris system table
```information_schema.workload_groups``` or
[SHOW-WORKLOAD-GROUPS](../../sql-manual/sql-statements/cluster-management/compute-management/SHOW-WORKLOAD-GROUPS);to
delete a workload group, refer to
[DROP-WORKLOAD-GROUP](../../sql-manual/sql-statements/cluster-management/compute-management/DROP-WORKLOAD-GROUP);
to modify a workload group, refer to
[ALTER-WORKLOAD-GROUP](../../sql-manual/sql-statements/cluster-management/compute-ma
[...]
+3. `Select_priv`
-3. Bind the workload group.
-* Bind the user to the workload group by default by setting the user property
to ```normal```.Note that the value here cannot be left blank, otherwise the
statement will fail to execute. If you're unsure which group to set, you can
set it to ```normal```, as ```normal``` is the global default group.
-```
-set property 'default_workload_group' = 'g1'.
-```
-After executing this statement, the current user's query will use 'g1' by
default.
+ Read-only permission for data directories, databases, and tables.
-* Specify the workload group via the session variable, which defaults to null.
-```
-set workload_group = 'g1'.
-```
-session variable `workload_group` takes precedence over user property
`default_workload_group`, in case `workload_group` is empty, the query will be
bound to `default_workload_group`, in case session variable ` workload_group`
is not empty, the query will be bound to `workload_group`.
+4. `Load_priv`
-If you are a non-admin user, you need to execute
[SHOW-WORKLOAD-GROUPS](../../sql-manual/sql-statements/cluster-management/compute-management/SHOW-WORKLOAD-GROUPS)
to check if the current user can see the workload group, if not, the workload
group may not exist or the current user does not have permission to execute the
query. If you cannot see the workload group, the workload group may not exist
or the current user does not have privileges. To authorize the workload group,
refer to: [gr [...]
+ Write permission for data directories, databases, and tables. Includes
Load, Insert, Delete, etc.
-4. Execute the query, which will be associated with the g1 workload group.
+5. `Alter_priv`
-### Query Queue
-```
-create workload group if not exists queue_group
-properties (
- "cpu_share"="10",
- "memory_limit"="30%",
- "max_concurrency" = "10",
- "max_queue_size" = "20",
- "queue_timeout" = "3000"
-);
-```
-1. It should be noted that the current queuing design is not aware of the
number of FEs, and the queuing parameters only works in a single FE, for
example:
+ Alteration permissions for data directories, databases, and tables.
Includes renaming libraries/tables, adding/deleting/modifying columns,
adding/deleting partitions, etc.
-A Doris cluster is configured with a work load group and set max_concurrency=1,
-If there is only 1 FE in the cluster, then this workload group will only run
one SQL at the same time from the Doris cluster perspective,
-If there are 3 FEs, the maximum number of query that can be run in Doris
cluster is 3.
+6. `Create_priv`
-2. In some operational scenarios, the administrator needs to bypass the
queuing. This can be achieved by setting a session variable:
-```
-set bypass_workload_group = true;
-```
+ Permission to create data directories, databases, tables, and views.
-### Configure CPU hard limits
-At present, Doris defaults to running the CPU's soft limit. If you want to use
Workload Group's hard limit, you can do as follows.
+7. `Drop_priv`
-1 Enable the cpu hard limit in FE. If there are multiple FE, the same
operation needs to be performed on each FE.
-```
-1 modify fe.conf in disk
-experimental_enable_cpu_hard_limit = true
+ Permission to delete data directories, databases, tables, and views.
-2 modify conf in memory
-ADMIN SET FRONTEND CONFIG ("enable_cpu_hard_limit" = "true");
-```
+8. `Usage_priv`
-2 modify cpu_hard_limit
-```
-alter workload group g1 properties ( 'cpu_hard_limit'='20%' );
-```
+ Usage permissions for Resources and Workload Groups.
-3 Viewing the current configuration of the Workload Group, it can be seen that
although the cpu_share may not be 0, but due to the hard limit mode being
enabled, the query will also follow the CPU's hard limit during execution. That
is to say, the switch of CPU software and hardware limits does not affect
workload group modification.
-```
-mysql [information_schema]>select name,
cpu_share,memory_limit,enable_memory_overcommit,cpu_hard_limit from
information_schema.workload_groups where name='g1';
-+------+-----------+--------------+--------------------------+----------------+
-| name | cpu_share | memory_limit | enable_memory_overcommit | cpu_hard_limit |
-+------+-----------+--------------+--------------------------+----------------+
-| g1 | 1024 | 30% | true | 20% |
-+------+-----------+--------------+--------------------------+----------------+
-1 row in set (0.02 sec)
-```
+9. `Show_view_priv`
-### How to switch CPU limit node between soft limit and hard limit
-At present, Doris does not support running both the soft and hard limits of
the CPU simultaneously. A Doris cluster can only have either the CPU soft limit
or the CPU hard limit at any time.
+ Permission to execute `SHOW CREATE VIEW`.
-Users can switch between two modes, and the main switching methods are as
follows:
+### Permission Levels
-1 If the current cluster configuration is set to the default CPU soft limit
and it is expected to be changed to the CPU hard limit, then cpu_hard_limit
should be set to a valid value first.
-```
-alter workload group test_group properties ( 'cpu_hard_limit'='20%' );
-```
-It is necessary to modify cpu_hard_limit of all Workload Groups in the current
cluster, sum of all Workload Group's cpu_hard_limit cannot exceed 100%.
-Due to the CPU's hard limit can not being able to provide a valid default
value, if only the switch is turned on without modifying cpu_hard_limit, the
CPU's hard limit will not work.
+#### Global Permissions
-2 Turn on the CPU hard limit switch in all FEs.
-```
-1 modify fe.conf
-experimental_enable_cpu_hard_limit = true
+Permissions granted through the GRANT statement with `*.*.*` scope. These
permissions apply to any table within any catalog.
-2 modify conf in memory
-ADMIN SET FRONTEND CONFIG ("enable_cpu_hard_limit" = "true");
-```
+#### Catalog Permissions
-If user expects to switch back from cpu hard limit to cpu soft limit, then
they only need to set ```enable_cpu_hard_limit=false```.
-CPU Soft Limit property ```cpu_share``` will be filled with a valid value of
1024 by default(If the user has never set the cpu_share before), and users can
adjust cpu_share based on the priority of Workload Group.
+Permissions granted through the GRANT statement with `ctl.*.*` scope. These
permissions apply to any table within the specified catalog.
-# Workload Group Permissions Table
-You can view the Workload Groups that users or roles have access to through
the Workload Group privilege table. Authorization related usage can refer
to[grant
statement](../../sql-manual/sql-statements/account-management/GRANT-TO).
+#### Database Permissions
-This table currently has row level permission control. Root or admin accounts
can view all data, while non root/admin accounts can only see data from
Workload Groups that they have access to.
+Permissions granted through the GRANT statement with `ctl.db.*` scope. These
permissions apply to any table within the specified database.
-Schema of Workload Group privilege table is as follow:
-```
-mysql [information_schema]>desc information_schema.workload_group_privileges;
-+---------------------+--------------+------+-------+---------+-------+
-| Field | Type | Null | Key | Default | Extra |
-+---------------------+--------------+------+-------+---------+-------+
-| GRANTEE | varchar(64) | Yes | false | NULL | |
-| WORKLOAD_GROUP_NAME | varchar(256) | Yes | false | NULL | |
-| PRIVILEGE_TYPE | varchar(64) | Yes | false | NULL | |
-| IS_GRANTABLE | varchar(3) | Yes | false | NULL | |
-+---------------------+--------------+------+-------+---------+-------+
-```
+#### Table Permissions
-Column Description:
-1. grantee, user or role.
-2. workload_group_name, value is the name of Workload Group or '%', where '%'
represents all Workload Group.
-3. privilege_type, type of privilege, at present, the value of this column is
only Usage_priv.
-4. is_grantable, value is YES or NO, it means whether the user can grant
access privilege of Workload Group to other user.Only root/admin user has grant
privilege.
+Permissions granted through the GRANT statement with `ctl.db.tbl` scope. These
permissions apply to any column within the specified table.
-Basic usage:
-1. Search for Workload Group with authorized access based on username.
-```
-mysql [information_schema]>select * from workload_group_privileges where
GRANTEE like '%test_wlg_user%';
-+---------------------+---------------------+----------------+--------------+
-| GRANTEE | WORKLOAD_GROUP_NAME | PRIVILEGE_TYPE | IS_GRANTABLE |
-+---------------------+---------------------+----------------+--------------+
-| 'test_wlg_user'@'%' | normal | Usage_priv | NO |
-| 'test_wlg_user'@'%' | test_group | Usage_priv | NO |
-+---------------------+---------------------+----------------+--------------+
-2 rows in set (0.04 sec)
-```
+#### Column Permissions
+
+Column permissions are primarily used to restrict user access to certain
columns within a table. Specifically, column permissions allow administrators
to set viewing, editing, and other rights for certain columns, controlling user
access and manipulation of specific column data.
+
+Permissions for specific columns of a table can be granted with `GRANT
Select_priv(col1,col2) ON ctl.db.tbl TO user1`.
+
+Currently, column permissions support only `Select_priv`.
+
+#### Row-Level Permissions
+
+Row Policies enable administrators to define access policies based on fields
within the data, controlling which users can access which rows.
+
+Specifically, Row Policies allow administrators to create rules that can
filter or restrict user access to rows based on actual values stored in the
data.
+
+From version 1.2, row-level permissions can be created with the `CREATE ROW
POLICY` command.
+
+From version 2.1.2, support for setting row-level permissions through Apache
Ranger's `Row Level Filter` is available.
+
+#### Usage Permissions
+
+- Resource Permissions
+
+ Resource permissions are set specifically for Resources, unrelated to
permissions for databases or tables, and can only assign `Usage_priv` and
`Grant_priv`.
+
+ Permissions for all Resources can be granted with the `GRANT USAGE_PRIV ON
RESOURCE '%' TO user1`.
+
+- Workload Group Permissions
+
+ Workload Group permissions are set specifically for Workload Groups,
unrelated to permissions for databases or tables, and can only assign
`Usage_priv` and `Grant_priv`.
+
+ Permissions for all Workload Groups can be granted with `GRANT USAGE_PRIV
ON WORKLOAD GROUP '%' TO user1`.
+
+### Data Masking
+
+Data masking is a method to protect sensitive data by modifying, replacing, or
hiding the original data, such that the masked data retains certain formats and
characteristics while no longer containing sensitive information.
+
+For example, administrators may choose to replace part or all of the digits of
sensitive fields like credit card numbers or ID numbers with asterisks `*` or
other characters, or replace real names with pseudonyms.
+
+From version 2.1.2, support for setting data masking policies for certain
columns through Apache Ranger's Data Masking is available, currently only
configurable via [Apache Ranger](./ranger.md).
+
+### Doris Built-in Authorization Scheme
+
+Doris's permission design is based on the RBAC (Role-Based Access Control)
model, where users are associated with roles, and roles are associated with
permissions. Users are indirectly linked to permissions through their roles.
+
+When a role is deleted, users automatically lose all permissions associated
with that role.
+
+When a user is disassociated from a role, they automatically lose all
permissions of that role.
+
+When permissions are added to or removed from a role, the permissions of the
users associated with that role change accordingly.
-2. Search for user which has access privilege by Workload Group name.
```
-mysql [information_schema]>select * from workload_group_privileges where
WORKLOAD_GROUP_NAME='test_group';
-+---------------------+---------------------+----------------+--------------+
-| GRANTEE | WORKLOAD_GROUP_NAME | PRIVILEGE_TYPE | IS_GRANTABLE |
-+---------------------+---------------------+----------------+--------------+
-| 'test_wlg_user'@'%' | test_group | Usage_priv | NO |
-+---------------------+---------------------+----------------+--------------+
-1 row in set (0.03 sec)
+┌────────┐ ┌────────┐ ┌────────┐
+│ user1 ├────┬───► role1 ├────┬────► priv1 │
+└────────┘ │ └────────┘ │ └────────┘
+ │ │
+ │ │
+ │ ┌────────┐ │
+ │ │ role2 ├────┤
+┌────────┐ │ └────────┘ │ ┌────────┐
+│ user2 ├────┘ │ ┌─► priv2 │
+└────────┘ │ │ └────────┘
+ ┌────────┐ │ │
+ ┌──────► role3 ├────┘ │
+ │ └────────┘ │
+ │ │
+ │ │
+┌────────┐ │ ┌────────┐ │ ┌────────┐
+│ userN ├─┴──────► roleN ├───────┴─► privN │
+└────────┘ └────────┘ └────────┘
```
+
+As shown above:
+
+User1 and user2 both have permission `priv1` through `role1`.
+
+UserN has permission `priv1` through `role3`, and permissions `priv2` and
`privN` through `roleN`. Thus, userN has permissions `priv1`, `priv2`, and
`privN` simultaneously.
+
+For ease of user operations, it is possible to directly grant permissions to a
user. Internally, a unique default role is created for each user. When
permissions are granted to a user, it is essentially granting permissions to
the user's default role.
+
+The default role cannot be deleted, nor can it be assigned to someone else.
When a user is deleted, their default role is automatically deleted as well.
+
+### Authorization Scheme Based on Apache Ranger
+
+Please refer to [Authorization Scheme Based on Apache Ranger](./ranger.md).
+
+## Common Questions
+
+### Explanation of Permissions
+
+1. Users with ADMIN privileges or GRANT privileges at the GLOBAL level can
perform the following operations:
+
+ - CREATE USER
+ - DROP USER
+ - ALTER USER
+ - SHOW GRANTS
+ - CREATE ROLE
+ - DROP ROLE
+ - ALTER ROLE
+ - SHOW ROLES
+ - SHOW PROPERTY FOR USER
+
+2. GRANT/REVOKE
+
+ - Users with ADMIN privileges can grant or revoke permissions for any user.
+ - Users with ADMIN or GLOBAL level GRANT privileges can assign roles to
users.
+ - Users who have the corresponding level of GRANT privilege and the
permissions to be assigned can distribute those permissions to users/roles.
+
+3. SET PASSWORD
+
+ - Users with ADMIN privileges or GLOBAL level GRANT privileges can set
passwords for non-ROOT users.
+ - Ordinary users can set the password for their corresponding User
Identity. Their corresponding User Identity can be viewed with the `SELECT
CURRENT_USER()` command.
+ - ROOT users can change their own password.
+
+### Additional Information
+
+1. When Doris is initialized, the following users and roles are automatically
created:
+
+ - operator role: This role has `Node_priv` and `Admin_priv`, i.e., all
permissions in Doris.
+ - admin role: This role has `Admin_priv`, i.e., all permissions except for
node changes.
+ - root@'%': root user, allowed to log in from any node, with the operator
role.
+ - admin@'%': admin user, allowed to log in from any node, with the admin
role.
+
+2. It is not supported to delete or change the permissions of roles or users
created by default.
+
+3. There is only one user with the operator role, which is Root. There can be
multiple users with the admin role.
+
+4. Some potentially conflicting operations are explained as follows:
+
+ 1. Domain and IP conflict:
+
+ Suppose the following user is created:
+
+ `CREATE USER user1@['domain'];`
+
+ And granted:
+
+ `GRANT SELECT_PRIV ON *.* TO user1@['domain']`
+
+ This domain is resolved to two IPs: ip1 and ip2.
+
+ Suppose later, we grant a separate permission to `user1@'ip1'`:
+
+ `GRANT ALTER_PRIV ON . TO user1@'ip1';`
+
+ Then `user1@'ip1'` will have permissions for both Select_priv and
Alter_priv. And when we change the permissions for `user1@['domain']` again,
`user1@'ip1'` will not follow the change.
+
+ 2. Duplicate IP conflict:
+
+ Suppose the following users are created:
+
+ ```
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
In terms of priority, `'192.%'` takes precedence over `'%'`, so when
user `user1` from machine `192.168.1.1` tries to log into Doris using password
`'12345'`, access will be denied.
5. Forgotten Password
diff --git a/versioned_docs/version-3.0/query-data/encryption-function.md
b/docs/admin-manual/auth/encryption-function.md
similarity index 97%
rename from versioned_docs/version-3.0/query-data/encryption-function.md
rename to docs/admin-manual/auth/encryption-function.md
index c9f7afab50d..2ff19794e74 100644
--- a/versioned_docs/version-3.0/query-data/encryption-function.md
+++ b/docs/admin-manual/auth/encryption-function.md
@@ -1,6 +1,6 @@
---
{
- "title": "Encrption and Masking Function ",
+ "title": "Encryption and Masking Function ",
"language": "en"
}
---
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/query-data/encryption-function.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/encryption-function.md
similarity index 96%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/query-data/encryption-function.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/encryption-function.md
index 75b375ef1fc..8faeaca0281 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/query-data/encryption-function.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/encryption-function.md
@@ -1,7 +1,7 @@
---
{
- "title": "Encrption and Masking Function ",
- "language": "en"
+ "title": "加密和脱敏函数",
+ "language": "zh-CN"
}
---
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-data/encryption-function.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/encryption-function.md
similarity index 96%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-data/encryption-function.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/encryption-function.md
index 75b375ef1fc..8faeaca0281 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-data/encryption-function.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/encryption-function.md
@@ -1,7 +1,7 @@
---
{
- "title": "Encrption and Masking Function ",
- "language": "en"
+ "title": "加密和脱敏函数",
+ "language": "zh-CN"
}
---
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query-data/encryption-function.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/auth/encryption-function.md
similarity index 96%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query-data/encryption-function.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/auth/encryption-function.md
index 75b375ef1fc..78a8f3c15cf 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query-data/encryption-function.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/auth/encryption-function.md
@@ -1,7 +1,7 @@
---
{
- "title": "Encrption and Masking Function ",
- "language": "en"
+ "title": "加密和脱敏函数",
+ "language": "zh-CN"
}
---
diff --git a/sidebars.json b/sidebars.json
index d56fcb7cbb0..9cad3b2d210 100644
--- a/sidebars.json
+++ b/sidebars.json
@@ -237,8 +237,7 @@
]
},
"query-data/complex-type",
- "query-data/lateral-view",
- "query-data/encryption-function"
+ "query-data/lateral-view"
]
},
{
@@ -449,7 +448,8 @@
"admin-manual/auth/ldap",
"admin-manual/auth/ranger",
"admin-manual/auth/certificate",
- "admin-manual/auth/fe-certificate"
+ "admin-manual/auth/fe-certificate",
+ "admin-manual/auth/encryption-function"
]
},
{
diff --git a/versioned_docs/version-2.1/query-data/encryption-function.md
b/versioned_docs/version-2.1/admin-manual/auth/encryption-function.md
similarity index 97%
rename from versioned_docs/version-2.1/query-data/encryption-function.md
rename to versioned_docs/version-2.1/admin-manual/auth/encryption-function.md
index c9f7afab50d..5fd76b9ce68 100644
--- a/versioned_docs/version-2.1/query-data/encryption-function.md
+++ b/versioned_docs/version-2.1/admin-manual/auth/encryption-function.md
@@ -1,6 +1,6 @@
---
{
- "title": "Encrption and Masking Function ",
+ "title": "Encryption and Masking Function",
"language": "en"
}
---
diff --git a/docs/query-data/encryption-function.md
b/versioned_docs/version-3.0/admin-manual/auth/encryption-function.md
similarity index 97%
rename from docs/query-data/encryption-function.md
rename to versioned_docs/version-3.0/admin-manual/auth/encryption-function.md
index c9f7afab50d..5fd76b9ce68 100644
--- a/docs/query-data/encryption-function.md
+++ b/versioned_docs/version-3.0/admin-manual/auth/encryption-function.md
@@ -1,6 +1,6 @@
---
{
- "title": "Encrption and Masking Function ",
+ "title": "Encryption and Masking Function",
"language": "en"
}
---
diff --git a/versioned_sidebars/version-2.1-sidebars.json
b/versioned_sidebars/version-2.1-sidebars.json
index 537ccf79818..00177760681 100644
--- a/versioned_sidebars/version-2.1-sidebars.json
+++ b/versioned_sidebars/version-2.1-sidebars.json
@@ -221,8 +221,7 @@
]
},
"query-data/complex-type",
- "query-data/lateral-view",
- "query-data/encryption-function"
+ "query-data/lateral-view"
]
},
{
@@ -406,7 +405,8 @@
"admin-manual/auth/ldap",
"admin-manual/auth/ranger",
"admin-manual/auth/certificate",
- "admin-manual/auth/fe-certificate"
+ "admin-manual/auth/fe-certificate",
+ "admin-manual/auth/encryption-function"
]
},
{
diff --git a/versioned_sidebars/version-3.0-sidebars.json
b/versioned_sidebars/version-3.0-sidebars.json
index ff8b8c7bf94..714485feb60 100644
--- a/versioned_sidebars/version-3.0-sidebars.json
+++ b/versioned_sidebars/version-3.0-sidebars.json
@@ -238,8 +238,7 @@
]
},
"query-data/complex-type",
- "query-data/lateral-view",
- "query-data/encryption-function"
+ "query-data/lateral-view"
]
},
{
@@ -442,7 +441,8 @@
"admin-manual/auth/ldap",
"admin-manual/auth/ranger",
"admin-manual/auth/certificate",
- "admin-manual/auth/fe-certificate"
+ "admin-manual/auth/fe-certificate",
+ "admin-manual/auth/encryption-function"
]
},
{
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
