paul-rogers commented on issue #12546:
URL: https://github.com/apache/druid/issues/12546#issuecomment-1133463990
Let's add additional design details as notes to keep the description light.
## Security
The catalog is implemented as another table in Druid's metastore DB.
Operations are via the REST API. When we support SQL DDL statements, the
implementation of those statements will use the same REST API (with some for of
user impersonation.)
In other systems, there are separate permissions for table metadata and
table data. Druid only has read and write access to each datasource, so we work
within those limitations.
The basic security rules for the catalog are:
* Create or update a table definition: allowed only if the user has write
access to the underlying datasource. This means that security rules must exist
before the definition can exist, and that can exist before the datasource
itself.
* Read of the table definition: allowed only if the user has read access to
the underlying datasource.
* List tables: allowed for all users. However, the result list contains only
those tables to which the user has read access.
Druid allows granting permissions on via a regular expression. So, the admin
*could* cobble together a form of private/temporary tables by allowing, say,
write access to all tables of the form "<user>-.*" such as "paul-test",
"paul-temp-metrics" and "paul-temp3".
A future enhancement would be to invent a more advanced security model, but
that is seen as a task separate from the catalog itself.
--
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]
