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 and here.
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.
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
STATEandCONFIGresources which are state and config respectively. To achieve the desired results, different resource names will need to be set for these resources. For example, fordruid/coordinator/v1/config/compactionthe resource name can be COMPACTION and resource type is CONFIG so aGETon this endpoint will be aREAD on COMPACTION CONFIGinstead ofREAD on CONFIG CONFIG. Similarly appropriate names will be chosen for resources. The design always had this provision for future improvement, see here and here.StateResourceFilterandConfigResourceFilterwill be changed to introspect the requested url and set the resource name accordingly before performing authorization.Rationale
Having fine grained access controls.
Operational impact
If the security extension uses state and config as resource name for
STATEandCONFIGresource 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
CONFIGandSTATEresource types in the security extension.