Once a month, receive latest insights, trends, analytics information and knowledge of Big Data.
AVAILABLE NEWSLETTERS:
Thank you for subscribing!
Once a month, receive latest insights, trends, analytics information and knowledge of Big Data.
Thank you for subscribing!
This blog is a first in a series of security-related blogs that we plan to publish in the near future.
It’s a myth that usability and security are mutually exclusive. In this blog, we’ll try to dispel it in the context of Apache Knox. For those who are not familiar with Apache Knox, it is:
Apache Knox provides the following functionality out-of-the-box:
As you may know, configuration via XML/JSON files and CLI is prone to human errors, not to mention a joyless experience for a security admin. The pain is compounded when you need to repeat the process for multiple clusters in the data lake. To alleviate this pain, we introduced a feature called Service Discovery and Topology Generation Framework in Apache Knox 0.14.0 (KNOX-1006) that will be available in HDP 3.0. Additionally, we have front ended it with the Knox Admin UI to provide a full UI-driven experience for managing Knox topologies. We have also added an Apache Ambari script that users can run using CLI to automate the configuration for Knox SSO.
Here are some salient features of the solution:
For your understanding, we have outlined a sample workflow for WebHDFS proxy and LDAP AuthN:
1.Log into the Knox Admin
2. Update Shiro Provider under Provider Configuration/default provider tab to reflect your distinguished name and the URL of the proxy service, and save the provider configuration.
3. Create a service descriptor for WebHDFS and update the discovery information with the URL of the Ambari server
4. Save the Descriptor to trigger the generation and deployment of the Knox Topology. That’s it!
5. Run a few HDFS commands using the Knox proxy URL to validate the setup
Below is a screenshot that shows how you can configure Knox SSO using an Amabri script from the CLI without having to configure each service separately:
If you are interested in the magic behind the scenes, please refer to the below technical documentation:
https://cwiki.apache.org/confluence/display/KNOX/KIP-8+Service+Discovery+and+Topology+Generation
https://knox.apache.org/books/knox-0-14-0/user-guide.html#Externalized+Provider+Configurations
https://knox.apache.org/books/knox-0-14-0/user-guide.html#Deployment+Directories
https://knox.apache.org/books/knox-0-14-0/user-guide.html#Cluster+Configuration+Monitoring
https://knox.apache.org/books/knox-0-14-0/user-guide.html#Remote+Configuration+Monitor
https://knox.apache.org/books/knox-0-14-0/user-guide.html#Remote+Configuration+Registry+Clients
I hope this blog is helpful in explaining why security and usability are not mutually exclusive. Stay tuned for further updates on Apache Knox.
This website uses cookies for analytics, personalisation and advertising. To learn more or change your cookie settings, please read our Cookie Policy. By continuing to browse, you agree to our use of cookies.
Apache, Hadoop, Falcon, Atlas, Tez, Sqoop, Flume, Kafka, Pig, Hive, HBase, Accumulo, Storm, Solr, Spark, Ranger, Knox, Ambari, ZooKeeper, Oozie, Phoenix, NiFi, Nifi Registry, HAWQ, Zeppelin, Slider, Mahout, MapReduce, HDFS, YARN, Metron and the Hadoop elephant and Apache project logos are either registered trademarks or trademarks of the Apache Software Foundation in the United States or other countries.
© 2011-2018 Hortonworks Inc. All Rights Reserved.
Tags: