atlas
atlas copied to clipboard
apache
[ATLAS-3261] Set kafka user as current principal for Ranger Authorization
If lineage message sent to ATLAS_HOOK has non empty "user" value, NotificationHookConsumer.java will set Authentication context to this user, allowing check in Ranger policies by Atlas authorizer.
Currently no user is set by NotificationHookConsumer, so Atlas authorizer is not invoked.
@arempter - the identity of the Kafka message producer is not available at the consumer side; Kafka doesn't support this. Though Atlas notification has a filed named 'user', this can't be used for authorization, as it trusts the senders to set correct value. Hence it is very important that ACLs on ATLAS_HOOKS Kafka topic is set carefully - to allow only trusted users to produce messages.
In short, notification mechanism must only be used for trusted users. For usecases that involve calls from untrusted users, which require authorizations, REST APIs should be used.
I completely agree, that there is no good way to guarantee that user name in message is correct and validated. I see it more like addition to topic ACL, which is main mechanism that grants access for posting messages. The issue with ACL is that is all-or-noting approach, without fine grained control of what user can do in atlas. On the other hand even if user will set any value for the user field, there is still external service (ranger policy) which is being checked and user cannot setup policy himself.
@arempter - I agree that authorizing based on username in the message can provide an additional layer of control. Given that authentication for each message is likely to add a sizable overhead, I would suggest to make this additional, per-message, authorization an option - controlled via a configuration like "atlas.notification.authorize.using.message.user". This will help avoid the overhead for deployments that don't need this additional layer of authorization control.
like "atlas.notification.authorize.using.message.user". This will help avoid the overhead for deployments that don't need this additional layer of authorization control.
Sure, updated parameter name
@bolkedebruin, @arempter - the patch looks good. I rebased this patch with latest master, and added caching of authentication objects; please review the updated patch at https://reviews.apache.org/r/71841/.