Resending my previous email. On Wed, Aug 12, 2015 at 7:41 AM, Balaji Ganesan <[email protected]> wrote:
> My responses inline > > On Tue, Aug 11, 2015 at 1:14 PM, Alok Lal <[email protected]> wrote: > >> Please ignore the previous mail as its format got messed up making it >> hard for others to read (hopefully this will be better): >> >> In High Level Concepts: >> >> > Ranger Tag database: This database or tables are used to store >> resources which are tagged. This would also have the attributes associated >> with the resource for the tag. Ranger tag database should be able store >> static or meta level tags. However, tags at the row or cell level should be >> stored at the component level or should be queried with the Tag Source >> System during policy execution from the component plugin. > > >> What is "static" or "meta-level" tag? What would be an example of >> storing at Component level? Say, for hbase, does that mean that cell level >> tags be part of the cell data itself? >> > > BG- I think the requirement is for the database to store tag, associated > metadata and be flexible to store any kind of tag. A static tag is just a > string, and could be anything. > > >> >> >> > Ranger Tag policies: Ranger needs to support policies which are defined >> at the Tag level. Since tag policies are configured at global level, it >> needs to address the permission set supported by the different components. >> TODO DISCUSS: Tag policies across repository >> >> >> To me this seems like not policies but tags are global. To deal with a >> tag that applies to more than one type of repo policy would have to let >> user specify accesses for multiple repo-types. As an aside today policy >> names are unique within a service. That rule would have to reviewed, >> unless of course, we would have a "faux service" that these "global" >> policies belong to. >> >> BG - Not sure if I got the full context here. Please correct me if I am > missing anything. A repository is Ranger world correlates to a cluster, and > yes Tag would be global for all components in a specific cluster. Tag could > have a different meaning for a different environment, i.e., a dev and > production environment could have different tags. Tag policies should be > handled differently than a resource based policy and current thinking is > that it will be a different UI. > > >> >> > Dynamic policy execution: These extendable policies can be used to >> support advanced use cases which needs special understanding the tag and >> attribute value. E.g. if there is policy which currently says it should >> expire in “90” days, but later on the requirement changes to “60” days, >> then the customer might design the tag based policies where the value >> “days” is accepted via policy definition or from other source, but do the >> computation in real-time based on when the resource was created. Out here, >> the resource would have tag with attribute “CreateTime” and it would be set >> when the source is tagged and sent to Ranger > > >> For this to work, won't policy have to allow for different >> ContextEnrichers based on type of component in which it is being >> evaluated? While evaluation can be generic given a CreateTime in context >> harvesting of the CreateTime from the context would necessarily be >> component dependent. >> > > BG- I will be moving expiry related requirements to a different page. The > idea is that data could be classified as limited shelf life with a expiry > date and access should be denied after that date. We can probably get the > expiry date as an attribute from external system. Not sure if this needs to > be component specific, the logic is the same irrespective of what service > is being accessed > > >> In Requirements: >> >> >> > Users would classify data externally in Apache Atlas or an external >> system >> >> >> So we don't want to provide a way for users to specify resource-tag >> association via Ranger UI. Not for now at least. Is it? One can envision >> "external" and "internal" resource-to-tag associations just as we have >> external and internal users today. >> > > BG - This is something the community can decide and pursue, > > >> In Use Cases/Scenarios: >> >> >> > If data is classified with multiple tags, there could be a possibility >> that different policies exists for different tags. Users should be given >> access if any of the the policies provide access to the user or the group. >> Exceptions would be sensitive or classified policies where users could be >> explicitly granted or denied permissions. If a user is denied permission in >> a policy, it would take precedence over any access given in other policies >> >> >> This exceptional treatment – must pass or no other tags/policies matter – >> is it an attribute of the policy of the tag? >> >> BG - We had an offline discussion on deny policy, and exceptions are a > manifestation of that. For sensitive policies, users would want to specifiy > who has access and deny anyone else, in which the deny takes precedence if > though the user may have access through another tag policy or resource > based access. This is manifested through the Ranger policy, not as as > attribute of the tag. > > >> A general comment about the Column Prohibition - Initial thoughts < >> https://cwiki.apache.org/confluence/display/RANGER/Column+Prohibition+-+Initial+thoughts> >> page: >> >> Say, I should not select columns A and Z together. Further, say, there >> is a column B which for most cases uniquely identifies A and Z then user >> can make two queries A with B and then Z with B and use these two to build >> the association between A and Z. To make matters complicated user can make >> these queries weeks apart and confound a threat detection system. >> We can say that admin should have included all A, B and Z in the column >> prohibition set. But my point is that we can come up with a way to build >> association that is meant to be prohibited by making several other joins. >> >> The requirement is well intentioned and perhaps there is no good solution >> to fix what I raise above. My point is just that we should recognize the >> limitations of sort of security this column prohibition can offer. It >> could give users a false sense of security. We need to be upfront about >> its limitations. >> > > BG- Agreed. Column prohibition is not a robust security method rather a > way to prevent accidental non-compliant queries for normal, well > intentioned user. Column prohibition *will not * prevent malicious user > from access to data beyond traditional methods of access control or > encryption. > > > > >> >> >> >> - Alok >> >> >> >> >> >> >> >> From: Balaji Ganesan >> Reply-To: "[email protected]" >> Date: Tuesday, August 11, 2015 at 12:59 PM >> To: "[email protected]" >> Cc: "[email protected]" >> Subject: Re: DISCUSS: Ranger-274 - Support for tag based policies >> >> >> +1 to Bosco's comment. >> >> Alok, would you be able to send the comments to this thread? >> >> >> On Tue, Aug 11, 2015 at 11:30 AM, Don Bosco Durai >> <[email protected]> wrote: >> >> Comments and responses in Wiki page are not manageable and also everyone >> doesn¹t subscribe to wiki updates. >> >> I have seen most ASF projects discuss in user or dev mailing list. The >> discussions and threads gets archived for future references. >> >> It might be good to give your comments in this mailing list. Feedbacks can >> be consolidated and wiki can be updated by wiki page owner on regular >> basis. >> >> Thanks >> >> Bosco >> >> >> On 8/11/15, 11:13 AM, "Alok Lal" <[email protected]> wrote: >> >> >I have added my comments directly on the wiki page! Perhaps that worked >> >for me due to permission levels? >> > >> > >> > >> > >> >On 8/11/15, 10:15 AM, "Don Bosco Durai" <[email protected] on >> behalf >> >of [email protected]> wrote: >> > >> >>Added user mailing list. So others can also provide feedback. >> >> >> >>Thanks >> >> >> >>Bosco >> >> >> >>On 8/11/15, 1:05 AM, "Balaji Ganesan" <[email protected]> >> wrote: >> >> >> >>>I have added my initial thoughts here. >> >>> >> >>> >> https://cwiki.apache.org/confluence/display/RANGER/Tag+based+policy+requ >> >>>ir >> >>>ements >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
