vtlim commented on a change in pull request #11779:
URL: https://github.com/apache/druid/pull/11779#discussion_r724351943
##########
File path: docs/operations/security-overview.md
##########
@@ -39,6 +39,7 @@ The following recommendations apply to the Druid cluster
setup:
* Enable authentication to the Druid cluster for production environments and
other environments that can be accessed by untrusted networks.
* Enable authorization and do not expose the Druid Console without
authorization enabled. If authorization is not enabled, any user that has
access to the web console has the same privileges as the operating system user
that runs the Druid Console process.
* Grant users the minimum permissions necessary to perform their functions.
For instance, do not allow users who only need to query data to write to data
sources or view state.
+* Do not provide plain-text passwords for production systems in configuration
specs. For example, sensitive properties in the consumerProperties of
`KafkaSupervisorIngestionSpec`.
Review comment:
```suggestion
* Do not provide plain-text passwords for production systems in
configuration specs. For example, sensitive properties should not be in the
`consumerProperties` field of `KafkaSupervisorIngestionSpec`.
```
##########
File path: docs/operations/security-user-auth.md
##########
@@ -69,10 +69,10 @@ There are two action types in Druid: READ and WRITE
There are three resource types in Druid: DATASOURCE, CONFIG, and STATE.
Review comment:
```suggestion
There are four resource types in Druid: DATASOURCE, CONFIG, STATE, and
SYSTEM_TABLE.
```
##########
File path: docs/operations/security-user-auth.md
##########
@@ -131,15 +134,16 @@ GET requires READ permission, while POST and DELETE
require WRITE permission.
Queries on Druid datasources require DATASOURCE READ permissions for the
specified datasource.
-Queries on the [INFORMATION_SCHEMA
tables](../querying/sql.md#information-schema) will
-return information about datasources that the caller has DATASOURCE READ
access to. Other
-datasources will be omitted.
+Queries on [INFORMATION_SCHEMA tables](../querying/sql.md#information-schema)
return information about datasources that the caller has DATASOURCE READ access
to. Other
+datasources are omitted.
Queries on the [system schema tables](../querying/sql.md#system-schema)
require the following permissions:
-- `segments`: Segments will be filtered based on DATASOURCE READ permissions.
+- `segments`: Druid filters segments according to DATASOURCE READ permissions.
- `servers`: The user requires STATE READ permissions.
-- `server_segments`: The user requires STATE READ permissions and segments
will be filtered based on DATASOURCE READ permissions.
-- `tasks`: Tasks will be filtered based on DATASOURCE READ permissions.
+- `server_segments`: The user requires STATE READ permissions. Druid filters
segments according to DATASOURCE READ permissions.
+- `tasks`: Druid filters tasks according to DATASOURCE WRITE permissions.
Review comment:
did the permission change from READ to WRITE? just making sure it's not
a carryover typo for `tasks`
##########
File path: docs/operations/security-overview.md
##########
@@ -50,7 +51,7 @@ The following recommendations apply to the network where
Druid runs:
* When possible, use firewall and other network layer filtering to only expose
Druid services and ports specifically required for your use case. For example,
only expose Broker ports to downstream applications that execute queries. You
can limit access to a specific IP address or IP range to further tighten and
enhance security.
The following recommendation applies to Druids authorization and
authentication model:
Review comment:
```suggestion
The following recommendation applies to Druid's authorization and
authentication model:
```
##########
File path: docs/operations/security-user-auth.md
##########
@@ -121,6 +121,9 @@ There is only one possible resource name for the "STATE"
config resource type, "
|`/druid-internal/v1/segments/`|realtime|
|`/status`|all process types|
+### `SYSTEM_TABLES`
+Resource names for this type are system schema table names in the `sys` schema
in SQL. For example `sys.segments` and `sys.server_segments`. Druid only
enforces authorization for `SYSTEM_TABLES` resources when the Broker property
`druid.sql.planner.authorizeSystemTablesDirectly` is true.
+
Review comment:
```suggestion
### `SYSTEM_TABLE`
Resource names for this type are system schema table names in the `sys`
schema in SQL, for example `sys.segments` and `sys.server_segments`. Druid only
enforces authorization for `SYSTEM_TABLE` resources when the Broker property
`druid.sql.planner.authorizeSystemTablesDirectly` is true.
```
--
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]
