[ 
https://issues.apache.org/jira/browse/RANGER-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyom Mani Tiwari updated RANGER-5852:
-------------------------------------
    Description: 
Allow constraint policies ({{{}POLICY_TYPE_CONSTRAINTS{}}}, with 
{{{}constraintPolicyItems{}}}) to be created, validated, stored and downloaded 
by plugins through Ranger Admin.

_Scope_
 * *Validation* ({{{}RangerPolicyValidator{}}}):
 ** accept type 4 only when the service def has constraintDefs;
 ** each item’s {{constraintName}} must exist in the service def;
 ** policy resources must fit the hierarchies from 
{{{}getResourceHierarchiesForConstraint(){}}};
 ** item access types must be in {{{}constraintDef.accessTypes{}}};
 ** mandatory parameters must be present, values must match their type, and 
unknown parameters are rejected;
 ** type-4 policies have no deny or exception items.
 * *Storage:* policies are stored as JSON in {{{}x_policy.policy_text{}}}, so 
confirm {{constraintPolicyItems}} round-trip. {{PolicyRefUpdater}} must add 
users, groups, roles and access types from constraint items to the ref tables, 
so that search, delete-user checks and reports work.
 * New ref table {{x_policy_ref_constraint}} (policy_id, constraint_def_id, 
constraint_name), like {{{}x_policy_ref_datamask_type{}}}, populated by 
{{{}PolicyRefUpdater{}}}. It’s used to block removing or renaming a 
constraintDef that’s in use 
 * *REST, search and download:* filter by type 4. Include type-4 policies in 
{{ServicePolicies}} and in policy deltas sent to plugins. Handle them in 
import/export.
 * *Zones:* constraint policies in security zones should behave the same as 
access policies.

  was:
Allow constraint policies ({{{}POLICY_TYPE_CONSTRAINTS{}}}, with 
{{{}constraintPolicyItems{}}}) to be created, validated, stored and downloaded 
by plugins through Ranger Admin.

_Scope_
 * *Validation* ({{{}RangerPolicyValidator{}}}):
 ** accept type 4 only when the service def has constraintDefs;
 ** each item’s {{constraintName}} must exist in the service def;
 ** policy resources must fit the hierarchies from 
{{{}getResourceHierarchiesForConstraint(){}}};
 ** item access types must be in {{{}constraintDef.accessTypes{}}};
 ** mandatory parameters must be present, values must match their type, and 
unknown parameters are rejected;
 ** type-4 policies have no deny or exception items.
 * *Storage:* policies are stored as JSON in {{{}x_policy.policy_text{}}}, so 
confirm {{constraintPolicyItems}} round-trip. {{PolicyRefUpdater}} must add 
users, groups, roles and access types from constraint items to the ref tables, 
so that search, delete-user checks and reports work.
 * *REST, search and download:* filter by type 4. Include type-4 policies in 
{{ServicePolicies}} and in policy deltas sent to plugins. Handle them in 
import/export.
 * *Zones:* constraint policies in security zones should behave the same as 
access policies.


> Admin: support constraint policies (policyType 4)
> -------------------------------------------------
>
>                 Key: RANGER-5852
>                 URL: https://issues.apache.org/jira/browse/RANGER-5852
>             Project: Ranger
>          Issue Type: New Feature
>          Components: admin
>            Reporter: Vyom Mani Tiwari
>            Assignee: Vyom Mani Tiwari
>            Priority: Major
>
> Allow constraint policies ({{{}POLICY_TYPE_CONSTRAINTS{}}}, with 
> {{{}constraintPolicyItems{}}}) to be created, validated, stored and 
> downloaded by plugins through Ranger Admin.
> _Scope_
>  * *Validation* ({{{}RangerPolicyValidator{}}}):
>  ** accept type 4 only when the service def has constraintDefs;
>  ** each item’s {{constraintName}} must exist in the service def;
>  ** policy resources must fit the hierarchies from 
> {{{}getResourceHierarchiesForConstraint(){}}};
>  ** item access types must be in {{{}constraintDef.accessTypes{}}};
>  ** mandatory parameters must be present, values must match their type, and 
> unknown parameters are rejected;
>  ** type-4 policies have no deny or exception items.
>  * *Storage:* policies are stored as JSON in {{{}x_policy.policy_text{}}}, so 
> confirm {{constraintPolicyItems}} round-trip. {{PolicyRefUpdater}} must add 
> users, groups, roles and access types from constraint items to the ref 
> tables, so that search, delete-user checks and reports work.
>  * New ref table {{x_policy_ref_constraint}} (policy_id, constraint_def_id, 
> constraint_name), like {{{}x_policy_ref_datamask_type{}}}, populated by 
> {{{}PolicyRefUpdater{}}}. It’s used to block removing or renaming a 
> constraintDef that’s in use 
>  * *REST, search and download:* filter by type 4. Include type-4 policies in 
> {{ServicePolicies}} and in policy deltas sent to plugins. Handle them in 
> import/export.
>  * *Zones:* constraint policies in security zones should behave the same as 
> access policies.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to