[
https://issues.apache.org/jira/browse/DRILL-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17387634#comment-17387634
]
ASF GitHub Bot commented on DRILL-7871:
---------------------------------------
paul-rogers commented on pull request #2251:
URL: https://github.com/apache/drill/pull/2251#issuecomment-887063203
@vdiravka, here I will suggest the broad outline of a design which meets the
very limited goals of this PR while also providing a path forward for a
generally useful set of Apache Drill features.
We introduce one new concept, the *tenant*. Key concepts:
* A tenant is a *name space* for options and plugin configs. The tenant
level is optional; by default, no tenants exist.
* Each user has an optional associated *tenant ID*. A user with no tenant ID
works at the system level. (Example: the Drill admin, or a user who sets up
demo configs shared by all users.) A user with an associated tenant ID gives
the tenant name space to use. There may be 0, 1 or many users associated with a
tenant.
* A persistent *tenant options* name space sits between the system options
and the session options in the option hierarchy. Users "inherit" options from
the system layer, unless overridden at the tenant layer, unless overridden at
the session layer.
* Queries and plugin config-related API calls resolve plugin configs within
the *tenant plugin config name space*. On lookups, if the config is not found
in the tenant name space, repeat the search in the global name space. (Allows
system-wide configs for such things as demo data.)
Now we can decide how much of the above to implement in this PR, leaving the
rest to future PRs. Given your goals, it would seem the minimum is:
* Provide an API or other means to define tenants and to associate tenants
with users.
* Provide documentation for how to inspect or remove per-tenant name spaces
(e.g. if the tenant cancels service or is moved to another cluster.)
* Tenant membership is enforced for the native and REST query APIs.
* Tenant users can see the Drill Console, but features that are not
"tenant-ready" should be disabled. That is, a tenant user might only be able to
run a query, and see their options, but not see query profiles, etc.
SQL semantics:
* The `ALTER SYSTEM` command affects the tenant option store given by the
user's tenant ID, if any. *System* (e.g. server-wide) options are set using the
same command issued by a user with no tenant ID.
* System tables are not available to users associated with a tenant ID.
(Later, this can be modified to filter system table contents to include only
information for that tenant.)
An possible code design might be:
* Add a tenant registry which can be as simple as the known, valid tenant
IDs. This "registry" can simply be an API, with a default implementation that
does nothing.
* Add a field to the user to hold the tenant ID. When resolving a user name,
obtain the tenant ID along with the admin/normal-user access level.
* Unfortunately, Drill does not have a `User` object, we assume the only
information for a user is the user name. Define a new `User` object which holds
the user ID and tenant ID. (Ideally, it would also hold the security level,
etc.)
* We know that the system must determine if the user is an admin. Extend
that mechanism to also provide the tenant ID. Modify that code to provide a new
method which returns the `User` object. A storage plugin manager client can
either use an existing `User` object, or obtain a new one by calling to this
new `User` factory method.
* Introduce the tenant option manager which acts like the system option
manager, and persists to a location that includes the tenant ID in the name.
Persistence is to a location which includes the tenant ID in the name.
* When a session starts, if the user has a tenant ID, add the tenant option
manager to the session option manager stack. This one change should ensure that
the option solution "just works" everywhere else.
* Modify the storage plugin manager to require a `User` object for every
config CRUD method. The `User` says which tenant store to read from or write to.
* The storage plugin registry currently uses keys to locate configs. This
key is extended with the tenant ID. Modify config resolution to use the tenant
ID. If the config is not found in the tenant store, or the tenant ID is not set
for the user, repeat the search with the default "system" config store. When
modifying configs, write to the persistent store given by the tenant ID.
* Modify all clients of the storage plugin manager to pass along the `User`
object, creating one if needed.
* System tables do not have an associated config. For system tables (only),
enforce the rule above: if a plugin lookup resolves to the system plugin, and
the user has an associated tenant ID, act as if the plugin is not found.
This proposed design accomplishes two goals. First, it is limited in scope
to only the limited needs of the PR author. Second, it is constructed in a way
that others can extend the solution toward a full multi-tenant solution in the
future without breaking backward compatibility.
Note that this design is a *multi-tenant* solution, not a *per-user*
solution. I would suggest changing the title of the PR to match the intent to
(partially) solve the multi-tenant problem.
The good news is that this is more-or-less in line with some of the code in
this PR.
@vdiravka, please review these suggestions, and the need to offer a solution
that is of general interest to the Drill community. Feel free to use the above,
or to modify them, to propose a revised set of requirements and designs. Once
we're on the same page at the design level, attention can return to review of
the code 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: dev-unsubscr...@drill.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> StoragePluginStore instances for different users
> ------------------------------------------------
>
> Key: DRILL-7871
> URL: https://issues.apache.org/jira/browse/DRILL-7871
> Project: Apache Drill
> Issue Type: New Feature
> Components: Security
> Affects Versions: 1.18.0
> Reporter: Vitalii Diravka
> Assignee: Vitalii Diravka
> Priority: Major
>
> Different users should have their own storage plugin configs to have access
> to own storages only. The feature can be based on Drill User Impersonation
> model
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
