Vyom Mani Tiwari created RANGER-5845:
----------------------------------------
Summary: Supported-constraint registration: deny access when a
returned constraint is not supported by the caller
Key: RANGER-5845
URL: https://issues.apache.org/jira/browse/RANGER-5845
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Vyom Mani Tiwari
Assignee: Vyom Mani Tiwari
RANGER-5842 adds constraint-policy evaluation: when access is allowed, the
policy engine returns all matching constraints in
{{{}RangerAccessResult.getConstraintResults(){}}}. If a caller can’t enforce a
returned constraint (for example {{{}requireApproval{}}}), it might silently
ignore it. This sub-task adds a way for plugins and PDP callers to declare
which constraints they support. If a returned constraint isn’t supported, the
result becomes a deny.
_Proposed behavior_
* A plugin registers the names of the constraints it supports.
* After constraint evaluation in
{{{}RangerPolicyEngineImpl.evaluateConstraintPolicies{}}}, if any matched
constraint isn’t in the supported set:
** the result becomes a deny ({{{}isAllowed=false{}}}) with reason
{{{}unsupported constraint: <name>{}}};
** the constraint results are cleared;
** the deny is audited, with the policy id of the constraint policy.
* When nothing is registered, the plugin supports no constraints, so it fails
closed.
* A service with no constraint policies behaves as today.
_Open questions (for discussion before implementation)_
# *Registration mechanism:* a {{RangerBasePlugin}} API (e.g.
{{{}setSupportedConstraints(Set<String>){}}}), a per-service property (e.g.
{{{}ranger.plugin.<service>.supported.constraints=requireApproval,maxRows{}}}),
or both? Proposal: both, with config overriding the API.
# *Default when nothing is registered:* support none, so any returned
constraint is denied? Proposal: yes.
# *PDP / authz-api callers:* a shared PDP serves many callers, so a per-plugin
set doesn’t fit. Should callers declare support per request (e.g.
{{{}context.supportedConstraints{}}}), or per service in the PDP configuration?
Proposal: a request field, falling back to PDP config.
_Out of scope:_ Admin storage and validation of constraint policies, audit
schema changes beyond the deny reason, UI, and the authz-api response format
(separate sub-tasks).
_Testing:_ policy-engine JSON tests for:
* a supported constraint, which is allowed and returns its constraints;
* an unsupported constraint, which is denied with the reason;
* nothing registered, which is denied;
* a mix of supported and unsupported constraints, which is denied;
* no constraint policies, which leaves behavior unchanged;
* config and API registration, including precedence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
