About andrew_ryan1

andrew_ryan1 · ‎08-14-2019

Thanks Josh, I'll enable kerberos and retry. I'll let you know how I go.

andrew_ryan1 · ‎08-08-2019

I am upgrading our cluster to HDP 3.0.1. I have installed ranger (1.1.0) and enabled the hbase plugin. (Other plugins are working as expected - hdfs, knox etc) All requests to hbase with _any_ user are being run as the root user. This is true through either knox or a direct call to hbase using curl. I do not have kerberos enabled as yet. Has anyone seen this before?

andrew_ryan1 · ‎11-29-2018

@Matthew Shipton Hi Matthew, I have a similar requirement. ManifoldCF will do what you need as far as I know. It didn't seem to be a very active project however. Ranger (0.7.0) has a solr plug-in which provides access control at the collection level and I believe it also requires Kerberos to be enabled to work. For us this requirement means we need to implement a cross realm trust with our MS domains to get to the solr UI and it starts getting complex requiring the involvement of multiple external teams. The approach I am currently pursuing is a proxy to intercept the rest calls and insert a filter query param.The solr documents need to have an attribute with the values and you can filter on those. I'm not sure if this is what is meant by "hooks and bridges" I am looking at using Lucidworks Fusion at the moment. I'm not entirely certain but I think it is a commercialised version of ManifoldCF. If this doesn't work out I'll probably end implementing a wrapper for Solr that does what I need. If you come across any better solution please share. Hope this helps Cheers

andrew_ryan1 · ‎10-29-2018

@Mike Wong I had an issue similar when I enabled SSL on HDFS. Map Reduce and YARN. Symptoms: I could connect to HDFS rest interface from the command line internal to the cluster using curl I could run the UI for HDFS from internal to the cluster using xwindows enabled putty an XMing OpenSSL form internal returned 0 for the HDFS connection No external connection to the could be made using curl/openssl/telnet to HDFS The ResourceManager and JobHistory UI's both worked fine We had a firewall but even when disabled the connection to HDFS failed The issue was that we have 'internal network IP addresses (infiniband)' and externally accessible IP addresses. The HDFS when enabling https had bound to the internal address and wasn't listening on the external address - hence the connection refused. The solution was to add the dfs.namenode.https-bind-host=0.0.0.0 property to get the service to listen across all network interfaces. Might be worth checking if you (or anybody else that gets a connection refused errors) that have multiple network interfaces, to which the port is binding to. netstat -nlp | grep 50470 tcp　　　　　　　 0　　　　　 0 <internal IP address>:50470　　　　　　　　0.0.0.0:*　　　　　　　　　　　　　　 LISTEN　　　　　 23521/java netstat -nlp | grep 50070 tcp　　　　　　　 0　　　　　 0 0.0.0.0:50070　　　　　　　　　　 0.0.0.0:*　　　　　　　　　　　　　　 LISTEN　　　　　 23521/java

andrew_ryan1 · ‎08-30-2018

As far as I know there is no way around the issue except to get the example.com name added to the certificate as a subject alt name. TLS implementations have become more strictly enforced over the years. As anyone who has configured against NiFi will attest. Adding the subject alt name shouldn't be an issue except for the fact that the certificates are self signed instead of having a issuer chain. This means that all relying applications would need to update their trust stores with the new certificate/s. Your AD team should be using a chain rather than self signed because this will also cause problems when the self signed certificates expire.

andrew_ryan1 · ‎01-08-2018

Hi all, I'm am trying to configure the ranger-solr-plugin to work with knox authentication in the Sandbox 2.6.0. I'm using Solr 7.1, Knox 0.12.0 and Ranger 0.7 . Kerberos is enabled. The ranger-solr-plugin works fine with a direct connection (kerberos authentication) to solr using a cURL request. When I submit a cURL request I get a 401 "Authentication required" error. The Solr logs show that the credentials passed through by Knox are the basic auth credentials (that were passed to Knox) when Solr is expecting kerberos authentication. Any advice appreciated. solr logs: 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel REQUEST for //sandbox.hortonworks.com:8443/solr/techproducts/query?q=* on HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} GET //sandbox.hortonworks.com:8443/solr/techproducts/query?q=* HTTP/1.1 X-Forwarded-For: 172.17.0.2 X-Forwarded-Proto: https X-Forwarded-Port: 8443 X-Forwarded-Host: sandbox.hortonworks.com:8443 X-Forwarded-Server: sandbox.hortonworks.com X-Forwarded-Context: /gateway/default Authorization: Basic dG9tOnRvbS1wYXNzd29yZA== User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2^M Host: sandbox.hortonworks.com:8443 Accept: */* Connection: keep-alive Accept-Encoding: gzip,deflate 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} onContentComplete 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} onRequestComplete 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpInput HttpInputOverHTTP@2e0a216d[c=0,q=1,[0]=EOF,s=STREAM] addContent EOF 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpConnection HttpConnection@380a76ec[SelectChannelEndPoint@689b879d{/172.17.0.2:50568<->9041,Open,in,out,-,-,1/120000,HttpConnection@380a76ec}{io=1/0,kio=1,kro=1}][p=HttpParser{s=END,0 of -1},g=HttpGenerator@c99a91f{s=START},c=HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*}] parsed true HttpParser{s=END,0 of -1} 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpConnection releaseRequestBuffer HttpConnection@380a76ec[SelectChannelEndPoint@689b879d{/172.17.0.2:50568<->9041,Open,in,out,-,-,1/120000,HttpConnection@380a76ec}{io=1/0,kio=1,kro=1}][p=HttpParser{s=END,0 of -1},g=HttpGenerator@c99a91f{s=START},c=HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*}] 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} handle //sandbox.hortonworks.com:8443/solr/techproducts/query?q=* 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannelState HttpChannelState@275bce0{s=IDLE a=NOT_ASYNC i=true r=NONE/false w=false} handling IDLE 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=DISPATCHED,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} action DISPATCH 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.Server REQUEST GET /solr/techproducts/query on HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=DISPATCHED,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*} 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.h.ContextHandler scope null||/solr/techproducts/query @ o.e.j.w.WebAppContext@7d70d1b1{/solr,file:///opt/solr-7.1.0/server/solr-webapp/webapp/,AVAILABLE}{/opt/solr-7.1.0/server/solr-webapp/webapp} 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.h.ContextHandler context=/solr||/techproducts/query @ o.e.j.w.WebAppContext@7d70d1b1{/solr,file:///opt/solr-7.1.0/server/solr-webapp/webapp/,AVAILABLE}{/opt/solr-7.1.0/server/solr-webapp/webapp} 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.session sessionManager=org.eclipse.jetty.server.session.HashSessionManager@2a556333 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.session session=null 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler servlet /solr|/techproducts/query|null -> default@5c13d641==org.eclipse.jetty.servlet.DefaultServlet,jsp=null,order=0,inst=true 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler chain=SolrRequestFilter->default@5c13d641==org.eclipse.jetty.servlet.DefaultServlet,jsp=null,order=0,inst=true 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler call filter SolrRequestFilter 2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.a.h.s.a.s.AuthenticationFilter Request [http://sandbox.hortonworks.com:8443/solr/techproducts/query?q=*] triggering authentication 2018-01-08 03:39:43.697 WARN (qtp42121758-16) [ ] o.a.h.s.a.s.KerberosAuthenticationHandler 'Authorization' does not start with 'Negotiate' : Basic dG9tOnRvbS1wYXNzd29yZA== 2018-01-08 03:39:43.698 DEBUG (qtp42121758-16) [ ] o.e.j.s.ErrorPageErrorHandler getErrorPage(GET /solr/techproducts/query) => error_page=null (from global default)

andrew_ryan1 · ‎11-14-2016

Hi All, I have a question regarding the common name attribute of key stores when enabling SSL for HDFS,MapReduce and Yarn along with Ranger HDFS plugin. I have read articles that state that the common name needs to be identical across the cluster for the keystores for the xasecure.policymgr.clientssl.keystore key store. This key store seems to be responsible for protecting the Ranger console so when not set to the FQDN of the console server breaks the Ranger console. https://community.hortonworks.com/articles/16373/ranger-ssl-pitfalls.html If this configuration is set then the journal nodes complain about the common name in the certificate not being the same as the hostname. Additionally, the configuration item common.name.for.certificate in hdfs-site.xml and the "Common Name for Certificate" value in the ranger plug-in policies implies that a single common name is required in all keystores across the cluster. response={"httpStatusCode":400,"statusCode":1,"msgDesc":"Unauthorized access. No common name for certificate set. Please check your service config","messageList":[{"name":"OPER_NOT_ALLOWED_FOR_ENTITY","rbKey":"xa.error.oper_not_allowed_for_state","message":"Operation not allowed for entity"}]}, serviceName=<clusterName>_hadoop If the key stores have the FQDN set then the name nodes throw an SSLException. javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching <hostname> found I am probably missing something. Do I need two distinct sets of keystores? One with an identical common name and one set with the FQDN for each host? Or should I be using a common subject alt name in the certificates?

andrew_ryan1 · ‎10-23-2016

@Divya Anugu Hi Divya, It is definitely possible to configure Hive2Server. I have personally set it up successfully between knox and hive. I documented the instructions and have attached them below. The instructions are for an active and a standby name node. Once you have obtained a pfx/p12 file containing a private key and a certificate for the machines names* you are securing you can begin the installation enabling process. *The certificate securing the server MUST have a common name segment of its Distinguished Name identical to the URL used to connect to the server. Installing keys and certificates Once you have the correctly named keys you can begin the installation/enablement of SSL. Firstly, the Hive server requires the java key store format (jks) The pfx/p12 files that you have must converted to jks format using the java keytool utility. keytool -importkeystore -srckeystore namenode1.pfx -destkeystore hbase.jks -srcstoretype pkcs12 -deststoretype JKS keytool -importkeystore -srckeystore namenode2.pfx -destkeystore hbase.jks -srcstoretype pkcs12 -deststoretype JKS Once you have created the jks you can view the certificates and keys using the keytool list command. keytool -list -v -keystore hbase.jks To allow the trust chain to validated by the client connecting to the service the issuing certificates need to be accessible to the client. In the case of a web client the certificates are added to the browser certificate store. In the case of the knox proxy (which is what we are configuring for full end-to-end SSL) we need to add the issuing certificates to the java trust store for the jvm that knox is running on. To establish which jvm this is run ps -ef | grep -i knox. Go to the jre/lib/security folder and add the full certificate issuing chain (you don't need to add the server certificate - only the issuers) to the cacerts file using the java keytool command: keytool -import -trustcacerts -alias GatekeeperTestRoot -file /home/uname/SSL/GK2RootCATest.cer -keystore <java_running_knox>/jre/lib/security/cacerts keytool -import -trustcacerts -alias GatekeeperTestIntermediate -file /home/uname/SSL/GK2IntermediateCATest.cer -keystore / <java_running_knox>/jre/lib/security/cacerts Enabling SSL for HIVE through Ambari Next we enable SSL on the Hive server through Ambari. Add the following settings to hive-site.xml through the Ambari -> HIVE -> configs -> Advanced ->Custom hive-site Nb. hive.server2.use.SSL is a toggle switch under Ambari -> HIVE -> configs->Use SSL <property> <name>hive.server2.use.SSL</name> <value>true</value> </property> <property> <name>hive.server2.keystore.password</name> <value>password</value></property> <property> <name>hive.server2.keystore.path</name> <value>/usr/hdp/current/hive-server2/conf/hbase.jks</value> </property> Save the properties and restart Hive Updating Knox service Mapping The final step is to modify the Knox topology Hive service mapping from http to https Ambari->knox->Advanced topology <service> <role>HIVE</role> <url>https://<namenode>:10000/cliservice</url> </service> Save the properties and restart Knox

andrew_ryan1 · ‎10-20-2016

@Divya Anugu Hi Divya, I'd be surprised if ther were actually no cipher suites in common. You can debug your SSL connection using openSSL Try running this from a terminal openssl s_client -CAfile <path to file self signed certificate in pem format> -connect servername:port -state You'll need to convert your cerificate file into PEM format if you haven't already openssl x509 -inform DER -in <inputCertInDERformat> -outform PEM -out <outputCertInPEMformat> Post the output and it will hopefully show a more meaningful error message Cheers

andrew_ryan1 · ‎10-20-2016

You need to export the certificate from the jks store. keytool -export -alias mydomain -file mydomain.crt -keystore keystore.jks You can list the aliases with keytool -list -v -keystore keystore.jks

andrew_ryan1 · ‎10-19-2016

@Divya Anugu Hi Divya, Try adding the certificate to System roots in keychain. Cheers

andrew_ryan1 · ‎10-19-2016

@Divya Anugu Hi Divya, I don't have a copy of client Tableau client but the error indicates that the trust point on the client side is not set up correctly. The client side is unable to verify the certificate presented by the server. Are you running Tableau form a MS platform? If so try adding the self-signed certificate file (.crt not the pfx/p12 file) to the Trusted root certification authorities tab using certmgr.msc from a dos prompt. Cheers

andrew_ryan1 · ‎10-19-2016

@Divya Anugu Hi Divya Have you configured the self signed certificate in the tableau SSL trust store? https://onlinehelp.tableau.com/current/server/en-us/ssl_config.htm Cheers Andrew

andrew_ryan1 · ‎10-05-2016

Knox_sample also works now

andrew_ryan1 · ‎10-05-2016

@mrizvi I downloaded the 2.5 sandbox and got the same issue as you describe. The problem seems to be the directory for previous deployments can't be deleted and this causes the service for the topologies to fail to start. I eventually got mine working by moving all of the topology xml files out of /usr/hdp/current/knox-server/conf/topologies and restarting knox. It automatically populates the default, knoxsso and admin files back into the folder. I was able to list the files using the default topology. I moved the knox_sample.xml back into the folder and did another restart. It failed to start due to the temp folder being unable to be deleted. So I catted the knox_sample.xml into another file knox_sample2.xml and restarted again. I was able to list the files through knox_sample2. It is more of a work around than anything else. I don't know why the temp folder can't be deleted. I couldn't delete the folder manually and when I tried I got an invalid argument error rmdir /var/lib/knox/data-2.5.0.0-1245/deployments/knoxsso.topo.157239f6c28/%2Fknoxauth/META-INF/temp/jsp rmdir: failed to remove `jsp/': Invalid argument

andrew_ryan1 · ‎09-30-2016

It's a different error from the gateway logs in the attached log file for the link I posted. So it probably isn't your issue. This command requires a running instance of Knox to be present on the same machine. It will execute a test to make sure all services are accessible through the gateway URLs. Errors are reported and suggestions to resolve any problems are returned. JSON formatted. I'm confused now. This implies that knox isn't running. But the results for the user auth test say that it is. I'm running 2.4 so I will try to setup 2.5 over the weekend for myself. Do you have ranger enabled with knox? Can you post the gateway.log error with debug enabled for when you make your curl request? Cheers

andrew_ryan1 · ‎09-30-2016

@mrizvi Quite alright. Maybe a long shot but I found this post with a similar issue to the one you are experiencing. service unavailable

andrew_ryan1 · ‎09-30-2016

Might be a good idea to check if you have any knox zombies running. They can hang on to files and prevent deletes. ps -ef | grep -i knox

andrew_ryan1 · ‎09-30-2016

@mrizvi I don't get that warning so it may be significant. I'm not sure. If I had to hazard a guess as to why it's failing to delete it's either a path or file permissions issue. Can you post the whole log? Also can you try a few tests with the /usr/hdp/current/knox-server.bin/knoxcli.sh utility? It might provide a bit more meaningful info. ./knoxcli.sh service-test --cluster knox_sample --u guest -p guest-password --hostname sandbox.hortonworks.com --port 8443 --cluster knox_sample ./knoxcli.sh user-auth-test --cluster knox_sample --u guest --p guest-password --hostname sandbox.hortonworks.com --port 8443 --cluster knox_sample

andrew_ryan1 · ‎09-29-2016

@mrizvi I would bump up the log levels for the gateway to DEBUG through Ambari as a next step. In the knox advanced tab for gateway log4j change log4j.rootLogger=ERROR, drfa to log4j.rootLogger=DEBUG, drfa Then submit a curl request check the gateway.log. There will be a lot of output so search for 'guest'.

andrew_ryan1 · ‎09-29-2016

@mrizvi Apologies, format issues I think. Try this one.knox-sample.xml

andrew_ryan1 · ‎09-29-2016

@mrizvi No worries. Can you contact the service without knox? curl -i -v -k -u guest:guest-password 'http://sandbox.hortonworks.com:50070/webhdfs/v1/?op=LISTSTATUS' I have attached a topology file that currently works on my sandbox for you to compare. Cheers

andrew_ryan1 · ‎09-29-2016

This issue was resolved by updating the zookeeper jaas config to use a keytab rather than a ticket cache. The cache was expiring and the auth failing. I thing that I've learned is that the updated configs can take a while to propagate through the cluster. I had tried this config before but likely didn't wait long enough before discounting it as the solution. Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true useTicketCache=false keyTab="/etc/security/keytabs/hbase.service.keytab" principal="hbase/<your_host>@<your_realm>"; };

andrew_ryan1 · ‎09-28-2016

@mrizvi A couple of things to check would be your knox_sample topology has the service mapping to webhdfs <service> <role>WEBHDFS</role> <url>http://sandbox:50070/webhdfs</url> </service> and the webhdfs server is listening on that port netstat -nl | grep 50070 Take a look at your knox logs as well - they may have some extra info. /usr/hdp/current/knox-server/logs/gateway.log Cheers

andrew_ryan1 · ‎09-23-2016

zookeeperlog-startup.txt Update: The above configuration now functions after a few service restarts. However I am now experiencing another issue. Requests to HBase rest now timeout after the specified number of client retries with a HTTP error of service unavailable. The Zookeeper logs indicate the failure to establish a quorum. I have attached a log excerpt of the log file. I have three nodes. Zookeeper is running on both other nodes according to Ambari. Has anyone come across this problem before? I have read some info that it may be related to DNS set up but have so far had no success. 2016-09-23 08:29:51,812 - DEBUG [QuorumPeer[myid=2]/0:0:0:0:0:0:0:0:2181:FastLeaderElection@609] - id: 3, proposed id: 3, zxid: 0x73000079ea, proposed zxid: 0x73000079ea 2016-09-23 08:29:51,814 - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2016-09-23 08:29:51,814 - DEBUG [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@366] - IOException stack trace java.io.IOException: ZooKeeperServer not running at org.apache.zookeeper.server.NIOServerCnxn.readLength(NIOServerCnxn.java:931) at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:237) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208) at java.lang.Thread.run(Thread.java:745) 2016-09-23 08:29:51,816 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1007] - Closed socket connection for client /34.45.6.3:34139 (no session established for client) 2016-09-23 08:29:51,816 - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2016-09-23 08:29:51,816 - DEBUG [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@366] - IOException stack trace java.io.IOException: ZooKeeperServer not running at org.apache.zookeeper.server.NIOServerCnxn.readLength(NIOServerCnxn.java:931) at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:237) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208) at java.lang.Thread.run(Thread.java:745) 2016-09-23 08:29:51,816 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1007] - Closed socket connection for client /34.45.6.2:60031 (no session established for client) 2016-09-23 08:29:51,817 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@197] - Accepted socket connection from /34.45.6.2:60032 2016-09-23 08:29:51,817 - DEBUG [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperSaslServer@78] - serviceHostname is 'namenode_1' 2016-09-23 08:29:51,817 - DEBUG [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperSaslServer@79] - servicePrincipalName is 'zookeeper' 2016-09-23 08:29:51,817 - DEBUG [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperSaslServer@80] - SASL mechanism(mech) is 'GSSAPI'

andrew_ryan1 · ‎09-14-2016

Hi all, I am trying to configure HBase rest to allow proxying of users. I have the Ranger HBase plugin enabled to provide the HBase ACLs. I am able to retrieve resources successfully from the repository using curl commands however the "doAs" proxying doesn't appear to be working. The Ranger audit logs show all operations being performed by the proxy user HTTP rather than the impersonated user. I have configured the hbase-site.xml file with the following additional settings to support impersonation. hadoop.proxyuser.HTTP.groups: hadoop hadoop.proxyuser.HTTP.hosts: * hadoop.security.authorization: true hbase.rest.authentication.kerberos.keytab: /etc/security/keytabs/hbase.service.keytab hbase.rest.authentication.kerberos.principal: HTTP/_HOST@<REALM> hbase.rest.authentication.type: kerberos hbase.rest.kerberos.principal: hbase/_HOST@<REALM> hbase.rest.keytab.file: /etc/security/keytabs/hbase.service.keytab hbase.rest.support.proxyuser: true I have added an HTTP user to ranger and the user to an HBase policy giving 'RWCA' access and have added the same priveleges to HTTP on HBase: grant 'HTTP' 'RWCA'. I am using the following curl command to query HBase. curl -ivk --negotiate -u : -H "Content-Type: application/octet-stream" -X GET "http://<namenode>:60080/<resource>/234998/d:p?doAs=hadoopuser1" -o test4.jpg I was expecting that ranger would apply the ACLs of the user being impersonated by the proxy user to limit access and provide audit logging in the same way as the webhdfs plugin. Is this possible? If so am I missing something in my configuration? Any advice appreciated. Regards Andrew

Online	Offline
Last Visited	‎08-15-2019 07:14 PM

Date Registered	‎09-05-2016 09:56 PM
Last Visited	‎08-15-2019 07:14 PM
Total Messages Posted	26
Total Kudos Received	7

Re: Kerberos ldaps subject alternative DNS name

Re: Not able to access WebHDFS via Knox in the San...

Re: Hbase rest proxying

Re: Ranger hbase plugin not proxying users. Runs e...

Ranger hbase plugin not proxying users. Runs every...

Re: Row level security in SOLR using Atlas/Ranger

Re: Connection failed: [Errno 111] Connection refu...

Re: Kerberos ldaps subject alternative DNS name

Why is Knox is passing though basic authentication...

Enabling SSL for HDFS, MapReduce and Yarn

Re: Enable SSL for spark thrift server

Re: Enable SSL for spark thrift server

Re: Enable SSL for spark thrift server

Re: Enable SSL for spark thrift server

Re: Enable SSL for spark thrift server

Re: Enable SSL for spark thrift server

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Not able to access WebHDFS via Knox in the San...

Re: Hbase rest proxying

Re: Not able to access WebHDFS via Knox in the San...

Re: Hbase rest proxying

Hbase rest proxying