Member since
08-08-2013
339
Posts
132
Kudos Received
27
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
14817 | 01-18-2018 08:38 AM | |
1567 | 05-11-2017 06:50 PM | |
9181 | 04-28-2017 11:00 AM | |
3437 | 04-12-2017 01:36 AM | |
2830 | 02-14-2017 05:11 AM |
04-28-2017
06:02 PM
Hello @Vipin Rathor , thank you sooo much. Your hint with the FQDN did the trick. After putting the FQDN in the curl command, it works nice!
... View more
04-28-2017
11:34 AM
Hello, I am working on providing privileges to access Solr collection via Sentry-ACL. Environment is CDH5.9, Kerberos enabled, Sentry & Solr are up and running, Sentry roles have been configured and privileges are granted: 1 role for "Query"-ing the collection 1 role for "Update"-ing the collection 1 role for "All" privileges If I now login to Hue, and click "Search" => "Indizes" => <collection-name> => "Search" , then I can see all documents in the collection, _BUT_ this is the case for _ANY_ user. Even users which are not part of the (OS-)group that is assigned to a Sentry role can see all documents. This is something I didn't expect after having Sentry-ACLs in place...?!?! I just created a user 'test' within Hue, this user doesn't even exist as OS user, but he can see all documents from th SOLR collection. WHY ? If I login as user 'test' into Hue and click on "Search" => "Indizes", the Solr-log shows an (expected) error: ERROR org.apache.solr.core.SolrCore: org.apache.solr.common.SolrException: org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException: User test does not have privileges for admin but nevertheless, I can proceed clicking on the collection-name and then "Search" to see all the documents (which I didn't expect 😉 ). The Solr-log just shows: INFO org.apache.solr.core.SolrCore.Request: [...collection-name...] webapp=/solr path=/select params={hl.snippets=5&q=*:*&doAs=test&hl=true&fl=*&start=0&hl.fragsize=1000&hl.fl=*&rows=10&wt=json} hits=2 status=0 QTime=2 What am I missing here to _really_ protect the Solr collection from being accessed by everyone ?!?! The same behaviour can be reproduced by executing curl commandline calls by a user which has a valid kerberos ticket, but is _NOT_ part of any group which is part of a Sentry policy. All those users can select the collection, which shouldn't be the case. THanks in advance...
... View more
Labels:
04-28-2017
11:00 AM
at the end it turned out not to be a enctype issue 😉 The problem was that the hostname of the solr server in the curl URL did not match the hostname part of solr's kerberos principal. After putting the FQDN in the call: curl --negotiate -u : 'http://mgr-node1.test.demo:8983......... the error disappeard and everything works nice.
... View more
04-27-2017
11:12 PM
Hello @mbigelow , many thanks for your reply. Here the output : ## as user cloudera-scm: -bash-4.2$ klist -ef
Ticket cache: FILE:/tmp/krb5cc_995
Default principal: cloudera-scm@realm.demo
Valid starting Expires Service principal
04/28/2017 06:08:22 04/29/2017 06:08:22 krbtgt/realm.demo@realm.demo
renew until 05/05/2017 06:08:22, Flags: FRI
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 any ideas ?
... View more
04-27-2017
11:22 AM
1 Kudo
Hi, I am currently facing an issue at accessing SOLR collection via curl . Cluster is kerberized and working properly (HDFS/Hive/...), but while executing (after grabbing a kerberos ticket as user 'solr') e.g. curl --negotiate -u : 'http://mgr-node1:8983/solr/' I receive the following response: ...HTTP Status 403 - GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96)...
Keytab for user 'solr' contains: 2 27.04.2017 09:02:49 solr/<node>@<realm> (aes256-cts-hmac-sha1-96)
2 27.04.2017 09:02:49 solr/<node>@<realm> (des3-cbc-sha1) 2 27.04.2017 09:02:49 solr/<node>@<realm> (arcfour-hmac) 2 27.04.2017 09:02:49 solr/<node>@<realm> (des-hmac-sha1) MIT-KDC config contains this enctype as well: sudo cat /var/kerberos/krb5kdc/kdc.conf | grep supported_enctypes
supported_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 cat /etc/krb5.conf | grep _enctypes
default_tgs_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
default_tkt_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
permitted_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 What is going on there ? Any help highly appreciated...
... View more
Labels:
- Labels:
-
Apache Solr
04-27-2017
12:29 AM
Hello, I setup a mini-CDH-5.9 cluster and enabled Kerberos. Working with HDFS, Hive, Hbase is working fine, the only issue is that I cannot access my SOLR collection via curl command-line. Accessing SOLR collection via Hue is also working. If I execute e.g. curl --negotiate -u : 'http://mgr-node1:8983/solr/mycollection/select?q=*&wt=json&indent=true' after grabbing a Kerberos ticket , I receive the error: HTTP Status 403 - GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96) But this enctype is included in the keytab, as well as the supported enctypes in the MIT-KDC: Keytab: klist -e -kt /etc/security/cloudera-scm.keytab
Keytab name: FILE:/etc/security/cloudera-scm.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (aes256-cts-hmac-sha1-96)
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (aes128-cts-hmac-sha1-96)
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (des3-cbc-sha1)
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (arcfour-hmac)
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (des-hmac-sha1)
1 04/26/2017 21:21:22 cloudera-scm@realm.demo (des-cbc-md5) KDC supported enctypes: sudo cat /var/kerberos/krb5kdc/kdc.conf | grep supported_enctypes
supported_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 Krb client config: cat /etc/krb5.conf | grep _enctypes
default_tgs_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
default_tkt_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
permitted_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 Any ideas where the error is coming from ? How to troubleshoot further, so that I can access the collection via curl, e.g. to index new data... Thanks in advance...
... View more
Labels:
- Labels:
-
Apache Solr
-
Cloudera Search
-
Kerberos
04-26-2017
02:23 PM
Hi, although @Lester Martin and @Sunile Manjee answered perfectly, just a minor addition. If you want to assign privileges to a _group_ instead of single user, then also use '@'-prefix, like e.g.: grant '@admingroup', 'RWXC', '@my_ns'
... View more
04-12-2017
01:36 AM
sorry for any confusion, in parallel "Sentry Service" got disabled for SOLR because of the issue posted here I will close this issue, since the linked issue is the real one 😉
... View more
04-11-2017
03:06 PM
Hello @saranvisa , thanks for replying quickly. I am not testing Sentry-HDFS permissions, I am working on Sentry-SOLR. The scenario I described relates to permissions of querying a SOLR collection, not accessing HDFS files. - Kerberos is enabled - SOLR collection has been created - Sentry roles have been created - Linux groups have been mapped to Sentry roles - Privileges to access the SOLR collection has been granted via ```solrctl sentry .. ``` commandline call available sentry roles: [cloudera@quickstart hue]$ solrctl sentry --list-roles
demo-update
sentry_admin
demo-query ...and privileges: [cloudera@quickstart hue]$ solrctl sentry --list-privileges demo-query
Collection=acltest->action=query
[cloudera@quickstart hue]$ solrctl sentry --list-privileges demo-update
Collection=acltest->action=update
[cloudera@quickstart hue]$ OS user 'testuser' is **NOT** part of any of those groups, but he can nevertheless query the collection 'acltest' [testuser@quickstart ~]$ curl --negotiate -u : 'http://quickstart.cloudera:8983/solr/acltest/select?q=*'
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">0</int><int name="QTime">0</int><lst name="params"><str name="q">*</str></lst></lst><result name="response" numFound="2" start="0"><doc><int name="my_id">1</int><long name="my_somecode">55508</long><str name="cust_plz">0815</str><str name="cust_hausnr">111</str><str name="cust_strasse">hauptstr</str><str name="cust_ort">nirvana</str><str name="bank_account">746757583873</str><long name="_version_">1564414881528020992</long></doc><doc><int name="my_id">2</int><long name="my_somecode">22208</long><str name="cust_plz">4711</str><str name="cust_hausnr">666</str><str name="cust_strasse">highway-to-hell</str><str name="cust_ort">nirvana</str><str name="bank_account">9958575488</str><long name="_version_">1564414881580449792</long></doc></result>
</response> I now also tried to set the privileges via Hue=>Security plugin, but this does not work. I am able to define the role and privilege, but after clicking the blue "Update" button I just see in the top right corner the hint "Privileges has been updated", but in the overview there is no privilege displayed for that collection.....strange....
... View more
04-11-2017
02:28 PM
Hi, I enabled Kerberos and Sentry for Search in the CDH5.8 sandbox. I created users+groups on Linux, as well as roles in Sentry, and linked them together. e.g. sentry-role 'demo-query' links to linux-group 'selectors' where user 'reader' is a member of. This role was granted 'query' privilege on my collection 'acltest'. In addition to that, there is user 'writer', member of 'inserters' which maps to sentry-role 'demo-update' and privilege 'update' on the collection 'acltest'. And there is one more user, called 'testuser', who is **not** part of any of the above mentioned Linux groups My expectation is/was, that user 'testuser' fails at querying collection 'acltest', but wrong. This user can query the collection without problem, but I didn't grant him any privileges ?!?! Why is he able to query the collection ? Details: [testuser@quickstart ~]$ curl --negotiate -u : 'http://quickstart.cloudera:8983/solr/acltest/select?q=*'
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">0</int><int name="QTime">0</int><lst name="params"><str name="q">*</str></lst></lst><result name="response" numFound="2" start="0"><doc><int name="my_id">1</int><long name="my_somecode">55508</long><str name="cust_plz">0815</str><str name="cust_hausnr">111</str><str name="cust_strasse">hauptstr</str><str name="cust_ort">nirvana</str><str name="bank_account">746757583873</str><long name="_version_">1564414881528020992</long></doc><doc><int name="my_id">2</int><long name="my_somecode">22208</long><str name="cust_plz">4711</str><str name="cust_hausnr">666</str><str name="cust_strasse">highway-to-hell</str><str name="cust_ort">nirvana</str><str name="bank_account">9958575488</str><long name="_version_">1564414881580449792</long></doc></result>
</response> [testuser@quickstart ~]$ id testuser
uid=502(testuser) gid=504(testuser) groups=504(testuser) I did all the Sentry related steps (role creation, group assignment and privilege granting) via the command line, not using Hue. What am I missing, so that the ACLs are getting applied as expected (in this particular case, user 'testuser' isn't able to query the collection) ? Thanks for any hint...
... View more
Labels:
- Labels:
-
Apache Sentry
-
Apache Solr