Member since
09-29-2015
42
Posts
34
Kudos Received
11
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1410 | 10-06-2017 06:59 PM | |
1221 | 01-19-2017 05:08 PM | |
1357 | 07-22-2016 01:26 PM | |
2099 | 07-12-2016 11:34 AM | |
1396 | 06-19-2016 01:52 PM |
04-07-2016
09:30 PM
1 Kudo
See the Apache docs here for HiveServer2 HA support: http://knox.apache.org/books/knox-0-8-0/user-guide.html#HiveServer2+HA
... View more
02-04-2016
09:48 PM
4 Kudos
Knox is composed of a number of Gateway Services at its core. Among these are one for setting up the Jetty SSL listener (JettySSLService) and another for protection of various credentials (AliasService) in order to keep them out of clear text config. These services are able to leverage each other for various things. The JettySSLService has the AliasService injected in order to get to the protected gateway-identity-passphrase. This is a password that is stored at the gateway level as apposed to the topology or cluster level. While mixing the two concerns would be possible with the functionality of JCEKS, it would inappropriately couple the two services implementations together. There has always been plans to look for a more central and secure credential store. The addition of the Credential Provider API in Hadoop opens up this possibility. Currently, the primary credential provider in Hadoop is still a JCEKS provider. We need a server to sit over a secure storage that you would need to authenticate to in order to get the protected passwords. Once this is available the current design in Knox will allow us to transition to a central credential server without the JettySSLService even being aware.
... View more
01-25-2016
06:32 PM
4 Kudos
Hi Vendant - SAML v2 available in the Apache Knox 0.7.0 release through the PicketLink federation provider. It is however not documented since the PicketLink project itself is being reworked into a larger identity solution. The Apache Knox 0.8.0 release which should be finalizing in the next week or so will leverage the pac4j provider that has recently been committed. Pac4j provider SAML v2 as well as various other integrations and is the focus of the 0.8.0 release. While I haven't tested it explicitly with OpenSSO, it has been successfully tested with shibboleth and Okta for SAML prior to commit. Given an environment with OpenSSO deployed, a professional services organization would be great to contribute such testing - you don't get much closer to the real world and the customers than that!
... View more
01-18-2016
09:18 PM
That seems to indicate that the Knox certificate is not correctly set as trusted. I am not sure how to do this for ODBC. In the following blog, the truststore and related password are provided in the connect string - for JDBC. The ODBC connect string may have the same idea. You will need to import the public cert for the Knox server into whatever the truststore is.
... View more
01-18-2016
03:44 AM
1 Kudo
Apache Knox provides the same REST APIs for PUTting files into HDFS. Please see the Apache docs for examples: http://knox.apache.org/books/knox-0-7-0/user-guide.html#WebHDFS+Examples Note that the link will take you to examples of using the groovy scripting capabilities of Knox as well as examples of using curl to do the same things.
... View more
01-04-2016
06:23 PM
1 Kudo
There is currently no end-to-end API management story for hosting APIs on Hadoop. I have spent some time thinking and talking about this idea and with some customer driven usecases we may be able to get it on the roadmap. In the meantime, I would consider using Slider to deploy a service that you can host on tomcat or jetty, etc. I know that there has been some recent work for deploying tomcat to YARN via Slider. This may be worth looking into. See the work done as part of https://issues.apache.org/jira/browse/SLIDER-1012. If you would like to bring a more holistic API management usecase to the Knox community that would incorporate the use of Slider to deploy and publish APIs to the YARN registry, and a facilities for discovery and subscription that would be useful for your deployment scenarios then please engage the Knox community on the dev@ list. We would love to get your insights and perspective!
... View more
12-21-2015
05:41 PM
1 Kudo
I would also offer that this mechanism would limit the usecases in which your custom service can be used to authentication that is based on username/password. There are a number of existing and upstream authentication/federation providers that do not involve providing a password to Knox. Your service will not work with KnoxSSO, HeaderPreAuth (SiteMinder, etc), OAuth, SAML, CAS, etc. I would suggest that you bring your usecase to the dev@ list for Apache Knox and that we determine the best approach for services like the one you have in mind.
... View more
10-28-2015
06:28 PM
4 Kudos
To put a bit of a finer point on this topic, we should describe the type of solutions that integrate easily with the pre-authenticated SSO provider in Knox. There are a number of solutions in the enterprise that follow a particular pattern for integration. This pattern requires all traffic to resources that participate in the SSO to be routed through a proxy or gateway to access those services. What this enables is the ability to inject headers into the request as it flows through the network to represent the authenticated user and in some cases the groups associated with that user. Apache Knox has the ability to flow-in the identity of the end user through the use of these HTTP headers by using the header based pre-authenticated SSO provider. It defaults to header names that are often used for SiteMinder integration - SM_USER and SM_GROUPS. The header names can be overridden to match those used in different environments. Tivoli Access Manager and other solutions follow this same pattern. The provider can also be configured to only accept requests from specific (or a range) of ip addresses as well as to require mutual authentication with SSL client certificates. These helps to mitigate risk of some other party circumventing the SSO solution and asserting an arbitrary identity for resource access. It is important to understand that the SSO solution and network security provisions need to ensure that there is no way to circumvent the SSO provider's proxy and go directly to Knox.
... View more
10-13-2015
03:12 PM
3 Kudos
For Knox, sslv3 is disabled by default and this can be further configured to disable more or "none" through the ssl.exclude.protocols parameter in gateway-site.xml. This can be done directly in the file or from within Ambari. Knox does not have a configurable means to disable specific algorithms - however you can use the Java JSSE networking properties to do this. In fact, this will work for all applications being run in that particular JVM which is better than having to track it down for each application. You should be able to find this in $JRE_HOME/lib/security/java.security in others. # Algorithm restrictions for Secure Socket Layer/Transport Layer Security # (SSL/TLS) processing # # In some environments, certain algorithms or key lengths may be undesirable # when using SSL/TLS. This section describes the mechanism for disabling # algorithms during SSL/TLS security parameters negotiation, including cipher # suites selection, peer authentication and key exchange mechanisms. # # For PKI-based peer authentication and key exchange mechanisms, this list # of disabled algorithms will also be checked during certification path # building and validation, including algorithms used in certificates, as # well as revocation information such as CRLs and signed OCSP Responses. # This is in addition to the jdk.certpath.disabledAlgorithms property above. # # See the specification of "jdk.certpath.disabledAlgorithms" for the # syntax of the disabled algorithm string. # # Note: This property is currently used by Oracle's JSSE implementation. # It is not guaranteed to be examined and used by other implementations. # # Example: # jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048
... View more
09-30-2015
01:33 PM
1 Kudo
There is no SAML implementation supported by Knox in HDP yet. While the pluggability of the Knox authentication and federation providers allow a third party to integrate a SSO solution such as one supporting SAML, the Apache Knox code base does not have an implementation that is certified with HDP yet. Work is underway to provide a certified integration with token exchange capabilities that will enable SAML based solutions out of the box. Stay tuned.
... View more
- « Previous
- Next »