[
https://issues.apache.org/jira/browse/SOLR-11543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217706#comment-16217706
]
Hrishikesh Gadre commented on SOLR-11543:
-----------------------------------------
[~ichattopadhyaya] [~noble.paul] let me know your thoughts on this. As part of
Sentry integration, I have added logic to parse the parameters passed as part
of the admin operation and implement necessary permissions check. But this is
brittle to maintain as we upgrade solr versions. Also other authorization
plugins may have similar requirements. So it would be better to implement this
logic cleanly as part of solr authorization framework.
https://github.com/hgadre/sentry/blob/a4ecc83d3e92c81e61aa5441102a9bcd6e90d421/sentry-binding/sentry-binding-solr/src/main/java/org/apache/sentry/binding/solr/authz/SolrAuthzUtil.java#L101
https://github.com/hgadre/sentry/blob/a4ecc83d3e92c81e61aa5441102a9bcd6e90d421/sentry-binding/sentry-binding-solr/src/main/java/org/apache/sentry/binding/solr/authz/SentrySolrPluginImpl.java#L188
> Support fine grained authorization for multi-tenancy usecases
> -------------------------------------------------------------
>
> Key: SOLR-11543
> URL: https://issues.apache.org/jira/browse/SOLR-11543
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 5.2
> Reporter: Hrishikesh Gadre
>
> As part of SOLR-7275, we implemented a pluggable authorization framework for
> Solr. But the current design (specifically wrt to admin apis) is not quite
> suitable to support multi-tenant Solr cloud in a secure environment. In such
> environment, there are two types of system admins (a) admins belonging to the
> service provider and (b) admins belonging to an individual tenant.
> Type (a) admins are responsible to setup solr cluster e.g. setting up solr
> servers, managing security etc.
> Type (b) admins on the other hand are responsible to perform collection-level
> admin operations e.g. creating/deleting/configuring/reloading collections
> belonging to the tenant. From security perspective it is important to ensure
> that such admin is able to operate only on the collections belonging to the
> respective tenant.
> The current design of authorization framework has following limitations
> (a) it does not provide the resource names associated with the operation as
> part of the authorization context (Ref:
> https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java).
> Here the collection names are hard-coded to either null or "*" value in the
> parameter for Name instance. This results in providing global admin
> privileges to the user. In a multi-tenant environment, this is not acceptable.
> (b) The authorization framework assumes that only a single permission is
> necessary for any given operation (Ref:
> https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java#L77).
> For some of the admin operations (e.g. MIGRATE collections admin API) we
> need to check additional permissions for multi-tenancy. Specifically in case
> of MIGRATE API we need to check following permissions
> - collections admin privilege (Update)
> - collection privilege for the source collection (Read)
> - collection privilege for the destination collection (Update)
> Hence ideally PermissionNameProvider needs to return a list of permission
> names instead of a single permission (in most cases the list will contain a
> single element).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
