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

Umesh Patil updated ATLAS-5388:
-------------------------------
    Description: 
h2. Problem Statement

 
REST hook notification ingress (rest-notification-webapp, port 41000) 
authorizes POST requests using an *admin-shaped* privilege 
({{{}service-notification-post{}}}) via {{{}AtlasAdminAccessRequest{}}}. The 
{{topicName}} URL path parameter (e.g. {{{}ATLAS_HOOK{}}}, 
{{{}ATLAS_ENTITIES{}}}) is used for Kafka routing.
 
This creates a security and policy-model gap:
 * Authorization cannot enforce least privilege per notification topic
 * A caller granted admin notification permission can POST to *any* topic
 * Hook service accounts cannot be scoped to a single topic (e.g. {{hivehook}} 
→ {{ATLAS_HOOK}} only)
 * No first-class resource type {{notification-topic}} exists for Ranger policy 
modeling
 * Privilege {{service-notification-post}} was never properly wired in Ranger 
Atlas service-def
 
h2. Security Impact

 
 * Violates principle of least privilege for hook/service accounts
 * Inconsistent with entity/type authorization model (which is resource-scoped)
 * REST notification APIs as potentially allowing unauthorized message injection
 * Production Ranger deployments cannot create topic-scoped policies until 
Ranger plugin is updated (follow-up)
 
h2. Affected Endpoint

 
{code:java}
POST http://<host>:41000/rest/api/atlas/v2/notification/topic/\{topicName}
{code}
 
 * {{topicName}} examples: {{{}ATLAS_HOOK{}}}, {{ATLAS_ENTITIES}}
 

h2. Root Cause (
 
|| Area ||  Broken Design ||
| Request type | \{{AtlasAdminAccessRequest}} |
| Privilege checked | \{{SERVICE_NOTIFICATION_POST}} 
(\{{service-notification-post}}) |
| Topic in auth decision | *No* — \{{topicName}} ignored |
| Simple policy section | No \{{notificationPermissions}} in 
\{{atlas-simple-authz-policy.json}} |
| Ranger resource type | No \{{notification-topic}} in service-def |  
 
*authorization call in NotificationREST:*
{code}
verifyAccess(new AtlasAdminAccessRequest(SERVICE_NOTIFICATION_POST), ...)
{code}


 
 
 

  was:
h2. Problem Statement

 
REST hook notification ingress (rest-notification-webapp, port 41000) 
authorizes POST requests using an *admin-shaped* privilege 
({{{}service-notification-post{}}}) via {{{}AtlasAdminAccessRequest{}}}. The 
{{topicName}} URL path parameter (e.g. {{{}ATLAS_HOOK{}}}, 
{{{}ATLAS_ENTITIES{}}}) is used for Kafka routing.
 
This creates a security and policy-model gap:
 * Authorization cannot enforce least privilege per notification topic
 * A caller granted admin notification permission can POST to *any* topic
 * Hook service accounts cannot be scoped to a single topic (e.g. {{hivehook}} 
→ {{ATLAS_HOOK}} only)
 * No first-class resource type {{notification-topic}} exists for Ranger policy 
modeling
 * Privilege {{service-notification-post}} was never properly wired in Ranger 
Atlas service-def
 
h2. Security Impact

 

 * Violates principle of least privilege for hook/service accounts
 * Inconsistent with entity/type authorization model (which is resource-scoped)
 * REST notification APIs as potentially allowing unauthorized message injection
 * Production Ranger deployments cannot create topic-scoped policies until 
Ranger plugin is updated (follow-up)
 
h2. Affected Endpoint

 
{code:java}
POST http://<host>:41000/rest/api/atlas/v2/notification/topic/\{topicName}
{code}
 

 * {{topicName}} examples: {{{}ATLAS_HOOK{}}}, {{ATLAS_ENTITIES}}
 


> REST notification POST authorization is admin-level and not topic-scoped, 
> topicName path parameter is ignored in auth decision
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ATLAS-5388
>                 URL: https://issues.apache.org/jira/browse/ATLAS-5388
>             Project: Atlas
>          Issue Type: Bug
>          Components:  atlas-core
>    Affects Versions: 3.0.0
>            Reporter: Umesh Patil
>            Assignee: Umesh Patil
>            Priority: Major
>
> h2. Problem Statement
>  
> REST hook notification ingress (rest-notification-webapp, port 41000) 
> authorizes POST requests using an *admin-shaped* privilege 
> ({{{}service-notification-post{}}}) via {{{}AtlasAdminAccessRequest{}}}. The 
> {{topicName}} URL path parameter (e.g. {{{}ATLAS_HOOK{}}}, 
> {{{}ATLAS_ENTITIES{}}}) is used for Kafka routing.
>  
> This creates a security and policy-model gap:
>  * Authorization cannot enforce least privilege per notification topic
>  * A caller granted admin notification permission can POST to *any* topic
>  * Hook service accounts cannot be scoped to a single topic (e.g. 
> {{hivehook}} → {{ATLAS_HOOK}} only)
>  * No first-class resource type {{notification-topic}} exists for Ranger 
> policy modeling
>  * Privilege {{service-notification-post}} was never properly wired in Ranger 
> Atlas service-def
>  
> h2. Security Impact
>  
>  * Violates principle of least privilege for hook/service accounts
>  * Inconsistent with entity/type authorization model (which is 
> resource-scoped)
>  * REST notification APIs as potentially allowing unauthorized message 
> injection
>  * Production Ranger deployments cannot create topic-scoped policies until 
> Ranger plugin is updated (follow-up)
>  
> h2. Affected Endpoint
>  
> {code:java}
> POST http://<host>:41000/rest/api/atlas/v2/notification/topic/\{topicName}
> {code}
>  
>  * {{topicName}} examples: {{{}ATLAS_HOOK{}}}, {{ATLAS_ENTITIES}}
>  
> h2. Root Cause (
>  
> || Area ||  Broken Design ||
> | Request type | \{{AtlasAdminAccessRequest}} |
> | Privilege checked | \{{SERVICE_NOTIFICATION_POST}} 
> (\{{service-notification-post}}) |
> | Topic in auth decision | *No* — \{{topicName}} ignored |
> | Simple policy section | No \{{notificationPermissions}} in 
> \{{atlas-simple-authz-policy.json}} |
> | Ranger resource type | No \{{notification-topic}} in service-def |  
>  
> *authorization call in NotificationREST:*
> {code}
> verifyAccess(new AtlasAdminAccessRequest(SERVICE_NOTIFICATION_POST), ...)
> {code}
>  
>  
>  



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

Reply via email to