-----------------------------------------------------------
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.
Changes
-------
Addressed review comments
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 (updated)
-----
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/
Changes: https://reviews.apache.org/r/70310/diff/1-2/
Testing
-------
Passed all unit tests
Thanks,
Abhay Kulkarni
