----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70310/#review214123 -----------------------------------------------------------
security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java Line 3714 (original), 3713 (patched) <https://reviews.apache.org/r/70310/#comment300293> Again, it is not necessary to reteive RangerSecurityZone.RangerSecurityZoneService details here - only zone names are needed. Consider adding a JPA query for this. - madhan On March 27, 2019, 5:06 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, 5:06 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/rest/ServiceREST.java > a60d4e005 > > > Diff: https://reviews.apache.org/r/70310/diff/2/ > > > Testing > ------- > > Passed all unit tests > > > Thanks, > > Abhay Kulkarni > >
