Tuesday, December 10, 2013

Announcing the Technical Preview of Apache Knox Gateway

Announcing the Technical Preview of Apache Knox Gateway

By Vinay Shukla
December 10th, 2013
Just yesterday, we talked about our roadmap for Security in Enterprise Hadoop. At our Security labs page you can see in one place the security roadmap and efforts underway across Hadoop and their timelines.
Security is often described as rings of defense. Continuing this analogy the Apache community has been working to create a perimeter security solution for Hadoop. This effort is Apache Knox Gateway (Apache Knox) and we are happy to announce the Technical Preview of Apache Knox. With this technical preview Apache Knox is one step closer to general availability.
Apache Knox is the Web/REST API Gateway solution for Hadoop. It provides a single access point to access all of Hadoop resources over REST. It also enables the integration of enterprise identity management solutions and provides numerous perimeter security features for REST/HTTP access to Hadoop.

Monday, December 9, 2013

Hadoop Security : Today and Tomorrow

Hadoop Security : Today and Tomorrow


By Vinay Shukla
Security is a top agenda item and represents critical requirements for Hadoop projects. Over the years, Hadoop has evolved to address key concerns regarding authentication, authorization, accounting, and data protection natively within a cluster and there are many secure Hadoop clusters in production. Hadoop is being used securely and successfully today in sensitive financial services applications, private healthcare initiatives and in a range of other security-sensitive environments. As enterprise adoption of Hadoop grows, so do the security concerns and a roadmap to embrace and incorporate these enterprise security features has emerged.

An Open Roadmap for Security

We recently published an open roadmap for security in Hadoop. This effort outlines a community based approach to delivering on the key requirements that are being asked for by some of the largest and most security stringent organizations on the planet. Our goal is to incite and work within the community to deliver flexible, comprehensive, and integrated security controls for Hadoop. You can check out this roadmap in the labs section of our website, but let’s see what we can do for security today.

Securing a Hadoop cluster today

The distributed nature of Hadoop, a key for its success, poses unique challenges in securing it. Securing a client-server system is often easier because security controls can be placed at the service, the single point of access. Securing a system requires a redundant and layered approach. With Hadoop this requirement is exaggerated by the complexity of a distribution. Many of the layers are in place today to help you secure a cluster. Lets review some of the tools available across the four pillars.
  • Authentication verifies the identity of a system or user accessing the system. Hadoop provides two modes of authentication. The first, Simple or Pseudo authentication, essentially places trust in user’s assertion about who they are. The second, Kerberos, provides a fully secure Hadoop cluster. In line with best practice, Hadoop provides these capabilities while relying on widely accepted corporate user-stores (such as LDAP or Active Directory) so that a single source can be used for credential catalog across Hadoop and existing systems.
  • Authorization specifies access privileges for a user or system. Hadoop provides fine-grained authorization via file permissions in HDFS and resource level access control (via ACL) for MapReduce and coarser grained access control at a service level. For data, HBase provides authorization with ACL on tables and column families and Accumulo extends this even further to cell level control. Also, Apache Hive provides coarse grained access control on tables.
  • Accounting provides the ability to track resource use within a system. Within Hadoop, insight into usage and data access is critical for compliance or forensics. As part of core Apache Hadoop, HDFS and MapReduce provide base audit support. Additionally, the Apache Hive metastore records audit (who/when) information for Hive interactions. Finally, Apache Oozie, the workflow engine, provides audit trail for services.
  • Data Protection ensures privacy and confidentiality of information. Hadoop and HDP allow you to protect data in motion. HDP provides encryption capability for various channels such as Remote Procedure Call (RPC), HTTP, JDBC/ODBC, and Data Transfer Protocol (DTP) to protect data in motion.  Finally, HDFS and Hadoop supports operating system level encryption.

Securing a Hadoop cluster tomorrow

There is a lot of innovation around security in Hadoop today. There is a lot of focus on making all these security frameworks work together and to make them simple to manage. Here are some of the ways Hortonworks is leading Hadoop security enhancements and is bringing enterprise security to Hadoop.
  • Perimeter level Security With Apache Knox
  • Apache Hadoop has Kerberos for authentication. However, some organizations require integration with their enterprise identity management and Single Sign-On (SSO) solutions. Hortonworks created Apache Knox Gateway (Apache Knox) to provide Hadoop cluster security at the perimeter for REST/HTTP requests and to enable the integration of enterprise identity-management solutions. Apache Knox provides integration with corporate identity systems such as LDAP, Active Directory (AD) and will also integrate with SAML based SSO and other SSO systems.
  • Apache Knox also protects a Hadoop cluster by hiding its network topology to eliminate the leak of network internals. A network firewall may be configured to deny all direct access to a Hadoop cluster and accept only the connections coming from the Apache Knox Gateway over HTTP. These measures dramatically reduce the attack vector.
  • Finally, Apache Knox promotes the use of REST/HTTP for Hadoop access. REST is proven, scalable, and provides client interoperability across languages, operating systems, and computing devices. By using Hadoop REST/HTTP APIs through Knox, clients do not need a local Hadoop installation.
  • Improved Authentication
  • Hortonworks is working with the community on a few ongoing projects to extend authentication to beyond Kerberos and provide token-based authentication. The JIRAs tracking this work are HADOOP-9392,HADOOP-9479, HADOOP-9533 and HADOOP-9804.
  • Granular Authorization
  • Authorization mechanisms in Hadoop components are getting enhanced across the board. Most Hive users want a familiar database-style authorization model. Hortonworks is working to enhance the Hive authorization to bring SQL GRANT and REVOKE semantic in Hive and make it fully secure. This enhancement will also bring row and column level security to Hive. The JIRA for this work is  HIVE-5837and the enhancement is expected in Q1, 2014. HDFS-4685 will bring ACL support in HDFS.
  • Accounting & Audit
  • There are enhancements planned to provide better reporting with audit log correlation and audit viewer capability in Hadoop. With audit log correlation an auditor will be able to answer what sequence of operations John Doe did across Hadoop components without requiring external tools. In future, with Ambari, an auditor will be able to see John Doe’s actions (such as read HDFS files and submit some MapReduce jobs) as one logical operation. In addition, Apache Knox plans to provide billing capability to record REST API usage for Hadoop.
  • Protecting data with Encryption
  • For encryption of data-in-motion the Hadoop ecosystem will continue to provide encryption of channels not already covered and to offer more effective encryption algorithm for all channels. In Q1, 2014 HDP will provide SSL support for Hive Server2. Further enhancements are in the works to provide encryption in Hive, HDFS and HBase.

Conclusion

Hadoop is a secure system and offers key features for securely processing enterprise data. But the security work never ends. Hortonworks is working on several projects to enhance Hadoop security from the inside, shore up defenses from the outside with Apache Knox and to keep up with evolving requirements by providing more flexible authentication and authorization and by improving data protection. We are also working to improve integration with enterprise Identity Management and security systems.
We encourage you to review this roadmap for Hadoop security and to get involved. Also, over the next few months we will publish more best practices, covering each pillar of security in more detail. Stay tuned for next post about wire encryption.

Tuesday, October 29, 2013

Apache Knox Gateway 0.3.0: Another release of perimeter security for Hadoop

Apache Knox Gateway 0.3.0: Another release of perimeter security for Hadoop

By Vinay Shukla
The Apache Knox community announced the release of the Apache Knox Gateway (Incubator) 0.3.0. We, at Hortonworks, are excited about this announcement.
The Apache Knox Gateway is a REST API Gateway for Hadoop with a focus on enterprise security integration.  It provides a simple and extensible model for securing access to Hadoop core and ecosystem REST APIs.
Apache Knox provides pluggable authentication to LDAP and trusted identity providers as well as service level authorization and more.  The diagram below shows how Apache Knox fits in a Hadoop cluster deployment.
knox1
The functionality in this release makes Apache Knox Gateway an ideal perimeter security solution for your Hadoop REST API access.
As mentioned on the Apache Knox news page, the highlights for the 0.3.0 release are:
  • LDAP authentication for REST calls to Hadoop
  • Secure Hadoop cluster (i.e. Kerberos) integration
  • HBase integration (non-Kerberos)
  • Hive JDBC integration (non-Kerberos)
  • Simple ACL based Service Level Authorization
Please visit Apache Knox project website to learn more about the Apache Knox Gateway and to download it. See the quick start guide to start playing with Apache Knox in a sandbox.

Monday, October 7, 2013

Death by thousand Knobs

On rare occasions when I wander down the drinks Isle at the supermarket, I am confused by the overwhelming choices of drinks. It is as if the market is telling me I don't know what you want, here is the dictionary of all the drinks in the world.

Software and other complex systems also have this issue. How many times have you seen an ultra configurable software that is hard to use, let alone use in the optimal way. Having too many configuration options is what I call Death by Thousand (Configuration) Knobs.

Often Thousand Knobs arise when the software/system creator does not know enough about how a customer will use the system. Sometimes there are legitimate reasons where it is impossible to know a priori how a system will be used, but often it arises because of laziness. Where the creator has not spent sufficient time analyzing the right way of using a software/system and is using Knobs to transfer the problem to the user.

Now I see some systems being proposed where the user is being asked to make the hard choices.

Do you want security or fast response time. These false choices are reflective of merely the early stages of a problem analysis.

Case in point http://venturebeat.com/2013/10/02/location-specific-privacy/ where an end user is asked if she wants her data processed in a more secure location.

Doh, I want my data shared with 419 scammers and Prism please and I will have that with catchup.






Thursday, June 20, 2013

Creating two files to hold key pairs

Sometimes there is a need to use private/public key pair for authentication/verification. SSH and other secure command utilize a similar strategy.

Below steps create two files. The file called keystore.jks holds the private key that is used to sign a piece of data. They keystore.jks is a private file and should be secured. The file customer.jks contains the certificate-which wraps the corresponding public key.
The file customer.jks is public and can be used to verify the signature produced by using private key from keystore.jks.




1. Create a JKS file to hold the private key and certificate (which is wrapped public key)

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

2. Export the certificate from keystore file created in previous step with to a file called mydomain.crt

keytool -export -alias selfsigned -file mydomain.crt -keystore keystore.jks

3. Create a new JKS file to hold the certificate exported in previous step

keytool -genkey -keyalg RSA -alias blah -keystore customer.jks -storepass password -validity 360 -keysize 2048

4. Now import the exported certificate to the customer.jks

keytool -importcert -alias selfsigned -file mydomain.crt -keystore customer.jks

5. Verify that customer.jks contains certificate with alias selfsigned

keytool -list -v -keystore customer.jks

Wednesday, May 29, 2013

SSL failure with DSA certificate on ios

This may come handy testing ios > Remote server over SSL.

SSL connection from ios device to a remote server will fail, if the remote server's certificate's algorithm is DSA. I found this during testing and I don't know if Apple has this documented.

My remote server was a Java server, and used JKS as the keystore format. The Java Keytool by defaults creates DSA type certificates.

To test that having the RSA certificate will get me past the issue. I created a new self signed certificate with JDK keytool with RSA type certificate.  Than I converted the certificate to PEM format and ran openssl server with the PEM certificate. I then connected to the openssl server from the safari browser on the ios device and the connection was successful.

You may ask why didn't I directly create the certificate with openssl in the PEM format, well I used keytool to show a collegue how to convert JKS to PEM.


  1. Create a self signed certificate
    keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
  2. Export JKS to PKCS12

    keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12
  3. Convert PKCS12 to PEM

    openssl pkcs12 -in keystore.p12 -out keystore.pem
  4. Launch a test server with openssl command

    openssl s_server -cert keystore.pem -www
  5. Connect to the server from a browser on iOS or from a remote device

    openssl s_client -connect  host:4433


Tuesday, May 7, 2013

Self signed Cert with Android and iPhone

Often there is a need to put a certificate on the android device (emulator | real)  for testing with SSL. This wil be the case when one needs to use a self signed cert since getting a real CA signed cert is expensive.

The high level steps are :

  1. Export the cert  from your current keystore and put it into a file
  2. Copy the cert file to android device
  3. Run settings app to add it to the trusted certificates.
The caveat it that the exported file from step 1 needs to be in p12 format.

Here are the detailed steps for Android emulator and using the source keystore as JKS.

  1. keytool -importkeystore -srckeystore -destkeystore -deststoretype PKCS12 -srcalias
  2. Start the Android emulator - emulator -avd & - Wait for this to finish
  3. adb - devices will list the android instances it know about, wait for the emulator to show up here as running.
  4. adb push /sdcard/file.p12 - Copies the exported cert file to /sdcard area of Android
  5. Go to Emulator > Settings > Security > Install Trusted Cert from SD card
  6. Type the password that you specified in step 1
  7. You should be good to go.
It is even easier for iPhone. 
  1. Just email the cert from step 1 to an email configured on iphone as an attachment
  2. Open the email from iPhone and click/tap the attachement.