diff --git a/src/main/docbkx/security.xml b/src/main/docbkx/security.xml index f0e327dd17a..9e6a57cebb6 100644 --- a/src/main/docbkx/security.xml +++ b/src/main/docbkx/security.xml @@ -40,24 +40,40 @@ This describes how to set up Apache HBase and clients for connection to secure HBase resources. -
+
Prerequisites - You need to have a working Kerberos KDC. - A HBase configured for secure client access is expected to be running on top of a - secured HDFS cluster. HBase must be able to authenticate to HDFS services. HBase needs - Kerberos credentials to interact with the Kerberos-enabled HDFS daemons. Authenticating a - service should be done using a keytab file. The procedure for creating keytabs for HBase - service is the same as for creating keytabs for Hadoop. Those steps are omitted here. Copy - the resulting keytab files to wherever HBase Master and RegionServer processes are deployed - and make them readable only to the user account under which the HBase daemons will run. - A Kerberos principal has three parts, with the form - username/fully.qualified.domain.name@YOUR-REALM.COM. We recommend using - hbase as the username portion. - The following is an example of the configuration properties for Kerberos operation that - must be added to the hbase-site.xml file on every server machine in the - cluster. Required for even the most basic interactions with a secure Hadoop configuration, - independent of HBase security. - + + Hadoop Authentication Configuration + + To run HBase RPC with strong authentication, you must set + hbase.security.authentication to true. In this case, + you must also set hadoop.security.authentication to + true. Otherwise, you would be using strong authentication for + HBase but not for the underlying HDFS, which would cancel out any benefit. + + + + + Kerberos KDC + + You need to have a working Kerberos KDC. + A HBase configured for secure client access is expected to be running on top of a + secured HDFS cluster. HBase must be able to authenticate to HDFS services. HBase needs + Kerberos credentials to interact with the Kerberos-enabled HDFS daemons. + Authenticating a service should be done using a keytab file. The procedure for + creating keytabs for HBase service is the same as for creating keytabs for Hadoop. + Those steps are omitted here. Copy the resulting keytab files to wherever HBase Master + and RegionServer processes are deployed and make them readable only to the user + account under which the HBase daemons will run. + A Kerberos principal has three parts, with the form + username/fully.qualified.domain.name@YOUR-REALM.COM. We recommend using + hbase as the username portion. + The following is an example of the configuration properties for Kerberos + operation that must be added to the hbase-site.xml file on every server + machine in the cluster. Required for even the most basic interactions with a secure + Hadoop configuration, independent of HBase security. + hbase.regionserver.kerberos.principal hbase/_HOST@YOUR-REALM.COM @@ -75,23 +91,30 @@ /etc/hbase/conf/keytab.krb5 ]]> - Each HBase client user should also be given a Kerberos principal. This principal should - have a password assigned to it (as opposed to a keytab file). The client principal's - maxrenewlife should be set so that it can be renewed enough times for the - HBase client process to complete. For example, if a user runs a long-running HBase client - process that takes at most 3 days, we might create this user's principal within - kadmin with: addprinc -maxrenewlife 3days - - Long running daemons with indefinite lifetimes that require client access to HBase can - instead be configured to log in from a keytab. For each host running such daemons, create a - keytab with kadmin or kadmin.local. The procedure for creating - keytabs for HBase service is the same as for creating keytabs for Hadoop. Those steps are - omitted here. Copy the resulting keytab files to where the client daemon will execute and - make them readable only to the user account under which the daemon will run. + Each HBase client user should also be given a Kerberos principal. This principal + should have a password assigned to it (as opposed to a keytab file). The client + principal's maxrenewlife should be set so that it can be renewed enough + times for the HBase client process to complete. For example, if a user runs a + long-running HBase client process that takes at most 3 days, we might create this + user's principal within kadmin with: addprinc -maxrenewlife + 3days + + Long running daemons with indefinite lifetimes that require client access to + HBase can instead be configured to log in from a keytab. For each host running such + daemons, create a keytab with kadmin or kadmin.local. The + procedure for creating keytabs for HBase service is the same as for creating keytabs + for Hadoop. Those steps are omitted here. Copy the resulting keytab files to where the + client daemon will execute and make them readable only to the user account under which + the daemon will run. + + +
Server-side Configuration for Secure Operation + First, refer to and ensure that your + underlying HDFS configuration is secure. Add the following to the hbase-site.xml file on every server machine in the cluster: Client-side Configuration for Secure Operation + First, refer to and ensure that your + underlying HDFS configuration is secure. Add the following to the hbase-site.xml file on every client: