pjain1 commented on issue #9380: URL: https://github.com/apache/druid/issues/9380#issuecomment-623015271
@jon-wei thanks for the comments. Before doing this proposal I had exact same goal to enable users to setup different roles/personas as per their requirement which is currently not possible because of lack of finer permission model. The permissions listed out in spreadsheet is for gathering feedback. I agree that we should strive to simplify the permission model. You mentioned that this proposal introduces more _resource types_, do you mean _resource names_ ? as resource types are still the same. To your point > Maybe it makes sense to start by defining the "core" resource types and then mapping the various endpoints to those core types. New resource names were defined in the spreadsheet with this goal in mind. May be having resource type viz. STATE/CONFIG along with them is redundant ? I need to think more about this, it would be helpful if we start by taking one persona like `Data engineer` - write down types and names for the APIs that he will be using and define permissions for him in format _Aciton:Type:Name_(if we are keeping the format same). For input source security, there can be two approaches - 1. Somehow allow input source specific user credentials to be passed to downstream system from which data is read to enable _do as_ functionality. This seems complex and intrusive. 2. Use Druid permission model by introducing `INPUTSOURCE` _Resource Type_ and corresponding _Resource Name_ will be provided by implementations of _InputSource_ interface. On task submission input source permission will be checked. I have a prototype code here - https://github.com/apache/druid/compare/master...pjain1:ingestion_security?expand=1#diff-40bbee918ab4b9fe487c02c4dfd1989d ---------------------------------------------------------------- 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]
