[GitHub] [atlas] arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization
arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization URL: https://github.com/apache/atlas/pull/58#issuecomment-502993992 @mneethiraj is there something more that should be done here? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [atlas] arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization
arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization URL: https://github.com/apache/atlas/pull/58#issuecomment-500495097 > 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 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [atlas] arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization
arempter commented on issue #58: [ATLAS-3261] Set kafka user as current principal for Ranger Authorization URL: https://github.com/apache/atlas/pull/58#issuecomment-500199699 > @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. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
