With all of that said, there is an interesting convergence point when we start hosting services in a Knox server. These services may require resource specific policies.
On Tue, Nov 19, 2013 at 4:29 PM, larry mccay <[email protected]> wrote: > That is an interesting point. > Read/Write permissions to an entire service is rather course but there may > be some value there. > > Not being able to do what your second example illustrates feels bad but > it's not like that isn't possible closer to the resource. > I say leave it out - I wouldn't want someone to confuse this level of > policy with protected all access to those resources - since this is only > the REST channel to it. > > The question remaining is whether: > > super-data-admin= > WEBHDFS:GET,PUT,POST,DELETE > > data-admin= > WEBHDFS:GET,PUT,POST > > this level of policy adds value over a service level toggle yes/no. > > I think that it probably does. > > We could lock the REST channel down to GETs across all of the services if > we wanted to. > > > > On Tue, Nov 19, 2013 at 3:53 PM, Kevin Minder < > [email protected]> wrote: > >> We do need to clarify whether or not "being in the VERB business" implies >> being in the multiple URL business. >> Specifically I would prefer policy be written at the service level not >> the resource level. >> >> data-admin= >> WEBHDFS:GET,PUT,POST,DELETE >> >> not >> >> data-scientist= >> /webhdfs/v1/{user}/**:GET,PUT,POST,DELETE >> /webhdfs/v1/**:GET >> >> but I'd like to hear discussion. >> >> >> On 11/19/13 3:46 PM, larry mccay wrote: >> >>> Yes, I have gone back and forth on that a number of times. >>> I'm not so sure that optional would end up meaning rarely used. >>> We either want to be in that business or not. >>> >>> What is interesting is that we as the REST API Gateway maybe should be >>> interested in the verb based protection. >>> >>> I'm not sure that I can make myself feel strongly about one way over the >>> other. I may lean slightly toward staying out of that business but other >>> related efforts may actually want to specify read vs write control. >>> >>> I just want it know that if we do support verb based policy semantics >>> then >>> we cannot allow folks to hurt themselves with it. >>> JEE made a mistake here long ago and it provides an opportunity for verb >>> tampering in order to bypass policy. >>> >>> Any indication of verb specific policy requires any request for the >>> non-specified verbs to be denied. It is not likely that we would mess >>> this >>> up but I just want to make sure. >>> >>> >>> >>> >>> On Tue, Nov 19, 2013 at 3:29 PM, Kevin Minder >>> <[email protected]>wrote: >>> >>> Hi Everyone, >>>> I wanted to get some of by RBAC enhancement thoughts down on paper. >>>> >>>> The key concept is really the notions of a Knox roles and privileges. A >>>> role is typically (partially) defined as a collection of privileges so >>>> lets >>>> start there. For this discussion I will define a privilege as the >>>> combination of a "service role" (e.g. WEBHDFS) and HTTP verbs (e.g. GET, >>>> PUT, POST, DELETE, etc.). So example privileges might be: >>>> >>>> WEBHDFS: GET >>>> OOZIE: GET,POST >>>> HIVE: GET >>>> >>>> Roles then are a named combination of privileges. Some examples: >>>> >>>> data-admin >>>> WEBHDFS:GET,PUT,POST,DELETE >>>> data-scientist >>>> WEBHDFS:GET >>>> OOZIE: GET,POST >>>> HIVE: GET >>>> >>>> Then Knox should be able to map groups obtained at authentication time >>>> (e.g. LDAP) to one or more of these roles. >>>> This does lead to the natural questions: >>>> 1) How is the group->role mapping managed? >>>> 2) There needs to be a simple way to have the have the roles come >>>> directly >>>> from LDAP such that mapping at the Knox level isn't required >>>> >>>> Seeing this on paper does raise in issue for me that might make the HTTP >>>> verb part a problem. >>>> A "data-scientist" should probably always have HDFS GET,PUT,POST,DELETE >>>> for /user/{uid} directory but the point of the role may be to prevent >>>> file >>>> deletion. >>>> But I don't think Knox should be in the resource authorization business. >>>> So perhaps a role is just a collection of services (i.e. without verb >>>> control) or would that just be optional and rarely used? >>>> >>>> Kevin. >>>> >>>> -- >>>> CONFIDENTIALITY NOTICE >>>> NOTICE: This message is intended for the use of the individual or entity >>>> to which it is addressed and may contain information that is >>>> confidential, >>>> privileged and exempt from disclosure under applicable law. If the >>>> reader >>>> of this message is not the intended recipient, you are hereby notified >>>> that >>>> any printing, copying, dissemination, distribution, disclosure or >>>> forwarding of this communication is strictly prohibited. If you have >>>> received this communication in error, please contact the sender >>>> immediately >>>> and delete it from your system. Thank You. >>>> >>>> >> >> -- >> CONFIDENTIALITY NOTICE >> NOTICE: This message is intended for the use of the individual or entity >> to which it is addressed and may contain information that is confidential, >> privileged and exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby notified that >> any printing, copying, dissemination, distribution, disclosure or >> forwarding of this communication is strictly prohibited. If you have >> received this communication in error, please contact the sender immediately >> and delete it from your system. Thank You. >> > >
