[jira] [Updated] (RANGER-5852) Admin: support constraint policies (policyType 4)

["Vyom Mani Tiwari (Jira)" <ji...@apache.org>]

     [ 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)