paul-rogers opened a new issue, #13120:
URL: https://github.com/apache/druid/issues/13120
### Description
Extend the recently-added query context security model to add another level
of filtering defined via system configuration. System configuration will allow
a site to say that selected context keys are either always allowed or never
allowed. Security rules apply only when there are per-user exceptions to the
disallowed keys.
### Background
Druid provides the query context feature in both SQL and native queries.
Query context values provide a wide range of functionality including a custom
query ID, controlling resources, affecting the behavior of execution engines
and much more.
Some of the query context values require deep knowledge of Druid internals.
Setting these values without that knowledge can actually destabilize the Druid
cluster. Because of this, some users want the ability to restrict usage of
query context values.
The current behavior, added within the last year, enforces security rules on
context using Druid’s resource security system. This system allows “users”
(however a particular security extension defines that term) to be granted
permissions on context keys one by one.
### Motivation
Experience has shown that the current system has two opportunities for
improvement. First, it is common for applications to insert query context keys
automatically. With the current approach, all users must be granted permission
on these system-set values. Failure to grant that permission results in all
queries being rejected.
Druid has no way to differentiate a context key set by the user vs. one set
by an application. To Druid, they are just keys set in a map presented to the
query REST API. While we could separate the keys into two groups, nothing would
prevent a user from setting one of the “system” keys.
Second, experience suggests that context key filtering is more of a system
configuration choice than a per-user choice. That is, a given deployment may
choose to disable a set of context keys: not on a per-user basis but site-wide.
### Proposal
To address these issues, and further perfect the context security feature,
we propose to add options to the configuration file in the form of a “allow
list” and a “restrict list”. For example, using straw-man configuration key
names:
```text
druid.query.context.allow=["queryID", "priority"]
```
or
```text
druid.query.context.disallow=["parallelMergeParallelism", "bySegment"]
```
The allow list names those context values that may appear in a query
context, whether set by the user or the site’s application. Keys not in the
accept list are rejected (but see below.) By contrast, keys in the reject list
are forbidden (but again see below), while all others are allowed. If a user
provides both an accept and reject list, then the result is treated as an
reject list with the accept list items removed.
When presented with a query context, Druid will match the actual keys
against the accept and reject lists, and will produce a set of restricted keys.
These the set of restricted keys includes all those in the context, minus those
in the accept list. Or, if a reject list is present, the restricted keys are
those in the context that match the reject list. That is, given a `context`
from a query:
```
if disallow config is not empty then
checkList = context ∩ disallow
end if
checkList = context - allow
```
The `checkList` is then run though the security system as today.
To maintain backward compatibility, Druid next uses the existing security
checks to validate only those keys in the `checkList`. This behavior allows,
say, specific users access to restricted keys. This can be useful if a
developer is asked to try some internal context key to resolve an issue.
Without this feature, the system configuration would have to change for all
users.
### Compatibility
If both lists are empty, and context security is disabled, then the new
features will behave exactly as before: all users can set all keys. If both
lists are empty, and context security is enabled, then the new features also
behave as before: all keys are subject to the security checks.
If either list is present, then the list controls the subset of keys subject
to security. Restricted keys are authorized as before, but accept list keys
bypass the security check. This provides a simple migration path to use
site-level configuration instead of security rules for keys which all users can
set.
### Specific Changes
The code changes to enable this feature are simple:
* Add the accept and reject lists to the Druid configuration files.
* Add the filtering operations described above to the two places where Druid
checks keys: in the SQL and native query paths.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
