> On March 29, 2019, 7:18 a.m., Madhan Neethiraj wrote:
> > agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
> > Lines 1363 (patched)
> > <https://reviews.apache.org/r/70310/diff/3/?file=2135321#file2135321line1363>
> >
> > Unzoned tag policies should be used *only* when the zone is not
> > associated with the service. Lines #1361 to #1385 should be removed. Please
> > review and update.
>
> Abhay Kulkarni wrote:
> The description of the use-case in the JIRA says otherwise. Please review
> the use-case description - especially the part where the access evaluation is
> described, and if it is not correct, then let us fix it and revisit this
> patch as a whole.
I have removed code which picked tag-policies from default zone if there were
no tag-policies for the zone of the accessed resource. However, the JIRA
description needs to changed.
From:
----
On the access evaluation perspective, if accessed resource falls in a Security
Zone, then there are two possibilities:
1) no policies for the zone in tag-service
2) no association of the zone with tag-service
Although it is possible to differentiate between these two cases, tag policies
in the default("unzoned") zone need to be considered for evaluation in both
cases for now.
----
To:
----
On the access evaluation perspective, if accessed resource falls in a Security
Zone, then there are two possibilities:
1) no policies for the zone in tag-service
2) no association of the zone with tag-service
tag policies in the default("unzoned") zone need to be considered for
evaluation in only in the case 2.
-----
- Abhay
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/70310/#review214198
-----------------------------------------------------------
On March 27, 2019, 7:24 p.m., Abhay Kulkarni wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70310/
> -----------------------------------------------------------
>
> (Updated March 27, 2019, 7:24 p.m.)
>
>
> Review request for ranger, Madhan Neethiraj, Mehul Parikh, Nitin Galave, and
> Velmurugan Periasamy.
>
>
> Bugs: RANGER-2379
> https://issues.apache.org/jira/browse/RANGER-2379
>
>
> Repository: ranger
>
>
> Description
> -------
>
> Currently, tag service is associated with a security zone if and only if any
> service-resource (that is, a tuple <resource-service, resource> ) in the
> Security Zone is contained in resource-service that is associated with the
> tag service. However, consider the following use case:
>
> 1) No zone exists. Tag-based policies are in-place, say for PII, EXPIRES_ON,
> etc.
>
> 2) Few tables in finance DB were tagged with EXPIRES_ON; few columns within
> this DB were tagged with PII. So tag-based access enforcement/masking
> policies are in effect for these objects.
>
> 3) An admin creates 'Finance' zone and moves 'finance' DB to this zone.
>
> 4) All tag-based policy enforcement is lost; as there is no tag-based policy
> in 'finance' zone, as the policies still belong to “unzoned” zone.
>
> Given this, it is a better design to not automatically create
> tag-service->zone association. Instead, the association between
> zone->tag-service needs to supported directly similar to how
> zone->resource-service association is established, with one difference; when
> a tag service is associated with a Security Zone, user should not be able to
> include any resource (tag-name, to be specific). This requires GUI changes
> for Security Zone CRUD, but no other changes, especially to tag service
> browser as well as tag policy creation.
>
> On the access evaluation perspective, if accessed resource falls in a
> Security Zone, then there are two possibilities:
>
> 1) no policies for the zone in tag-service
> 2) no association of the zone with tag-service
>
> Although it is possible to differentiate between these two cases, tag
> policies in the default("unzoned") zone need to be considered for evaluation
> in both cases for now.
>
> This patch contains changes for security zone validations and access
> authorization logic only.
>
>
> Diffs
> -----
>
>
> agents-common/src/main/java/org/apache/ranger/plugin/errors/ValidationErrorCode.java
> 5a8fb5e1d
>
> agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerSecurityZoneValidator.java
> 0e3b8f48a
>
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
> 5e683638b
>
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyRepository.java
> ff2a4b207
>
> agents-common/src/main/java/org/apache/ranger/plugin/util/ServicePolicies.java
> 2a80b2518
>
> agents-common/src/test/java/org/apache/ranger/plugin/model/validation/RangerSecurityZoneValidatorTest.java
> fa167a77c
>
> agents-common/src/test/resources/policyengine/test_policyengine_hdfs_zones.json
> 6fcb66e0b
> security-admin/src/main/java/org/apache/ranger/db/XXSecurityZoneDao.java
> 991649664
> security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java
> a60d4e005
> security-admin/src/main/resources/META-INF/jpa_named_queries.xml eaa4e08c2
>
>
> Diff: https://reviews.apache.org/r/70310/diff/3/
>
>
> Testing
> -------
>
> Passed all unit tests
>
>
> Thanks,
>
> Abhay Kulkarni
>
>
