Umesh Patil created ATLAS-5388:
----------------------------------
Summary: 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
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 but is *not* evaluated during authorization.
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)
* PMC security review flagged 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}
POST http://<host>:41000/rest/api/atlas/v2/notification/topic/\{topicName}
{code}
* \{{topicName}} examples: \{{ATLAS_HOOK}}, \{{ATLAS_ENTITIES}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)