[
https://issues.apache.org/jira/browse/SENTRY-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217202#comment-16217202
]
Hrishikesh Gadre commented on SENTRY-1480:
------------------------------------------
As explained in the jira description, the high-level idea is to automatically
transform the Sentry permissions for Solr to be compatible with latest
Sentry/Solr plugin implemented in SENTRY-1475. e.g. consider a permission
defined as
{noformat}
collection=admin->action=*
{noformat}
After the config migration, the above permission should be replaced with
{noformat}
admin=collections->action=*, admin=cores->action=*
{noformat}
The migration tooling needs to handle both file based Sentry configuration as
well as Sentry service.
(a) For file based Sentry configuration, we can implement a command-line tool
which reads the existing permissions .ini file and emits a new .ini file with
the transformed permissions. Since the .ini file does not carry Sentry version,
it should be responsibility of the user/admin to invoke this migration tool
only for permissions file associated with Sentry 1.x installation. A separate
tool already exists which can import the file based Sentry configuration to
Sentry service. Hence if the user is interested in migrating to Sentry service,
these two tools should be invoked in sequence. i.e.
sentry1.x_permissions_file -(migrate_permissions)-> sentry2.x_permissions_file
- (import) -> Sentry_service_configuration
(b) For Sentry service based configuration, we can take a similar approach.
i.e. to implement a command-line tool which reads the existing permissions from
Sentry service (post Sentry upgrade) and transforms the permissions
accordingly. Since Sentry service version is not provided as part of Sentry
service API, it should be the responsibility of user/admin to invoke this tool
only for permissions associated with Sentry 1.x installation.
Ideally the sentry version needs to recorded in the permissions meta-data to
avoid any issues during migration process due to human error (e.g. consider a
case where a migration tool is run on the Sentry 2.x permissions - in this case
user may have a collection named "admin". Hence the permissions associated with
"admin" collection are semantically different than the once associated with
Sentry 1.x).
> A upgrade tool to migrate Solr/Sentry permissions
> --------------------------------------------------
>
> Key: SENTRY-1480
> URL: https://issues.apache.org/jira/browse/SENTRY-1480
> Project: Sentry
> Issue Type: Task
> Components: Solr Plugin
> Reporter: Hrishikesh Gadre
> Fix For: 2.0.0
>
>
> SENTRY-1475 is tracking the integration between Solr 6 and Sentry. Currently
> admin privileges for Solr are defined using "admin" as the collection name
> (i.e. Sentry reuses collection level permissions for admin operations).
> Solr 6, on the other hand, provides a pluggable authorization framework with
> fine-grained permissions model. Specifically it provides pre-defined
> permissions for admin operations (viz. collection-admin and core-admin etc.).
> Hence we need an upgrade tool to migrate the existing permissions (written
> for Solr 4) to this new permissions model supported by Solr 6.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
