clintropolis opened a new issue #11675: URL: https://github.com/apache/druid/issues/11675
### Motivation Currently Druid authorization is handled by `Authorizer` implementations checking if a `Resource`, which is composed of a type, name, and action can be authorized given some authentication context information. For Druid datasources, we have `ResourceType.DATASOURCE`, and the name is the datasource name. Additionally, #10812 added `ResourceType.VIEW` to allow SQL view implementations to also be authorized. However, Druid SQL also has additional schemas, `sys`, `lookup`, `INFORMATION_SCHEMA`, and extensions can define any number of schemas. Adding a new `ResourceType` for each schema is not a scalable solution. ### Proposed changes `Resource` will be extended with a nullable `schema` string property to capture the `schema` that a `name` belongs to. For SQL query authentication, we already have access to the schema because during SQL validation the table identifiers are fully qualified, we are just [discarding the schema information when constructing the `Resource`](https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/calcite/planner/SqlResourceCollectorShuttle.java#L73). For native JSON query authentication, everything with a non-druid schema can be inferred from the type of datasource (e.g. lookups) and set accordingly. Authorizer implementations will need to be updated to consider this parameter, Druid just supplies the `Resource` to validate, so no new global setting will be necessary to enable this behavior, since it will be up to any specific `Authorizer` implementation to act on this additional information. For `druid-basic-security`, this means `BasicAuthorizerPermission` will be updated to allow specifying a schema matching pattern, and a new configuration parameter will be added to set the default schema parameter for permissions which are defined with a null schema (which will include all existing permissions), `druid.auth.authorizer.{authorizerName}.defaultResourceSchemaPattern`, which should default to `druid` to match the existing behavior. I am less familiar with `druid-ranger-security`, but i think it would make the most sense to add an additional property to the request with the `schema` value of the `Resource` along with an extension configuration to control whether or not this schema is included on the request or not. This does not conflict with or contradict #9380 as far as I can tell, though having a separate `LOOKUP` resource type seems perhaps no longer necessary, as this modification can also deprecate the `VIEW` resource type. ### Rationale I considered if there was a way of just capturing the schema in the `name` property of the `Resource`, however, there is not a very good upgrade/downgrade path, because authorizer implementations such as `druid-basic-security` use pattern matching against the name. Having a separate `schema` property avoids encoding this information in the `name` in a backwards incompatible way, and allows authorizer extensions to handle the `schema` property in the most appropriate way, unambiguously. ### Operational impact Cluster operators will gain additional means to secure datasources, including queries on lookup tables and system tables. Operators will however need to be considerate of their authorizer implementation and plan upgrades accordingly. ### Test plan (optional) It will be important to focus on testing upgrade and downgrade paths to ensure that authorization is able to function correctly using configurations of both new and existing behavior models. -- 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]
