HDP YARN + Ranger misconfiguration: how to debug

[Willemina Konynenberg <Wi...@actian.com>]

Hi all,

For reference: I am new to actual hands on administration of hadoop (mostly been using setups managed by others so far), so I may well be overlooking the utterly obvious...

I have installed an experimental hadoop cluster using the centos6 2.4.2.0 repos from hortonworks. (/usr/hdp/2.4.2.0-258)

After getting things up & running and confirming that things work as expected, I installed Ranger and started configuring that.
Activating the Ranger plugin for HDFS worked as expected, and after disabling the fallback I could verify that suitable policies in Ranger have the expected effect on HDFS users.
I then tried to activate the Ranger plugin for YARN.  It took me some time to work out that YARN, too, has a fallback option, yarn.acl, which I needed to disable.  But even after that, it would appear that YARN happily allows any request, regardless of whether there is any Ranger policy to actually allow it.

I looked at the Ranger/YARN audit files, and saw that both before and after disabling yarn.acl.enable, there are entries suggesting that requests are being allowed by the yarn.acl enforcer. (resource:root.default, action:submit-app, result:1, enforcer:yarn-acl, ...)
I suspect this means that setting yarn.acl.enable to false in the ambari console and then restarting the affected services has not been enough to actually get YARN to not fall back to its own internal access controls.

Basically, I want to confirm that Ranger works as intended by verifying that when a user has no suitable policy rule in Ranger, it will not get the corresponding access rights from that service.

I have been hunting around the various log files and what not, but can't figure out what might be misconfigured, or how I might go about  debugging this issue.  There are just too many as yet unknown files & components at play for me to work out where to start.

Any hints greatly appreciated.

Regards,

Willy Konynenberg