pjain1 opened a new issue #9380: Fine grained config and state resources
URL: https://github.com/apache/druid/issues/9380
 
 
   ### Motivation
   
   This proposal is to introduce fine grained config and state resources for 
better access controls. For example, for a user we may want to allow them the 
permission to view the status of a node but do not want to allow by default 
access to all other state resources like load queue, list of servers or list of 
tasks for a worker etc. Another example, we may want to give permissions to a 
user to just query the datasources but not read/change any state or config of 
the cluster, however even for showing the datasource list on console, a read on 
config is required to fetch compaction status for the datasource.
   
   ### Proposed changes
   
   The current design has the same resource name for all `STATE` and `CONFIG` 
resources which are _state_ and _config_ respectively. To achieve the desired 
results, different resource names will need to be set for these resources. For 
example, for `druid/coordinator/v1/config/compaction` the resource name can be 
_COMPACTION_ and resource type is _CONFIG_ so a `GET` on this endpoint will be 
a `READ on COMPACTION CONFIG` instead of `READ on CONFIG CONFIG`. Similarly 
appropriate names will be chosen for resources. The design always had this 
provision for future improvement, see 
[here](https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/http/security/ConfigResourceFilter.java#L38)
 and  
[here](https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/http/security/StateResourceFilter.java).
   
   - `StateResourceFilter` and `ConfigResourceFilter` will be changed to 
introspect the requested url and set the resource name accordingly before 
performing authorization. 
   - Endpoints that do authorization in the method itself will be changed to 
set the resource names appropriately before authorizing.
   
   ### Rationale
   
   Having fine grained access controls. 
   
   ### Operational impact
   
   If the security extension uses _state_ and _config_ as resource name for 
`STATE` and `CONFIG` resource types for auth checks then they would need to 
change the implementation to allow any name as valid and just check the 
resource type to preserve the old behaviour.
   
   ### Backwards Compatibility 
   Its backward compatible as long as exact resource name match is not done for 
`CONFIG` and `STATE` resource types in the security extension.
   
   

----------------------------------------------------------------
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]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to