diff --git a/docs/operations/security-overview.md b/docs/operations/security-overview.md
index e1a1dd7ff83..236b942a7dc 100644
--- a/docs/operations/security-overview.md
+++ b/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 should not be in the `consumerProperties` field of `KafkaSupervisorIngestionSpec`. See [Environment variable dynamic config provider](./dynamic-config-provider.md#environment-variable-dynamic-config-provider) for more information.
 * Disable JavaScript, as noted in the [Security section](https://druid.apache.org/docs/latest/development/javascript.html#security) of the JavaScript guide.
 
 The following recommendations apply to the network where Druid runs:
@@ -49,8 +50,8 @@ The following recommendations apply to the network where Druid runs:
   - Implement account lockout and throttling features.
 * 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:
-* Only grant `WRITE` permissions to any `DATASOURCE` to trusted users. Druid's trust model assumes those users have the same privileges as the operating system user that runs the Druid Console process. 
+The following recommendation applies to Druid's authorization and authentication model:
+* Only grant `WRITE` permissions to any `DATASOURCE` to trusted users. Druid's trust model assumes those users have the same privileges as the operating system user that runs the Druid Console process. Additionally, users with `WRITE` permissions can make changes to datasources and they have access to both task and supervisor APIs which may return sensitive information.
 * Only grant `STATE READ`, `STATE WRITE`, `CONFIG WRITE`, and `DATASOURCE WRITE` permissions to highly-trusted users. These permissions allow users to access resources on behalf of the Druid server process regardless of the datasource.
 * If your Druid client application allows less-trusted users to control the input source or firehose of an ingestion task, validate the URLs from the users. It is possible to point unchecked URLs to other locations and resources within your network or local file system.
 
diff --git a/docs/operations/security-user-auth.md b/docs/operations/security-user-auth.md
index e5e5cab1bcd..31815995d3c 100644
--- a/docs/operations/security-user-auth.md
+++ b/docs/operations/security-user-auth.md
@@ -34,7 +34,7 @@ Druid uses the following resource types:
 * DATASOURCE – Each Druid table (i.e., `tables` in the `druid` schema in SQL) is a resource.
 * CONFIG – Configuration resources exposed by the cluster components. 
 * STATE – Cluster-wide state resources.
-* SYSTEM_TABLE – if `druid.sql.planner.authorizeSystemTablesDirectly` is enabled, then Druid authorizes system tables, the `sys` schema in SQL, using this resource type.
+* SYSTEM_TABLE – when the Broker property `druid.sql.planner.authorizeSystemTablesDirectly` is true, then Druid uses this resource type to authorize the system tables in the `sys` schema in SQL.
 
 For specific resources associated with the types, see the endpoint list below and corresponding descriptions in [API Reference](./api-reference.md).
 
@@ -67,12 +67,12 @@ Each Authorizer will always have a default "admin" and "druid_system" user with
 
 There are two action types in Druid: READ and WRITE
 
-There are three resource types in Druid: DATASOURCE, CONFIG, and STATE.
+Druid uses the following resource types: `DATASOURCE`, `CONFIG`, `STATE`, and `SYSTEM_TABLE`.
 
-### DATASOURCE
+### `DATASOURCE`
 Resource names for this type are datasource names. Specifying a datasource permission allows the administrator to grant users access to specific datasources.
 
-### CONFIG
+### `CONFIG`
 There are two possible resource names for the "CONFIG" resource type, "CONFIG" and "security". Granting a user access to CONFIG resources allows them to access the following endpoints.
 
 "CONFIG" resource name covers the following endpoints:
@@ -92,7 +92,7 @@ There are two possible resource names for the "CONFIG" resource type, "CONFIG" a
 |`/druid-ext/basic-security/authentication`|coordinator|
 |`/druid-ext/basic-security/authorization`|coordinator|
 
-### STATE
+### `STATE`
 There is only one possible resource name for the "STATE" config resource type, "STATE". Granting a user access to STATE resources allows them to access the following endpoints.
 
 "STATE" resource name covers the following endpoints:
@@ -121,6 +121,8 @@ There is only one possible resource name for the "STATE" config resource type, "
 |`/druid-internal/v1/segments/`|realtime|
 |`/status`|all process types|
 
+### `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.
 ### HTTP methods
 
 For information on what HTTP methods are supported on a particular request endpoint, please refer to the [API documentation](./api-reference.md).
@@ -131,17 +133,18 @@ 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.
+- `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.
 - `supervisors`: Druid filters supervisors according to DATASOURCE WRITE permissions.
 
+When the Broker property `druid.sql.planner.authorizeSystemTablesDirectly` is true, users also require  `SYSTEM_TABLE` authorization on a system schema table to query it.
+
 ## Configuration Propagation
 
 To prevent excessive load on the Coordinator, the Authenticator and Authorizer user/role Druid metadata store state is cached on each Druid process.