a2l007 commented on a change in pull request #10571:
URL: https://github.com/apache/druid/pull/10571#discussion_r571070721
##########
File path:
server/src/main/java/org/apache/druid/server/http/LookupCoordinatorResource.java
##########
@@ -753,4 +844,42 @@ public int hashCode()
return Objects.hash(loaded, pendingNodes);
}
}
+
+ private Map<String, Map<String, LookupExtractorFactoryMapContainer>>
filterByLookupAccess(
+ Map<String, Map<String, LookupExtractorFactoryMapContainer>> lookups,
+ HttpServletRequest request,
+ AuthorizerMapper authorizerMapper,
+ Action action
+ )
+ {
+ final Map<String, Map<String, LookupExtractorFactoryMapContainer>>
filteredLookups = new HashMap<>(lookups);
+ lookups.keySet().forEach(tier -> filteredLookups.compute(tier, (tier1,
lookupFactory) -> {
+ final Map<String, LookupExtractorFactoryMapContainer> filteredMap =
new HashMap<>(lookupFactory);
+ lookupFactory.keySet().forEach(loookupId -> {
+ final Access access =
AuthorizationUtils.authorizeAllResourceActions(
+ request,
+ Collections.singleton(new ResourceAction(new
Resource(loookupId, ResourceType.LOOKUP), action)),
+ authorizerMapper
+ );
+ if (!access.isAllowed()) {
+ filteredMap.remove(loookupId);
+ }
+ });
+ return filteredMap;
+ }
+ ));
+ // We're filtering, so having access to none of the objects isn't an
authorization failure (in terms of whether
+ // to send an error response or not.)
+ request.setAttribute(AuthConfig.DRUID_AUTHORIZATION_CHECKED, true);
Review comment:
Some level of logging would be useful here in case certain lookups are
filtered out here and the cluster operator is unaware as to why it got filtered
out.
##########
File path:
indexing-service/src/main/java/org/apache/druid/indexing/overlord/http/OverlordResource.java
##########
@@ -160,14 +166,25 @@ public OverlordResource(
public Response taskPost(final Task task, @Context final HttpServletRequest
req)
{
final String dataSource = task.getDataSource();
- final ResourceAction resourceAction = new ResourceAction(
+ final List<ResourceAction> resourceActions = new ArrayList<>();
+
+ resourceActions.add(new ResourceAction(
new Resource(dataSource, ResourceType.DATASOURCE),
Action.WRITE
- );
+ ));
+
+ // if its a reindex task from druid, make sure the user has read
permissions on the source druid datasource
+ if (authorizerMapper.getAuthVersion().equals(AuthConfig.AUTH_VERSION_2) &&
task instanceof IndexTask
Review comment:
This wouldn't work for hadoop indexing tasks would it?
##########
File path: server/src/main/java/org/apache/druid/server/QueryLifecycle.java
##########
@@ -196,6 +206,23 @@ public void initialize(final Query baseQuery)
public Access authorize(final AuthenticationResult authenticationResult)
{
transition(State.INITIALIZED, State.AUTHORIZING);
+ if (authorizerMapper.getAuthVersion().equals(AuthConfig.AUTH_VERSION_2)) {
+ return doAuthorize(
+ authenticationResult,
+ AuthorizationUtils.authorizeAllResourceActions(
+ authenticationResult,
+ baseQuery.getDataSource() instanceof LookupDataSource ?
Review comment:
Would this work for lookups specified in DimensionSpecs or extraction
functions?
##########
File path: docs/design/auth-model.md
##########
@@ -0,0 +1,337 @@
+---
+id: auth-model
+title: "Authorization model"
+---
+
+<!--
+ ~ Licensed to the Apache Software Foundation (ASF) under one
+ ~ or more contributor license agreements. See the NOTICE file
+ ~ distributed with this work for additional information
+ ~ regarding copyright ownership. The ASF licenses this file
+ ~ to you under the Apache License, Version 2.0 (the
+ ~ "License"); you may not use this file except in compliance
+ ~ with the License. You may obtain a copy of the License at
+ ~
+ ~ http://www.apache.org/licenses/LICENSE-2.0
+ ~
+ ~ Unless required by applicable law or agreed to in writing,
+ ~ software distributed under the License is distributed on an
+ ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~ KIND, either express or implied. See the License for the
+ ~ specific language governing permissions and limitations
+ ~ under the License.
+ -->
+
+## Authorization model
+
+There are two versions of auth model in Druid, auth v1 model (legacy) and
newer auth v2 model. Auth v1 is default and switch
+to v2 can be made by setting the flag `druid.auth.authVersion=v2` .
+
+Here are the details below -
+
+## Auth V1 Model (Legacy)
+There are two action types in Druid: READ and WRITE
+
+There are three resource types in Druid: DATASOURCE, CONFIG, and STATE.
+
+### DATASOURCE
+Resource names for this type are datasource names. Specifying a datasource
permission allows the administrator to grant users access to specific
datasources.
+
+### CONFIG
+There are two possible resource names for the "CONFIG" resource type, "CONFIG"
and "security". Granting a user access to CONFIG resources allows them to
access the following endpoints.
+
+"CONFIG" resource name covers the following endpoints:
+
+|Endpoint|Process Type|
+|--------|---------|
+|`/druid/coordinator/v1/config`|coordinator|
+|`/druid/indexer/v1/worker`|overlord|
+|`/druid/indexer/v1/worker/history`|overlord|
+|`/druid/worker/v1/disable`|middleManager|
+|`/druid/worker/v1/enable`|middleManager|
+
+"security" resource name covers the following endpoint:
+
+|Endpoint|Process Type|
+|--------|---------|
+|`/druid-ext/basic-security/authentication`|coordinator|
+|`/druid-ext/basic-security/authorization`|coordinator|
+
+### STATE
+There is only one possible resource name for the "STATE" config resource type,
"STATE". Granting a user access to STATE resources allows them to access the
following endpoints.
+
+"STATE" resource name covers the following endpoints:
+
+|Endpoint|Process Type|
+|--------|---------|
+|`/druid/coordinator/v1`|coordinator|
+|`/druid/coordinator/v1/rules`|coordinator|
+|`/druid/coordinator/v1/rules/history`|coordinator|
+|`/druid/coordinator/v1/servers`|coordinator|
+|`/druid/coordinator/v1/tiers`|coordinator|
+|`/druid/broker/v1`|broker|
+|`/druid/v2/candidates`|broker|
+|`/druid/indexer/v1/leader`|overlord|
+|`/druid/indexer/v1/isLeader`|overlord|
+|`/druid/indexer/v1/action`|overlord|
+|`/druid/indexer/v1/workers`|overlord|
+|`/druid/indexer/v1/scaling`|overlord|
+|`/druid/worker/v1/enabled`|middleManager|
+|`/druid/worker/v1/tasks`|middleManager|
+|`/druid/worker/v1/task/{taskid}/shutdown`|middleManager|
+|`/druid/worker/v1/task/{taskid}/log`|middleManager|
+|`/druid/historical/v1`|historical|
+|`/druid-internal/v1/segments/`|historical|
+|`/druid-internal/v1/segments/`|peon|
+|`/druid-internal/v1/segments/`|realtime|
+|`/status`|all process types|
+
+### HTTP methods
+
+For information on what HTTP methods are supported on a particular request
endpoint, please refer to the [API
documentation](../operations/api-reference.md).
+
+GET requires READ permission, while POST and DELETE require WRITE permission.
+
+### SQL Permissions
+
+Queries on Druid datasources require DATASOURCE READ permissions for the
specified datasource.
+
+Queries on the [INFORMATION_SCHEMA
tables](../querying/sql.html#information-schema) will
+return information about datasources that the caller has DATASOURCE READ
access to. Other
+datasources will be omitted.
+
+Queries on the [system schema tables](../querying/sql.html#system-schema)
require the following permissions:
+- `segments`: Segments will be filtered based on DATASOURCE READ permissions.
+- `servers`: The user requires STATE READ permissions.
+- `server_segments`: The user requires STATE READ permissions and segments
will be filtered based on DATASOURCE READ permissions.
+- `tasks`: Tasks will be filtered based on DATASOURCE READ permissions.
+
+## Auth V2 Model
+
+This model can be enabled by setting the flag `druid.auth.authVersion=v2`. The
idea behind this model is to support user
+personas like admin, viewer etc. in an easy manner.
+
+There are two action types in Druid: READ and WRITE. Depending on HTTP method
used for endpoints action is decided, for
+GET and HEAD method action is `READ`, for all other methods action is `WRITE`.
+
+There are 4 resource types in Druid: DATASOURCE, INTERNAL, LOOKUP and SERVER.
+
+1. `DATASOURCE` resource type is concerned with all the actions that can be
taken for querying, indexing, setting retention,
+compaction rules for a dataset. Thus, if a user has read/write action on
datasource they can control the lifecycle of that datasource.
+
+1. `SERVER` resource type covers all the cluster administration endpoints.
+
+1. `LOOKUP` resource type covers lookups similar to `DATASOURCE` resource type.
+
+1. `INTERNAL` resource type covers all the resources/endpoints that druid
internally uses to communicate among nodes.
+
+Examples - A server admin role can have read/write on `DATASOURCE`, `SERVER`
and `LOOKUP` resource types. A viewer can have
+just read on all or specific `DATASOURCE`. Many times users may want to create
roles with custom permissions, all these
+is supported using `Resource Name`, each `Resource type` can have multiple of
them. Authorizer uses `Action`, `Resource Type`
+and `Resource Name` to authorize users action. For example, while querying a
datasource named `ds` a `READ` action on
+resource type `DATASOURCE` with resource name `ds` is required. Below are the
details -
+
+### DATASOURCE
+
+Resource names for this type are datasource names. Specifying a datasource
permission allows the administrator to grant users access to specific
datasources.
+When users get `READ` permission on a datasource, they will be able to query
that datasource, will be able to see retention/compaction rules
+for them, get schema details and vice versa with `WRITE` permissions.
+
+Below are the endpoints protected/filtered using datasource permissions. These
permissions are enforced in SQL queries as well, see `SQL Permissions` section
below.
+
+|Endpoint|Process Type|
+|--------|---------|
+|`GET/POST /druid/coordinator/v1/datasources/...`|coordinator|
+|`GET /druid/coordinator/v1/rules`|coordinator|
+|`GET/POST /druid/coordinator/v1/rules/{dataSourceName}`|coordinator|
+|`GET /druid/coordinator/v1/rules/{dataSourceName}/history`|coordinator|
+|`GET /druid/coordinator/v1/tiers/{tierName}`|coordinator|
+|`GET/POST /druid/v2/datasources/...`|broker|
+|`GET/POST /druid/coordinator/v1/metadata/...`|coordinator|
+|`GET/POST /druid/coordinator/v1/config/compaction`|coordinator|
+|`GET/DELETE /druid/coordinator/v1/config/compaction/{dataSource}`|coordinator|
+|`GET /druid/coordinator/v1/compaction/progress`|coordinator|
+|`GET /druid/coordinator/v1/compaction/status`|coordinator|
+|`POST /druid/indexer/v1/task`|overlord|
+|`GET /druid/indexer/v1/task/{taskid}`|overlord|
+|`GET /druid/indexer/v1/task/{taskid}/status`|overlord|
+|`GET /druid/indexer/v1/task/{taskid}/segments`|overlord|
+|`POST /druid/indexer/v1/task/{taskid}/shutdown`|overlord|
+|`POST /druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks`|overlord|
+|`GET /druid/indexer/v1/waitingTasks`|overlord|
+|`GET /druid/indexer/v1/pendingTasks`|overlord|
+|`GET /druid/indexer/v1/runningTasks`|overlord|
+|`GET /druid/indexer/v1/completeTasks`|overlord|
+|`GET /druid/indexer/v1/tasks`|overlord|
+|`DELETE /druid/indexer/v1/pendingSegments/{dataSource}`|overlord|
+|`GET /druid/indexer/v1/task/{taskid}/log`|overlord|
+|`GET /druid/indexer/v1/task/{taskid}/reports`|overlord|
Review comment:
Should we add `/druid/indexer/v1/supervisor` and `/druid/v2/` here?
##########
File path:
server/src/main/java/org/apache/druid/server/http/LookupCoordinatorResource.java
##########
@@ -541,6 +629,7 @@ LookupStatus getLookupStatus(
@GET
@Produces({MediaType.APPLICATION_JSON})
@Path("/nodeStatus")
+ @ResourceFilters({ ConfigResourceFilter.class,
ServerServerResourceFilter.class })
Review comment:
Shouldn't this be under `SERVER STATUS` ?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
