vyommani opened a new pull request, #1316: URL: https://github.com/apache/ranger/pull/1316
## 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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
