RANGER-5842: Evaluate constraint policies in the policy engine and return applicable constraints in the access result

[vyommani]

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

[mneethiraj]

@vyommani - I suggest separating this PR into 2 parts:

1. to capture updates to RangerAccessResult - so that plugins can start validating the integration
2. policy evaluation updates for constraints

[mneethiraj]

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) {
  ...

[mneethiraj]

constraintResults => constraints

[mneethiraj]

Please add policyPriority as well, as this might be necessary for enforcement to pick appropriate constraints.

Also, consider adding a Comparator to make it easier to sort a constraints list.

static class ConstraintResultComparator implements Comparator<RangerConstraintResult>, java.io.Serializable {
  @Override
  public int compare(RangerConstraintResult me, RangerConstraintResult other) {
    int ret = compareStrings(me.getConstraintName(), other.getConstraintName());

    if (ret == 0) {
      ret = Integer.compare(me.getPolicyPriority(), other.getPolicyPriority());

      if (ret == 0) {
        ret = RangerPolicyResourceMatcher.MATCH_TYPE_COMPARATOR.compare(me.getMatchType(), other.getMatchType());

        if (ret == 0) {
          ret = Integer.compare(me.getPolicyId(), other.getPolicyId());
        }
      }
    }

    return ret;
  }
}

private static int compareStrings(String str1, String str2) {
  if (str1 == null) {
    return str2 == null ? 0 : -1):
  } else if (str2 == null) {
    return 1;
  }  else {
    return str1.compareTo(str2);
  }
}

[vyommani]

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.