vyommani opened a new pull request, #1309:
URL: https://github.com/apache/ranger/pull/1309
…licy model to RangerPolicy
## What changes were proposed in this pull request?
This adds the data model for constraint policies. It’s the first step toward
constraint-policy support: conditions a plugin must enforce on top of an allow
decision, such as human approval for AI agent actions (requireApproval) or row
limits (maxRows). This change only adds model classes and JSON serialization.
RangerServiceDef
New constraintDefs (List<RangerConstraintDef>): the constraints a service
supports.
RangerConstraintDef fields: itemId, name, label, description, rbKeyLabel,
rbKeyDescription, resources (resource names), accessTypes (access-type names),
parameters, options.
RangerConstraintParamDef fields: itemId, name, label, description, type,
mandatory (defaults to false), defaultValue, rbKeyLabel, rbKeyDescription.
updateFrom, dedupStrings and toString include the new field. dataMaskDef and
rowFilterDef are unchanged.
RangerPolicy
New POLICY_TYPE_CONSTRAINTS = 4. Like POLICY_TYPE_AUDIT, it is not added to
POLICY_TYPES, so engine and Admin code that loops over policy types is
unaffected until evaluation support is added.
New constraintPolicyItems (List<RangerConstraintPolicyItem>).
RangerConstraintPolicyItem extends RangerPolicyItem and carries
RangerPolicyItemConstraintInfo: constraintName plus parameters (Map<String,
Object>). This follows the RangerDataMaskPolicyItem /
RangerPolicyItemDataMaskInfo pattern.
dedupStrings on the constraint info dedups both parameter keys and String
values.
Example service-def:
"constraintDefs": [{
"itemId": 1, "name": "requireApproval", "label": "Require approval",
"resources": ["tool"], "accessTypes": ["execute"],
"parameters": [{ "itemId": 1, "name": "approver", "label": "Approver",
"type": "user", "mandatory": true }]
}]
Example policy:
"policyType": 4,
"constraintPolicyItems": [{
"groups": ["finance-users"],
"accesses": [{ "type": "execute", "isAllowed": true }],
"conditions": [{ "type": "expression", "values": ["ATTR.trx_amount >
10000"] }],
"constraintInfo": { "constraintName": "requireApproval", "parameters": {
"approver": "finance-approvers" } }
}]
Not in this change. These are follow-up sub-tasks:
Admin persistence and validation (DB schema for constraintDefs)
policy-engine evaluation
supported-constraint registration, and denying requests with unsupported
constraints
audit
authz-api/PDP result
policy UI
plugin capability gating
Points for review:
One constraint per policy item, as with data masks, rather than a list per
item.
resources / accessTypes in RangerConstraintDef are plain names, rather than
full RangerResourceDef / RangerAccessTypeDef objects as in dataMaskDef.
Which parameter type values to support, e.g. string, int, boolean, user,
group, role.
## How was this patch tested?
New tests in the existing model test classes:
TestRangerServiceDef.test14_ConstraintDefsJsonRoundTrip covers:
JSON parsing and round-trip of constraintDefs;
service-def JSON without constraintDefs deserializes, and the field isn’t
written when empty;
null-safe setters, copy constructors, updateFrom, equals/hashCode, toString,
normalize() and dedupStrings.
TestRangerPolicy.test13_ConstraintPolicyItemsAndJson covers:
POLICY_TYPE_CONSTRAINTS is not in POLICY_TYPES;
JSON parsing and round-trip of constraintPolicyItems, with unknown fields
ignored;
access-policy JSON doesn’t include the new field;
updateFrom, equals/hashCode, toString, and dedup of parameter keys and
values.
TestRangerPolicy.test09 is extended for the V2 null-safe supplier.
--
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]
