Repository navigation
RANGER-5842: Evaluate constraint policies in the policy engine and return applicable constraints in the access result - #1316
Conversation
mneethiraj
left a comment
mneethiraj
left a comment
There was a problem hiding this comment.
@vyommani - I suggest separating this PR into 2 parts:
- to capture updates to
RangerAccessResult- so that plugins can start validating the integration - policy evaluation updates for constraints
|
|
||
| if (policyType == RangerPolicy.POLICY_TYPE_AUDIT) { | ||
| // Audit and constraint policies are outside POLICY_TYPES and use the access resource hierarchy. | ||
| if (policyType == RangerPolicy.POLICY_TYPE_AUDIT || policyType == RangerPolicy.POLICY_TYPE_CONSTRAINTS) { |
There was a problem hiding this comment.
Each constraintDef has its own resources list. So, either this method should ake an additional parameter, constraint, or add a new method that return resources for a speciific constraint.
public Set<List<RangerResourceDef>> getResourceHierarchiesForConstraint(String constraint, Collection<String> keys) {
...
|
Updated: rebased on #1320, renamed to constraints, and policyPriority is set on each result. Added getResourceHierarchiesForConstraint(): it returns the access-hierarchy prefixes that fall within the constraintDef’s resources, and the matcher uses it for constraint policies. Open question: should a constraint policy be limited to a single constraint name? Today the matcher takes the union of hierarchies across the policy’s constraints. |
…turn applicable constraints in the access result
|
@mneethiraj Split: RangerAccessResult / RangerConstraintResult changes merged separately in #1320 (RANGER-5848); this PR now covers evaluation only. Also rebased on master and added RANGER_PLUGIN_CAPABILITY_CONSTRAINT_POLICIES. On mixed constraints in one policy: Admin validation (RANGER-5852) will require the policy’s resources to be valid for every constraint used by its items. |
| private RangerConstraintDef getConstraintDef(String constraint) { | ||
| RangerConstraintDef ret = null; | ||
|
|
||
| if (StringUtils.isNotEmpty(constraint) && CollectionUtils.isNotEmpty(delegate.servicedef.getConstraintDefs())) { |
There was a problem hiding this comment.
Instead of iterating at each call, consider caching in RangerServiceDefHelper.
|
@mneethiraj , addressed your review comments in the latest commit: constraint hierarchies are built from each constraintDef’s resources (graph, as for data-mask/row-filter) and cached per constraint in RangerServiceDefHelper |
What changes were proposed in this pull request?
Depends on #1309 (RANGER-5838). Only the last commit is new; I’ll rebase once #1309 is merged.
What changes were proposed in this pull request?
The policy engine now evaluates constraint policies (POLICY_TYPE_CONSTRAINTS, added in RANGER-5838). When an access request is allowed, every matching constraint is returned in the access result, and the calling service enforces them. Examples: pause for human approval (requireApproval), or limit the rows returned (maxRows).
Integration for services
There’s no change to isAccessAllowed(request).
On an allowed result, RangerAccessResult.getConstraintResults() returns each matching constraint (RangerConstraintResult): the constraint name, parameter values, policy ID and version, and match type.
On a denied result, the list is always empty.
Engine changes
RangerPolicyRepository keeps constraint policy evaluators in a separate list and resource trie. POLICY_TYPE_CONSTRAINTS is not added to POLICY_TYPES, so existing evaluation paths are unchanged. Policy deltas (create, update, delete) are supported.
RangerPolicyEngineImpl evaluates constraint policies after the access decision, and only when the result is allowed. It collects all matching constraints and ignores policy priority. It returns early when a service has no constraint policies.
Matching uses the resource, policy conditions, validity schedule, users/groups/roles, access type and item conditions, including ATTR conditions (RANGER-5822).
RangerDefaultConstraintPolicyItemEvaluator is the only reader of RangerPolicyItemConstraintInfo. Constraint items never change the allow/deny decision.
RangerServiceDefHelper uses the access resource hierarchy for constraint policies, and RangerPolicyDeltaUtil accepts constraint policy deltas.
Limitations (follow-up sub-tasks)
Only request.getAccessType() is matched. Requests for several access types, and _any requests, aren’t expanded.
Resource-based policies only; tag-based constraint policies come later.
The engine doesn’t check constraintDefs. Validating constraint policies against the service-def happens in Admin.
Not yet included: registering the constraints a plugin supports (with deny for unsupported ones), audit of returned constraints, constraints in RangerAuthzResult for authz-api/PDP, and the UI.
How was this patch tested?
New engine test cases in test_policyengine_constraints.json
mvn -pl agents-common verify passes