hadoop-hdfs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dietrich, Paul" <paul.dietr...@honeywell.com>
Subject WebHDFS use of proxy to read encrypted file
Date Wed, 27 Jan 2016 17:41:40 GMT
I am using Apache Hadoop 2.7.1 with Kerberos SPNEGO authentication (i.e. security on) and data
at-rest encryption enabled. I am using Ranger 0.5.0 kms for the keyserver implementation.

My end goal is to allow users to browse files from within encryption zones for which they
are permitted using HUE.

Since I am using HUE, I have entered the configuration parameter hadoop.proxyusers.hue.users
to value '*' for now for testing.

Ignoring the HUE application for the moment and doing some testing, the behavior I see with
WebHDFS using curl to read an encrypted file is that whatever user tries to open the file
they get proxied to user hue. Here is the series of commands run as user 'paul' and /zone
was setup as an encryption zone using key 'testkey':
> kinit
> hdfs dfs -cat /zone/helloWorld
Hello World
> curl --tlsv1.2 -i --location-trusted --cacert /etc/pki /cacerts.pem --negotiate -u :

And the result:
not allowed to do 'DECRYPT_EEK' on 'testkey'"}}

If I instead run curl with a proxy request adding 'doas=paul' I get a somewhat expected result:
to obtain user group information: org.apache.hadoop.security.authorize.AuthorizationException:
User: paul is not allowed to impersonate paul"}}

>From that step it leads me to something related, but slightly disturbing. If I now add
hadoop.proxyusers.paul.users to value 'paul' allowing paul to proxy for paul it works, but
it works too well. Running the original curl command as user paul returns the file contents;
however, running the curl command as any other user also returns the file contents!

The audit log for kms shows the access, but it thinks every access is being done as user paul
2016-01-27 10:09:08,552 OK[op=DECRYPT_EEK, key=testkey, user=paul, accessCount=1, interval=10873ms]
The audit log for hdfs shows the access with the user performing the request shown:
2016-01-27 10:08:57,347 INFO FSNamesystem.audit: allowed=true   ugi=tom (auth:KERBEROS)  
  ip=/     cmd=open        src=/zone/helloWorld    dst=null        perm=null
2016-01-27 10:08:57,482 INFO FSNamesystem.audit: allowed=true   ugi=tom (auth:TOKEN)     
  ip=/      cmd=open        src=/zone/helloWorld    dst=null        perm=null

I'm not sure where to dig in to find what exactly is going on, so if someone knows if this
is expected behavior or where to start looking that would be a great help. Thanks.


To unsubscribe, e-mail: user-unsubscribe@hadoop.apache.org
For additional commands, e-mail: user-help@hadoop.apache.org

View raw message