----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70310/#review214071 -----------------------------------------------------------
agents-common/src/main/java/org/apache/ranger/plugin/errors/ValidationErrorCode.java Lines 116 (patched) <https://reviews.apache.org/r/70310/#comment300244> Error message doesn't convey the issue. Can you please review and update the message? agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java Lines 1354 (patched) <https://reviews.apache.org/r/70310/#comment300246> if (StringUtils.isNotEmpty(zoneName) && tagPolicyRepository != null && (zoneTagServiceMap == null || zoneTagServiceMap.get(zoneName) == null)) agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java Lines 1359 (patched) <https://reviews.apache.org/r/70310/#comment300245> "Accessed resource in zone '" + zoneName + "' which is not associated with tag service '" + tagServiceName + "'. Evaluating unzoned policies of this tag service" agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java Lines 1374 (patched) <https://reviews.apache.org/r/70310/#comment300247> Following will fall back to unzoned policies if no tag-policy exists for the given tags in 'zoneName' - which is not correct. For example, if a zone doesn't have policy for PII, but has other tag policies, then evaluation shouldn't fall back to unzoned. The right approach should be send down 'zoneName' to getLikelyMatchPolicyEvaluators() in line #1369. security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java Lines 3711 (patched) <https://reviews.apache.org/r/70310/#comment300248> - tagServiceName is already available in 'servicePolicies.getTagPolicies().getServiceName(). There shouldn't be a need to retrieval at line #3709. - is it necessary to get zone details here? Consider a DB query to retrieve just name of zones associated with a given service name (and send in tagServiceName here). - madhan On March 26, 2019, 9:39 p.m., Abhay Kulkarni wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/70310/ > ----------------------------------------------------------- > > (Updated March 26, 2019, 9:39 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/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/1/ > > > Testing > ------- > > Passed all unit tests > > > Thanks, > > Abhay Kulkarni > >
