drill-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bridg...@apache.org
Subject [1/5] drill git commit: Securing Drill-Kerberos Auth Feature Docs
Date Thu, 16 Mar 2017 02:20:58 GMT
Repository: drill
Updated Branches:
  refs/heads/gh-pages 9deab2032 -> 1cc194faa


Securing Drill-Kerberos Auth Feature Docs


Project: http://git-wip-us.apache.org/repos/asf/drill/repo
Commit: http://git-wip-us.apache.org/repos/asf/drill/commit/535d5184
Tree: http://git-wip-us.apache.org/repos/asf/drill/tree/535d5184
Diff: http://git-wip-us.apache.org/repos/asf/drill/diff/535d5184

Branch: refs/heads/gh-pages
Commit: 535d518445232c345f5f4051d9214e0a33361c5b
Parents: 9deab20
Author: Bridget Bevens <bbevens@maprtech.com>
Authored: Wed Mar 15 17:45:21 2017 -0700
Committer: Bridget Bevens <bbevens@maprtech.com>
Committed: Wed Mar 15 17:45:21 2017 -0700

----------------------------------------------------------------------
 _docs/configure-drill/031-securing-drill.md     |   9 +
 .../010-securing-drill-introduction.md          |  39 +++
 .../020-secure-communication-paths.md           |  67 +++++
 .../securing-drill/030-roles-privileges.md      |  29 ++
 .../040-configuring-user-impersonation.md       | 147 ++++++++++
 .../050-configure-inbound-impersonation.md      |  53 ++++
 ...ser-impersonation-with-hive-authorization.md | 268 +++++++++++++++++++
 .../070-configuring-user-authentication.md      |  25 ++
 .../080-configuring-plain-authentication.md     | 112 ++++++++
 ...090-configuring-kerberos-auththentication.md | 112 ++++++++
 ...-configuring-web-ui-and-rest-api-security.md | 111 ++++++++
 _docs/img/kerberauthprocess.png                 | Bin 0 -> 78559 bytes
 _docs/img/kerberclientserver.png                | Bin 0 -> 66070 bytes
 _docs/img/plainauthprocess.png                  | Bin 0 -> 93994 bytes
 _docs/img/securecommunicationpaths.png          | Bin 0 -> 46625 bytes
 15 files changed, 972 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/031-securing-drill.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/031-securing-drill.md b/_docs/configure-drill/031-securing-drill.md
new file mode 100644
index 0000000..81bb48a
--- /dev/null
+++ b/_docs/configure-drill/031-securing-drill.md
@@ -0,0 +1,9 @@
+---
+title: "Securing Drill"
+parent: "Configure Drill"
+---
+
+
+
+  
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md b/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
new file mode 100644
index 0000000..b070c0a
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
@@ -0,0 +1,39 @@
+---
+title: "Securing Drill Introduction"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+
+Before connecting to a data source, you can configure Drill security features and [secure communication pathways]({{site.baseurl}}/docs/secure-drill/secure-communication-paths/) to a secure Drill cluster.  Security features include:
+
+- **Authentication** - Drill supports user authentication to secure clusters with:
+	- Kerberos. 
+		See [Kerberos Authentication]({{site.baseurl}}/docs/securing-drill/configuring-kerberos-authentication/).
+	- Username and password (with the Plain mechanism or a Custom Authenticator). See: 
+		- [Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/)  
+		- [Creating Custom Authenticators]({{site.baseurl}}/docs/custom-authentication)
+	- Digest 
+- **Authorization** - Drill supports restricting an authenticated user's capabilities.
+		See [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/).
+- **Impersonation** - Drill executes queries on behalf of a client while performing the action requested by the client.
+		See:  
+			- [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)  
+			- [Configuring Inbound Impersonation]({{site.baseurl}}/docs/configuring-inbound-impersonation/)  
+			- [Configuring User Impersonation with Hive Authorization]({{site.baseurl}}/docs/configuring-user-impersonation-with-hive-authorization/)  
+- **Encryption** - Drill does not support encryption as of Drill 1.10.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/020-secure-communication-paths.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/020-secure-communication-paths.md b/_docs/configure-drill/securing-drill/020-secure-communication-paths.md
new file mode 100644
index 0000000..ee21b21
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/020-secure-communication-paths.md
@@ -0,0 +1,67 @@
+---
+title: "Secure Communication Paths"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+As illustrated in the following figure, Drill 1.10 features five secure communication paths. Security features for each communication path are described their respective  sections.
+
+
+1. Web client to drillbit
+1. C++ client to drillbit
+1. Java client to drillbit
+1. Java client and drillbit to ZooKeeper
+1. Drillbit to storage plugin
+
+![Secure Communication Paths](http://i.imgur.com/2ndkLt6.png)
+
+
+## Web Client to Drillbit
+
+The Web Console and REST API clients are web clients. Web clients can:
+
+- Submit and monitor queries
+- Configure storage plugins
+
+---
+**Note**
+
+Impersonation and authorization are available through the web clients only when authentication is enabled. Otherwise, the user identity is unknown.
+
+---
+
+| Security Capability | Description                                                                                                                                                                                                                                                                                                                                          | Reference                                                            |
+|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|
+| Authentication      | Users authenticate to a drillbit using a username and password form authenticator. By default, authentication is disabled.                                                                                                                                                                                                                           | Configuring Web Console and REST API Security                        |
+| Impersonation       | Drill acts on behalf of the user on the session. This is usually the connection user (or the user that authenticates). This user can impersonate another user, which is allowed if the connection user is authorized to impersonate the target user based on the inbound impersonation policies (USER role).  By default, impersonation is disabled. | Configuring User Impersonation and Configuring Inbound Impersonation |
+| Authorization       | Queries execute on behalf of the web user. Users and administrators have different navigation bars. Various tabs are shown based on privileges. For example, only administrators can see the Storage tab and create/read/update/delete storage plugin configuration.                                                                                 | Configuring Web Console and REST API Security                        |
+
+## Java and C++ Client to Drillbit
+
+Java (native or JDBC) and C++ (native or ODBC) clients submit queries to Drill. BI tools use the ODBC or JDBC API.
+
+| Security Capability | Description                                                                                                                                                                                                                                                                                                                                                                                                                                             | Reference                                                            |
+|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|
+| Authentication      | Users authenticate to a drillbit using Kerberos, Plain (username and password through PAM), and Custom authenticator (username and password). By default, user authentication is disabled.                                                                                                                                                                                                                                                              | Configuring User Authentication                                      |
+| Impersonation       | Drill acts on behalf of the user on the session. This is usually the connection user (or the user that authenticates). This user can impersonate another user. This is allowed if the connection user is authorized to impersonate the target user based on the inbound impersonation policies (USER role).  By default, impersonation is disabled.                                                                                                     | Configuring User Impersonation and Configuring Inbound Impersonation |
+| Authorization       | A user can execute queries on data that he/she has access to. Each storage plugin manages the read/write permissions. Users can create views on top of data to provide granular access to that data. The user sets read permissions to appropriate users and/or groups.  System-level options can only be changed by administrators (USER role). By default, only the process user is an administrator. This is available if authentication is enabled. | Configuring User Impersonation/Impersonation and Views               |
+
+## Drill Client and Drillbit to ZooKeeper 
+
+Drill clients and drillbits communicate with ZooKeeper to obtain the list of active drillbits. Drillbits store system-level options and running query profiles.
+
+| Security Capability | Description                                         | Reference                       |
+|---------------------|-----------------------------------------------------|---------------------------------|
+| Authentication      | Not fully supported.                                | Configuring User Authentication |
+| Authorization       | Drill does not set ACLs on ZooKeeper nodes (znode). |                                 |
+| Encryption          | Not fully supported.                                | ZooKeeper SSL User Guide        |
+
+## Drillbit to Hive Storage Plugin
+
+The planner accesses the Hive Metastore for metadata. During execution, query fragments scan data from Hive using the Hive storage plugin.
+
+| Security Capability 	| Description 	| Reference 	|
+|---------------------	|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------	|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------	|
+| Authentication 	| Drillbit is a client to the Hive Metastore. Authentication options   include Kerberos and DIGEST. By default, authentication is disabled. 	| Kerberos (if Hive impersonation is disabled and Kerberos principal is   mentioned) and DIGEST (the only supported mechanism when Hive impersonation   is enabled and SASL is enabled). 	|
+| Impersonation 	| While accessing Hive Metastore, Hive impersonation setting in the storage   plugin configuration overrides Drill’s impersonation setting. While scanning   data in Hive, Drill impersonation is applied. 	| Configuring User Impersonation 	|
+| Authorization 	| Drill supports SQL standard-based authorization and storage-based   authorization. 	| Configuring User Impersonation with Hive Authorization 	|
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/030-roles-privileges.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/030-roles-privileges.md b/_docs/configure-drill/securing-drill/030-roles-privileges.md
new file mode 100644
index 0000000..e6fccd4
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/030-roles-privileges.md
@@ -0,0 +1,29 @@
+---
+title: "Roles and Privileges"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+Drill has two roles that perform different functions: 
+
+* User (USER) role
+* Administrator (ADMIN) role 
+
+## User Role
+
+Users can execute queries on data that he/she has access to. Each storage plugin manages the read/write permissions. Users can create views on top of data to provide granular access to that data.  
+
+## Administrator Role
+
+When authentication is enabled, only Drill users who are assigned Drill cluster administrator privileges can perform the following tasks:
+
+- Change system-level options by issuing the ALTER SYSTEM command.
+- Update a storage plugin configuration through the REST API or Web Console. 
+- Users and administrators have different navigation bars in the web console. Various tabs are shown based on privilege. For example,  only administrators can see the Storage tab and create/read/update/delete storage plugin configuration.
+- View profiles of all queries that all users have run or are currently running in a cluster.
+- Cancel running queries that were launched by any user in the cluster.
+
+See [Configuring Web Console and REST API Security]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/) for more information.
+
+
+
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/040-configuring-user-impersonation.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/040-configuring-user-impersonation.md b/_docs/configure-drill/securing-drill/040-configuring-user-impersonation.md
new file mode 100644
index 0000000..3a3ec6a
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/040-configuring-user-impersonation.md
@@ -0,0 +1,147 @@
+---
+title: "Configuring User Impersonation"
+date: 2016-05-05 21:44:32 UTC
+parent: "Securing Drill"
+---
+Impersonation allows a service to act on behalf of a client while performing the action requested by the client. By default, user impersonation is disabled in Drill. You can configure user impersonation in the <DRILLINSTALL_HOME>/conf/drill-override.conf file.
+ 
+When you enable impersonation, Drill executes client requests as the user logged in to the client. Drill passes the user credentials to the file system, and the file system checks to see if the user has permission to access the data. When you enable authentication, Drill uses the pluggable authentication module (PAM) to authenticate a user’s identity before the user can access the Drillbit process. See User Authentication.
+ 
+If impersonation is not configured, Drill executes all of the client requests against the file system as the user that started the Drillbit service on the node. This is typically a privileged user. The file system verifies that the system user has permission to access the data.
+
+
+## Example
+When impersonation is disabled and user Bob issues a query through the SQLLine client, SQLLine passes the query to the connecting Drillbit. The Drillbit executes the query as the system user that started the Drill process on the node. For the purpose of this example, we will assume that the system user has full access to the file system. Drill executes the query and returns the results back to the client.
+![](http://i.imgur.com/4XxQK2I.png)
+
+When impersonation is enabled and user Bob issues a query through the SQLLine client, the Drillbit uses Bob's credentials to access data in the file system. The file system checks to see if Bob has permission to access the data. If so, Drill returns the query results to the client. If Bob does not have permission, Drill returns an error.
+![](http://i.imgur.com/oigWqVg.png)
+
+## Impersonation Support
+The following table lists the clients, storage plugins, and types of queries that you can use with impersonation in Drill:
+
+| Type            | Supported                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | Not Supported               |
+|-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------|
+| Clients         | SQLLine, ODBC, JDBC                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | Drill Web Console, REST API |
+| Storage Plugins | File System, Hive, MapR-DB                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | HBase                       |
+| Queries         | When you enable impersonation, the setting applies to queries on data and metadata. For example, if you issue the SHOW SCHEMAS command, Drill impersonates the user logged into the client to access the requested metadata. If you issue a SELECT query on a workspace, Drill impersonates the user logged in to the client to access the requested data. Drill applies impersonation to queries issued using the following commands: SHOW SCHEMAS, SHOW DATABASES, SHOW TABLES, CTAS, SELECT, CREATE VIEW, DROP VIEW, SHOW FILES. To successfully run the CTAS and CREATE VIEW commands, a user must have write permissions on the directory where the table or view will exist. Running these commands creates artifacts on the file system. |                             |
+
+## Impersonation and Views
+You can use views with impersonation to provide granular access to data and protect sensitive information. When you create a view, Drill stores the view definition in a file and suffixes the file with .drill.view. For example, if you create a view named myview, Drill creates a view file named myview.drill.view and saves it in the current workspace or the workspace specified, such as dfs.views.myview. See [CREATE VIEW]({{site.baseurl}}/docs/create-view) Command.
+
+You can create a view and grant read permissions on the view to give other users access to the data that the view references. When a user queries the view, Drill impersonates the view owner to access the underlying data. If the user tries to access the data directory, Drill returns a permission denied error. A user with read access to a view can create new views from the originating view to further restrict access on data.
+
+### View Permissions
+A user must have write permission on a directory or workspace to create a view, as well as read access on the table(s) and/or view(s) that the view references. When a user creates a view, permission on the view is set to owner by default. Users can query an existing view or create new views from the view if they have read permissions on the view file and the directory or workspace where the view file is stored. 
+
+When users query a view, Drill accesses the underlying data as the user that created the view. If a user does not have permission to access a view, the query fails and Drill returns an error. Only the view owner or a superuser can modify view permissions to change them from owner to group or world. 
+ 
+The view owner or a superuser can modify permissions on the view file directly or they can set view permissions at the system or session level prior to creating any views. Any user that alters view permissions must have write access on the directory or workspace in which they are working. See Modifying Permissions on a View File and Modifying SYSTEM|SESSION Level View Permissions. 
+
+### Modifying Permissions on a View File
+
+Only a view owner or a super user can modify permissions on a view file to change them from owner to group or world readable. Before you grant permission to users to access a view, verify that they have access to the directory or workspace in which the view file is stored.
+
+Use the `chmod` and `chown` commands with the appropriate octal code to change permissions on a view file:
+
+    hadoop fs –chmod <octal code> <file_name>
+    hadoop fs –chown <user>:<group> <file_name>
+Example: `hadoop fs –chmod 750 employees.drill.view`
+
+### Modifying SYSTEM|SESSION Level View Permissions
+
+Use the `ALTER SESSION|SYSTEM` command with the `new_view_default_permissions` parameter and the appropriate octal code to set view permissions at the system or session level prior to creating a view.
+ 
+    ALTER SESSION SET `new_view_default_permissions` = '<octal_code>';
+    ALTER SYSTEM SET `new_view_default_permissions` = '<octal_code>';
+ 
+Example: ``ALTER SESSION SET `new_view_default_permissions` = '777';``
+ 
+After you set this parameter, Drill applies the same permissions on each view created during the session or across all sessions if set at the system level.
+
+## Chained Impersonation
+You can configure Drill to allow chained impersonation on views when you enable impersonation in the `drill-override.conf` file. Chained impersonation controls the number of identity transitions that Drill can make when a user queries a view. Each identity transition is equal to one hop.
+ 
+An administrator can set the maximum number of hops on views to limit the number of times that Drill can impersonate a different user when other users query a view. The default maximum number of hops is set at 3. When the maximum number of hops is set to 0, Drill does not allow impersonation chaining, and a user can only read data for which they have direct permission to access. An administrator may set the chain length to 0 to protect highly sensitive data. 
+ 
+The following example depicts a scenario where the maximum hop number is set to 3, and Drill must impersonate three users to access data when Chad queries a view that Jane created:
+
+![]({{ site.baseurl }}/docs/img/drill_imp_simple.PNG)
+
+In the previous example, Joe created V2 from the view that user Frank created. In the following example, Joe created V3 by joining a view that Frank created with a view that Bob created. 
+ 
+![]({{ site.baseurl }}/docs/img/user_hops_joined_view.PNG)  
+
+Although V3 was created by joining two different views, the number of hops remains at 3 because Drill does not read the views at the same time. Drill reads V2 first and then reads V1.  
+
+In the next example, Bob queries V4 which was created by Frank. Frank's view was created from several underlying views. Charlie created V2 by joining Jane's V1 with Kris's V1.2. Kris's V1.2 was created from Amy's V1.1, increasing the complexity of the chaining. Assuming that the hop limit is set at 4, this scenario exceeds the limit.  
+
+![]({{ site.baseurl }}/docs/img/user_hops_four.PNG)  
+
+When Bob queries Franks’s view, Drill returns an error stating that the query cannot complete because the number of hops required to access the data exceeds the maximum hop setting of 4.
+
+If users encounter this error, the administrator can increase the maximum hop setting to accommodate users running queries on views.
+
+### Configuring Impersonation and Chaining
+Chaining is a system-wide setting that applies to all views. Currently, Drill does not provide an option to  allow different chain lengths for different views.
+
+Complete the following steps on each Drillbit node to enable user impersonation, and set the maximum number of chained user hops that Drill allows:
+
+1. Navigate to `<drill_installation_directory>/conf/` and edit `drill-override.conf`.
+2. Under `drill.exec`, add the following:
+
+          drill.exec.impersonation: {
+                enabled: true,
+                 max_chained_user_hops: 3
+          }
+
+       Alternatively, you can nest impersonation within the `drill.exec` block, as shown in the following example: 
+
+              drill.exec: {
+                   cluster-id: "cluster_name",
+                   zk.connect: "<hostname>:<port>,<hostname>:<port>,<hostname>:<port>",
+                   sys.store.provider.zk.blobroot: "hdfs://",
+                   impersonation: {
+                     enabled: true,
+                     max_chained_user_hops: 3
+                   }
+                 }
+
+ 
+3. Verify that enabled is set to `‘true’`.
+4. Set the maximum number of chained user hops that you want Drill to allow.
+5. Restart the Drillbit process on each Drill node.
+
+         <DRILLINSTALL_HOME>/bin/drillbit.sh restart
+
+## Impersonation and Chaining Example
+Frank is a senior HR manager at a company. Frank has access to all of the employee data because he is a member of the hr group. Frank created a table named “employees” in his home directory to store the employee data he uses. Only Frank has access to this table.
+ 
+drwx------      frank:hr     /user/frank/employees
+ 
+Each record in the employees table consists of the following information:
+emp_id, emp_name, emp_ssn, emp_salary, emp_addr, emp_phone, emp_mgr
+ 
+Frank needs to share a subset of this information with Joe who is an HR manager reporting to Frank. To share the employee data, Frank creates a view called emp_mgr_view that accesses a subset of the data. The emp_mgr_view filters out sensitive employee information, such as the employee social security numbers, and only shows data for the employees that report directly to Joe. Frank and Joe both belong to the mgr group. Managers have read permission on Frank’s directory.
+ 
+rwxr-----     frank:mgr   /user/frank/emp_mgr_view.drill.view
+ 
+The emp_mgr_view.drill.view file contains the following view definition:
+
+(view definition: SELECT emp_id, emp_name, emp_salary, emp_addr, emp_phone FROM \`/user/frank/employee\` WHERE emp_mgr = 'Joe')
+ 
+When Joe issues SELECT * FROM emp_mgr_view, Drill impersonates Frank when accessing the employee data, and the query returns the data that Joe has permission to see based on the view definition. The query results do not include any sensitive data because the view protects that information. If Joe tries to query the employees table directly, Drill returns an error or null values.
+ 
+Because Joe has read permissions on the emp_mgr_view, he can create new views from it to give other users access to the employee data even though he does not own the employees table and cannot access the employees table directly.
+ 
+Joe needs to share employee contact data with his direct reports, so he creates a special view called emp_team_view to share the employee contact information with his team. Joe creates the view and writes it to his home directory. Joe and his reports belong to a group named joeteam. The joeteam group has read permissions on Joe’s home directory so they can query the view and create new views from it.
+ 
+rwxr-----     joe:joeteam   /user/joe/emp_team_view.drill.view
+ 
+The emp_team_view.drill.view file contains the following view definition:
+ 
+(view definition: SELECT emp_id, emp_name, emp_phone FROM \`/user/frank/emp_mgr_view.drill\`);
+ 
+When anyone on Joe’s team issues SELECT * FROM emp_team_view, Drill impersonates Joe to access the emp_team_view and then impersonates Frank to access the emp_mgr_view and the employee data. Drill returns the data that Joe’s team has can see based on the view definition. If anyone on Joe’s team tries to query the emp_mgr_view or employees table directly, Drill returns an error or null values.
+ 
+Because Joe’s team has read permissions on the emp_team_view, they can create new views from it and write the views to any directory for which they have write access. Creating views can continue until Drill reaches the maximum number of impersonation hops.

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md b/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md
new file mode 100644
index 0000000..244c085
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md
@@ -0,0 +1,53 @@
+---
+title: "Configuring Inbound Impersonation"
+date: 2016-03-16 19:05:49 UTC
+parent: "Securing Drill"
+---  
+
+Drill supports [user impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)  where queries run as the user that created a connection. However, this user is not necessarily the end user who submits the queries. For example, in a classic three-tier architecture, the end user interacts with Tableau Desktop, which communicates with a Tableau Server, which in turn communicates with a Drill cluster. In this scenario, a proxy user creates a connection, and the queries are submitted to Drill by the proxy user on behalf of the end user, and not by the end user directly. In this particular case, the query needs to be run as the end user.  
+
+As of Drill 1.6, an administrator can define inbound impersonation policies to impersonate the end user. The proxy user needs to be authorized to submit queries on behalf of the specified end user. Otherwise, any user can impersonate another user. Then, the query runs as the end user, and data authorization is based on this user’s access permissions. Note that without [authentication]({{site.baseurl}}/docs/configuring-user-authentication/) enabled in both communication channels, a user can impersonate any other user.
+
+Drill trusts proxy users to provide the correct end user identity information. Drill does not authenticate the end user. The proxy user (application) is responsible for end user authentication, which is usually enabled.
+
+![]({{ site.baseurl }}/docs/img/inboundImpersonation.PNG)  
+
+This image shows how identity is propagated through various layers (with authentication enabled). The flow on the left is Drill with user impersonation enabled, and the flow on the right is Drill with user impersonation and inbound impersonation enabled. `t:euser` is a property on the connection (`u` is `username`, `p`is `password`, `t` is `impersonation_target`).  
+
+
+##Configuring Inbound Impersonation
+You must be an administrator to configure inbound impersonation. You can define administrative users through the `security.admin.user_groups` and `security.admin.users` options. See [Configuration Options]({{site.baseurl}}/docs/configuration-options-introduction/#system-options). 
+
+[User impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) must be enabled before you can configure inbound impersonation.
+
+Complete the following steps to enable inbound impersonation:  
+
+1. In `drill-override.conf`, set user impersonation to true:
+  
+              {
+              drill.exec.impersonation.enabled: true,
+              ...
+              }
+
+2. Define inbound impersonation policies. For example, the following ALTER SYSTEM statement authorizes:
+       * `puser1` to impersonate any user (use * as a wildcard character)
+       * `puser2` to impersonate `euser1` and all users in `egroup2` 
+       * all users in `pgroup3` to impersonate all users in `egroup3`  
+      
+              ALTER SYSTEM SET `exec.impersonation.inbound_policies`=‘[
+              { proxy_principals : { users: [“puser1”] },
+                target_principals: { users: [“*”] } },
+              { proxy_principals : { users: [“puser2”] }, 
+                target_principals: { users: [“euser1”], groups :  [“egroup2”] } },
+              { proxy_principals : { groups: [“pgroup3”] },
+                target_principals: { groups: [“egroup3”] } } ]’;  
+Policy format:
+
+              { proxy_principals : { users : [“...”, “...”], groups : [“...”, “...”] },
+              target_principals: { users : [“...”, “...”], groups : [“...”, “...”] } }
+
+3. Ensure that the proxy user (application) passes the username of the impersonation target user to Drill when creating a connection through the `impersonation_target` connection property. For example, through sqlline:  
+
+        bin/sqlline –u “jdbc:drill:schema=dfs;zk=myclusterzk;impersonation_target=euser1” -n puser1 -p ppass1  
+
+In this example, `puser1` is the user submitting the queries. This user is authenticated. Since this user is authorized to impersonate any user, queries through the established connection are run as `euser1`.

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/060-configuring-user-impersonation-with-hive-authorization.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/060-configuring-user-impersonation-with-hive-authorization.md b/_docs/configure-drill/securing-drill/060-configuring-user-impersonation-with-hive-authorization.md
new file mode 100644
index 0000000..3aaea9d
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/060-configuring-user-impersonation-with-hive-authorization.md
@@ -0,0 +1,268 @@
+---
+title: "Configuring User Impersonation with Hive Authorization"
+date: 2016-01-05
+parent: "Securing Drill"
+---
+As of Drill 1.1, you can enable impersonation in Drill and configure authorization in Hive version 1.0 to authorize access to metadata in the Hive metastore repository and data in the Hive warehouse. Impersonation allows a service to act on behalf of a client while performing the action requested by the client. See [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation).
+
+There are two types of Hive authorizations that you can configure to work with impersonation in Drill: SQL standard based and storage based authorization.  
+
+## SQL Standard Based Authorization  
+
+You can configure Hive SQL standard based authorization in Hive version 1.0 to work with impersonation in Drill 1.1. The SQL standard based authorization model can control which users have access to columns, rows, and views. Users with the appropriate permissions can issue the GRANT and REVOKE statements to manage privileges from Hive.
+
+For more information, see [SQL Standard Based Hive Authorization](https://cwiki.apache.org/confluence/display/HIVE/SQL+Standard+Based+Hive+Authorization).  
+
+## Storage Based Authorization  
+  
+You can configure Hive storage based authorization in Hive version 1.0 to work with impersonation in Drill 1.1. Hive storage based authorization is a remote metastore server security feature that uses the underlying file system permissions to determine permissions on databases, tables, and partitions. The unit style read/write permissions or ACLs that a user or group has on directories in the file system determine access to data. Because the file system controls access at the directory and file level, storage based authorization cannot control access to data at the column or view level.
+
+You manage user and group privileges through permissions and ACLs in the distributed file system. You manage storage based authorization through the remote metastore server to authorize access to data and metadata.
+
+DDL statements that manage permissions, such as GRANT and REVOKE, do not affect permissions in the storage based authorization model.
+
+For more information, see [Storage Based Authorization in the Metastore Server](https://cwiki.apache.org/confluence/display/Hive/Storage+Based+Authorization+in+the+Metastore+Server).  
+
+## Configuration  
+
+Once you determine the Hive authorization model that you want to implement, enable impersonation in Drill, update the `hive-site.xml` file with the relevant parameters for the authorization type, and modify the Hive storage plugin configuration in Drill with the relevant properties for the authorization type.  
+
+### Prerequisites  
+
+* Hive 1.0 installed
+* Drill 1.1 or later installed
+* Hive remote metastore repository configured  
+
+## Step 1: Enabling Drill Impersonation  
+
+Modify `<DRILL_HOME>/conf/drill-override.conf` on each Drill node to include the required properties, set the [maximum number of chained user hops]({{site.baseurl}}/docs/configuring-user-impersonation/#chained-impersonation), and restart the Drillbit process.
+
+1. Add the following properties to the `drill.exec` block in `drill-override.conf`:  
+
+          drill.exec: {
+           cluster-id: "<drill_cluster_name>",
+           zk.connect: "<hostname>:<port>,<hostname>:<port>,<hostname>:<port>"
+           impersonation: {
+                 enabled: true,
+                 max_chained_user_hops: 3
+            }
+           }  
+
+2. Issue the following command to restart the Drillbit process on each Drill node:  
+`<DRILLINSTALL_HOME>/bin/drillbit.sh restart`  
+
+##  Step 2:  Updating hive-site.xml  
+
+Update hive-site.xml with the parameters specific to the type of authorization that you are configuring and then restart Hive.  
+
+### Storage Based Authorization  
+
+Add the following required authorization parameters in hive-site.xml to configure storage based authentication:  
+
+**hive.metastore.pre.event.listeners**  
+**Description:** Enables metastore security.  
+**Value:** org.apache.hadoop.hive.ql.security.authorization.AuthorizationPreEventListener  
+
+**hive.security.metastore.authorization.manager**  
+**Description:** Tells Hive which metastore-side authorization provider to use. The default setting uses DefaultHiveMetastoreAuthorizationProvider, which implements the standard Hive grant/revoke model. To use an HDFS permission-based model (recommended) for authorization, use StorageBasedAuthorizationProvider.  
+**Value:** org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider  
+
+**hive.security.metastore.authenticator.manager**  
+**Description:** The authenticator manager class name in the metastore for authentication.  
+**Value:** org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator  
+
+**hive.security.metastore.authorization.auth.reads**  
+**Description:** When enabled, Hive metastore authorization checks for read access.  
+**Value:** true  
+
+**hive.metastore.execute.setugi**  
+**Description:** When enabled, this property causes the metastore to execute DFS operations using the client's reported user and group permissions. This property must be set on both the client and server sides. If the cient and server settings differ, the client setting is ignored.  
+**Value:** true 
+
+**hive.server2.enable.doAs**  
+**Description:** Tells HiveServer2 to execute Hive operations as the user submitting the query. Must be set to true for the storage based model.  
+**Value:** true
+
+
+
+### Example of hive-site.xml configuration with the required properties for storage based authorization 
+
+       <configuration>
+         <property>
+           <name>hive.metastore.uris</name>
+           <value>thrift://10.10.100.120:9083</value>    
+         </property>  
+       
+         <property>
+           <name>javax.jdo.option.ConnectionURL</name>
+           <value>jdbc:derby:;databaseName=/opt/hive/hive-1.0/bin/metastore_db;create=true</value>    
+         </property>
+       
+         <property>
+           <name>javax.jdo.option.ConnectionDriverName</name>
+           <value>org.apache.derby.jdbc.EmbeddedDriver</value>    
+         </property>
+       
+         <property>
+           <name>hive.metastore.pre.event.listeners</name>
+           <value>org.apache.hadoop.hive.ql.security.authorization.AuthorizationPreEventListener</value>
+         </property>
+       
+         <property>
+           <name>hive.security.metastore.authenticator.manager</name>
+           <value>org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator</value>
+         </property>
+       
+         <property>
+           <name>hive.security.metastore.authorization.manager</name>
+           <value>org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider</value>
+         </property>
+       
+         <property>
+           <name>hive.security.metastore.authorization.auth.reads</name>
+           <value>true</value>
+         </property>
+       
+         <property>
+           <name>hive.metastore.execute.setugi</name>
+           <value>true</value>
+         </property>
+       
+         <property>
+           <name>hive.server2.enable.doAs</name>
+           <value>true</value>
+         </property>
+       </configuration>
+
+
+## SQL Standard Based Authorization  
+
+Add the following required authorization parameters in hive-site.xml to configure SQL standard based authentication:  
+
+**hive.security.authorization.enabled**  
+**Description:** Enables Hive security authorization.   
+**Value:** true 
+
+**hive.security.authenticator.manager**  
+**Description:** Class that implements HiveAuthenticationProvider to provide the client’s username and groups.  
+**Value:** org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator  
+
+**hive.security.authorization.manager**  
+**Description:** The Hive client authorization manager class name.   
+**Value:** org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory  
+
+**hive.server2.enable.doAs**  
+**Description:** Tells HiveServer2 to execute Hive operations as the user submitting the query. Must be set to false for the storage based model. 
+**Value:** false
+
+**hive.users.in.admin.role**  
+**Description:** A comma separated list of users which gets added to the ADMIN role when the metastore starts up. You can add more uses at any time. Note that a user who belongs to the admin role needs to run the "set role" command before getting the privileges of the admin role, as this role is not in the current roles by default.  
+**Value:** Set to the list of comma-separated users who need to be added to the admin role. 
+
+**hive.metastore.execute.setugi**  
+**Description:** In unsecure mode, setting this property to true causes the metastore to execute DFS operations using the client's reported user and group permissions. Note: This property must be set on both the client and server sides. This is a best effort property. If the client is set to true and the server is set to false, the client setting is ignored.  
+**Value:** false  
+  
+
+### Example of hive-site.xml configuration with the required properties for SQL standard based authorization         
+        
+       <configuration>
+         <property>
+           <name>hive.metastore.uris</name>
+           <value>thrift://10.10.100.120:9083</value>    
+         </property> 
+
+         <property>
+           <name>javax.jdo.option.ConnectionURL</name>
+           <value>jdbc:derby:;databaseName=/opt/hive/hive-1.0/bin/metastore_db;create=true</value>    
+         </property>
+       
+         <property>
+           <name>javax.jdo.option.ConnectionDriverName</name>
+           <value>org.apache.derby.jdbc.EmbeddedDriver</value>    
+         </property>  
+
+         <property>
+           <name>hive.security.authorization.enabled</name>
+           <value>true</value>
+         </property>
+       
+         <property>
+           <name>hive.security.authenticator.manager</name>
+           <value>org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator</value>
+         </property>       
+       
+         <property>
+           <name>hive.security.authorization.manager</name>   
+           <value>org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory</value>
+         </property>
+       
+         <property>
+           <name>hive.server2.enable.doAs</name>
+           <value>false</value>
+         </property>
+       
+         <property>
+           <name>hive.users.in.admin.role</name>
+           <value>user</value>
+         </property>
+       
+         <property>
+           <name>hive.metastore.execute.setugi</name>
+           <value>false</value>
+         </property>    
+        </configuration>
+
+## Step 3: Modifying the Hive Storage Plugin  
+
+Modify the Hive storage plugin configuration in the Drill Web Console to include specific authorization settings. The Drillbit that you use to access the Web Console must be running.  
+
+Complete the following steps to modify the Hive storage plugin:  
+
+1.  Navigate to `http://<drillbit_hostname>:8047`, and select the **Storage tab**.  
+2.  Click **Update** next to "hive."  
+3.  In the configuration window, add the configuration properties for the authorization type.
+  
+   * For storage based authorization, add the following properties:  
+
+              {
+               type:"hive",
+               enabled: true,
+               configProps : {
+                 "hive.metastore.uris" : "thrift://<metastore_host>:<port>",
+                 "fs.default.name" : "hdfs://<host>:<port>/",
+                 "hive.metastore.sasl.enabled" : "false",
+                 "hive.server2.enable.doAs" : "true",
+                 "hive.metastore.execute.setugi" : "true"
+               }
+              }  
+   * For SQL standard based authorization, add the following properties:  
+
+              {
+               type:"hive",
+               enabled: true,
+               configProps : {
+                 "hive.metastore.uris" : "thrift://<metastore_host>:9083",
+                 "fs.default.name" : "hdfs://<host>:<port>/",
+                 "hive.security.authorization.enabled" : "true",
+                 "hive.security.authenticator.manager" : "org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator",
+                 "hive.security.authorization.manager" : "org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory",
+                 "hive.metastore.sasl.enabled" : "false",
+                 "hive.server2.enable.doAs" : "false",
+                 "hive.metastore.execute.setugi" : "false"
+               }
+              }
+              
+
+
+
+
+
+
+
+
+
+
+
+
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md b/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
new file mode 100644
index 0000000..e383fb7
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
@@ -0,0 +1,25 @@
+---
+title: "Configuring User Authentication"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+Authentication is the process of establishing confidence of authenticity. A Drill client user is authenticated when a drillbit process running in a Drill cluster confirms the identity it is presented with.  Drill 1.10 supports several authentication mechanisms through which users can prove their identity before accessing cluster data: 
+
+* **Kerberos** - New in Drill 1.10. See [Kerberos Authentication]({{site.baseurl}}/docs/securing-drill/kerberos-authentication/).
+* **Plain** [also known as basic authentication (auth), which is username and password-based authentication, through the Linux Pluggable Authentication Module (PAM)] - See [Plain Authentication]({{site.baseurl}}/docs/securing-drill/plain-authentication/).
+* **Custom authenticators** - See [Creating Custom Authenticators]({{site.baseurl}}/docs/develop-custom-functions/adding-custom-functions-to-drill/custom-authentication).
+
+These authentication options are available through JDBC and ODBC interfaces.
+
+---
+**Note**
+
+If user impersonation is enabled, Drill executes the client requests as the authenticated user. Otherwise, Drill executes client requests as the user that started the drillbit process. You can enable both authentication and impersonation to improve Drill security. See [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) for more information.
+
+---
+
+
+
+
+
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md b/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
new file mode 100644
index 0000000..8217d58
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
@@ -0,0 +1,112 @@
+---
+title: "Configuring Plain Authentication"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+Linux PAM provides a Plain (or username and password) authentication module that interface with any installed PAM authentication entity, such as the local operating system password file (`/etc/passwd`) or LDAP. 
+When using PAM for authentication, each user that has permission to run Drill queries must exist in the list of users that resides on each Drill node in the cluster. The username (including `uid`) and password for each user must be identical across all Drill nodes. 
+
+If you use PAM with `/etc/passwd` for authentication, verify that the users with permission to start the Drill process are part of the shadow user group on all nodes in the cluster. This enables Drill to read the `/etc/shadow` file for authentication.
+
+This section includes the following topics:
+
+- [Authentication Process]({{site.baseurl}}/docs/configuring-plain-authentication/#authentication-process)
+- [Connecting with SQLLine]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-sqline)
+- [Connecting with BI Tools]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-bitools)
+- [Installing and Configuring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/#installing-and-configuring-plain-authentication)
+
+## Authentication Process
+
+The following image illustrates the PAM user authentication process in Drill.  The client passes a username and password to the drillbit as part of the connection request, which then passes the credentials to PAM.  If PAM authenticates the user, the connection request passes the authentication phase and the connection is established. The user will be authorized to access Drill and issue queries against the file system or other storage plugins, such as Hive or HBase.  
+
+![Plain Auth Process](http://i.imgur.com/JkuApo2.png)
+
+If PAM cannot authenticate the user, the connection request will not pass the authentication phase, and the user will not be authorized to access Drill. The connection is terminated as `AUTH_FAILED`.
+
+For more PAM information (including a *JPAM User Guide*), see [JPAM](http://jpam.sourceforge.net/ "JPAM").
+
+## Connecting with SQLLine
+
+When Plain user authentication is enabled with PAM, each user that accesses the drillbit process through a client, such as SQLLine, must provide username and password credentials for access. Users can include the `–n` and `–p` parameters with their username and password when launching SQLLine. 
+
+**Example**
+
+    sqlline –u jdbc:drill:zk=10.10.11.112:5181 –n bridget –p mypw007!)pwmy
+
+Alternatively, a user can launch SQLLine and then issue the !connect command to hide the password.
+
+1. Start SQLLine on Linux by running the sqlline script. 
+
+	    bridgetsmachine:~$ /etc/drill/bin/sqlline
+      	apache drill 1.10.0
+      	"a drill in the hand is better than two in the bush"
+
+1. At the SQLLine prompt, enter the !connect command followed by:
+	`jdbc:drill:zk=zk=<zk name>[:<port>][,<zk name2>[:<port>]... `]`
+	
+	**Example**
+
+        `sqlline> !connect jdbc:drill:zk=localhost:2181 scan complete in 1385m`s
+
+1. When prompted, enter a username and password. The password is hidden as it is typed.
+    
+       	Enter username for jdbc:drill:zk=localhost:2181: bridget
+      	Enter password for jdbc:drill:zk=localhost:2181: ************* 
+
+## Connecting with BI Tools
+
+To connect to a Drill from a BI tool, such as Tableau, the ODBC driver prompts you for the authentication type, username, and password. For PAM, select **Basic Authenticatio**n in the Authentication Type drop-down menu.
+
+![User Auth BI Tools](http://i.imgur.com/J5X1Tds.png)
+
+##Installing and Configuring Plain Authentication
+
+Install and configure the provided Drill PAM for Plain (or username and password) authentication. Drill only supports the PAM provided here. Optionally, you can build and implement a custom authenticator.
+
+---
+
+**Note**
+
+Do not point to an existing directory where other Hadoop components are installed. Other file system libraries can conflict with the Drill libraries and cause system errors. 
+
+---
+
+Complete the following steps to install and configure PAM for Drill:
+
+1. Download the `tar.gz` file for the Linux platform:
+
+	`http://sourceforge.net/projects/jpam/files/jpam/jpam-1.1`/
+
+1. Untar the file, and copy the `libjpam.so` file into a directory that does not contain other Hadoop components. For example, `/opt/pam/`
+
+
+1. Add the following line to `<DRILL_HOME>/conf/drill-env.sh`, including the directory where the `libjpam.s`o file is located: 
+
+    `export DRILLBIT_JAVA_OPTS="-Djava.library.path=<directory>"` 
+
+	**Example**
+
+    	`export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pam/"` 
+
+1. Add the following configuration to the drill.exec block in `<DRILL_HOME>/conf/drill-override.conf`: 
+		
+		  drill.exec {
+		   security.user.auth {
+		         enabled: true,
+		         packages += "org.apache.drill.exec.rpc.user.security",
+		         impl: "pam",
+		         pam_profiles: [ "sudo", "login" ]
+		   } 
+		  }
+
+1. (Optional) To add or remove different PAM profiles, add or delete the profile names in the “pam_profiles” array shown above. 
+
+1. Restart the Drillbit process on each Drill node. 
+
+    `<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
+
+
+
+
+
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md b/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
new file mode 100644
index 0000000..fa70fca
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
@@ -0,0 +1,112 @@
+---
+title: "Configuring Kerberos Authentication"
+date: 2017-03-15 00:30:47 UTC
+parent: "Securing Drill"
+---
+As of version 1.10, Drill supports Kerberos v5 network security authentication.  Kerberos allows trusted hosts to prove their identity over a network to an information system.  A Kerberos realm is unique authentication domain. A centralized key distribution center (KDC) coordinates authentication between a clients and servers. Clients and servers obtain and use tickets from the KDC using a special keytab file to communicate with the KDC and prove their identity to gain access to a drillbit.  Administrators must create principal (user or server) identities and passwords to ensure the secure exchange of mutual authentication information passed to and from the drillbit. 
+
+To use Kerberos with Drill and establish connectivity, use the JDBC driver packaged with Drill 1.10.
+
+---
+**NOTE**
+
+Proper setup, configuration, administration, and usage of a Kerberos environment is beyond the scope of this documentation.  See the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") documentation for information about Kerberos.
+
+---
+
+## Prerequisites
+
+The required Kerberos plugin is part of the 1.10 Drill package. You must have a working Kerberos infrastructure, which Drill does not provide. You must be working in a Linux-based or Windows Active Directory (AD) Kerberos environment and have a Drill server configured for Kerberos. See also [Enabling Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/#enabling-authentication)
+
+## Client Authentication Process 
+
+This section shows a high-level overview of the client authentication process in Kerberos. It is assumed that Kerberos credentials are present in the client.
+
+1. The client sends a request for a ticket granting ticket that contains the user principal to the Kerberos KDC, a network service that supplies tickets and temporary session keys. 
+
+1. The authentication server validates the principal’s identity and sends the client a ticket granting ticket and session key encrypted with a secret key. A session key is a temporary encryption key used for one login session.
+
+1. Using the ticket granting ticket, the principal requests access to a drillbit service from the ticket granting server.
+
+1. The ticket granting server checks for a valid ticket granting ticket and the principal identity. If the request is valid, the ticket granting server returns a ticket granting service ticket.
+
+1. The client uses the service ticket to request access to the drillbit.
+
+1. The drillbit service has access to the keytab, a file that contains a list of keys for principals.  The key allows the service to decrypt the client’s ticket granting service ticket, identify the principal, and grant access.
+
+
+![Kerberos Auth Process Overview](http://i.imgur.com/U6e8FR5.png)
+
+## Server Authentication Process
+For Kerberos server authentication information, see the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") administration documentation. 
+
+
+## Enabling Authentication
+During startup, a drillbit service must authenticate. At runtime, Drill uses the keytab file. Trust is based on the keytab file; it’s secrets are shared with the KDC. The drillbit service also uses this keytab credential to validate service tickets from clients. Based on this information, the drillbit determines whether the client’s identity can be verified to use its service. 
+
+---
+**NOTE**
+
+Drill must  run as a user capable of impersonation. The Kerberos provider in the SASL framework maps from the Kerberos identity to an OS user name. Drill impersonates the OS username when running queries. 
+
+---
+
+
+![Kerberos Client-Server Connection](http://i.imgur.com/04S0vss.png)
+
+
+
+
+1. Create a Kerberos principal identity and a keytab file.  You can create one principal for each drillbit or one principal for all drillbits in a cluster. The drill.keytab file must be owned by and readable by the administrator user.
+
+	- For a single principal per node in cluster:
+
+			# kadmin  
+			: addprinc -randkey <username>/<FQDN>@<REALM>.COM  
+			: ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
+
+		(where FQDN is the hostname of the drillbit server. If you have multiple servers, you must create a principal and keytab for each server.)
+	
+	- For a single principal per cluster, use `<clustername>` instead of `<FQDN>`:
+
+			# kadmin  
+			: addprinc -randkey <username>/<clustername>@<REALM>.COM  
+			: ktadd -k /opt/mapr/conf/drill.keytab <username>/<FQDN>@<REALM>.COM
+1. Add the Kerberos principal identity and keytab file to the `drill-override.conf` file.
+
+	- The instance name must be lowercase. Also, if \_HOST is set as the instance name in the principal, it is replaced with the fully qualified domain name of that host for the instance name. For example, if a drillbit running on `host01.aws.lab` uses `drill/_HOST@<EXAMPLE>.COM` as the principal, the canonicalized principal is `drill/host01.aws.lab@<EXAMPLE>.COM`.  
+
+		    drill.exec {  
+   				security: {  
+ 					user.auth.enabled:true,  
+ 					auth.mechanisms:[“KERBEROS”],  
+ 					auth.principal:“drill/<clustername>@<REALM>.COM”,  
+ 					auth.keytab:“/etc/drill/conf/drill.keytab”  
+				}  
+			}   
+	- To configure multiple mechanisms, extend the mechanisms list and provide additional configuration parameters. For example, the following configuration enables Kerberos and Plain (username and password) mechanisms. See Installing and Configuring Plain Authentication for PAM configuration instructions.  
+
+			drill.exec: {  
+				security: {  
+					user.auth.enabled:true,  
+					user.auth.impl:"pam",  
+					user.auth.pam_profile:["sudo", "login"],  
+					auth.mechanisms:["KERBEROS","PLAIN"],  
+					auth.principal:"drill/<clustername>@<REALM>.COM",  
+					auth.keytab:"/etc/drill/conf/drill.keytab"  
+				}  
+			}  
+
+3 . Restart the drillbit process on each Drill node.
+
+	`<DRILLINSTALL_HOME>/bin/drillbit.sh restart`
+
+## Using Connection URLs
+
+In Drill 1.10, Kerberos authentication introduces new URL parameters. The simplest way to connect using Kerberos is to generate a TGT on the client side. In the JDBC connection string, only specify the service principal. For example:
+
+     jdbc:drill:  
+     drillbit=10.10.10.10;  
+     principal=drill/<serverhostname>@<REALM>.COM  
+
+

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/configure-drill/securing-drill/091-configuring-web-ui-and-rest-api-security.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/091-configuring-web-ui-and-rest-api-security.md b/_docs/configure-drill/securing-drill/091-configuring-web-ui-and-rest-api-security.md
new file mode 100644
index 0000000..2f418d0
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/091-configuring-web-ui-and-rest-api-security.md
@@ -0,0 +1,111 @@
+---
+title: "Configuring Web Console and REST API Security"
+date: 2016-02-08 21:57:12 UTC
+parent: "Securing Drill"
+---
+Drill 1.5 extends [Drill user authentication]({{site.baseurl}}/docs/configuring-user-authentication/) to the Web Console and underlying REST API. As administrator, you can control the extent of access to the Web Console and REST API client applications. For example,
+you can limit the access of certain users to Web Console functionality, such as viewing the in-progress or completed queries of other users. You can limit users from viewing other users' query profiles, who can cancel queries of other users, and other functionality.
+
+With Web Console security in place, users who do not have administrator privileges need to use the SHOW SCHEMAS command instead of the Web Console for storage plugin configuration information.
+
+## HTTPS Support
+Drill 1.2 uses code-level support for transport layer security (TLS) to secure the Web Console and REST API. By default, the Web Console and REST API support the HTTP protocol. You set the following start-up option to TRUE to enable HTTPS support:
+
+`drill.exec.http.ssl_enabled`
+
+By default this start-up option is set to FALSE.
+
+Drill generates a self-signed certificate that works with SSL for HTTPS access to the Web Console. Because Drill uses a self-signed certificate, you see a warning in the browser when you go to `https://<node IP address>:8047`. The Chrome browser, for example, requires you to click `Advanced`, and then `Proceed to <address> (unsafe)`. If you have a signed certificate by an authority, you can set up a custom SSL to avoid this warning. You can set up SSL to specify the keystore or truststore, or both, for your organization, as described in the next section.
+
+## Setting Up a Custom SSL Configuration
+
+As cluster administrator, you can set the following SSL configuration parameters in the `conf/drill-override.conf` file, as described in the [Java product documentation](http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html/#Customization):
+
+* javax.net.ssl.keyStore  
+  Path to the application's certificate and private key in the Java keystore file.  
+* javax.net.ssl.keyStorePassword  
+  Password for accessing the private key from the keystore file.  
+* javax.net.ssl.trustStore  
+  Path to the trusted CA certificates in a keystore file.  
+* javax.net.ssl.trustStorePassword  
+  Password for accessing the trusted keystore file.
+ 
+## Prerequisites for Web Console and REST API Security
+
+You need to perform the following configuration tasks using Web Console and REST API security.  
+
+* Configure [user authentication]({{site.baseurl}}/docs/configuring-user-authentication/)  
+* Set up Web Console administrators  
+  Optionally, you can set up Web Console administrator-user groups to facilitate management of multiple Web Console administrators.
+
+## Setting up Web Console Administrators and Administrator-User Groups
+
+Configure the following system options using the [ALTER SYSTEM]({{site.baseurl}}/docs/alter-system/) command:
+
+* security.admin.users  
+  Set the value of this option to a comma-separated list of user names who you want to give administrator privileges, such as changing system options.  
+* security.admin.user_groups  
+  Set the value of this option to a comma-separated list of administrator groups.
+
+Any user who is a member of any group listed in security.admin.user.groups is a Drill cluster administrator. Any user for whom you have configured Drill user authentication, but not set up as a Drill cluster administrator, has only user privileges to access the Web Console and REST API client applications.
+
+## Web Console and REST API Privileges
+
+The following table and subsections describe the privilege levels for accessing the REST API methods and corresponding Web Console functions:
+
+* Administrator (ADMIN)  
+* User (USER)  
+* Administrator and User (ALL) 
+
+| Resource Method          | Path                         | Request Type | Output Type      | Functionality                                                                                                                                                                                                                                               | Privilege Level                                                                                               |
+|--------------------------|------------------------------|--------------|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
+| getStats                 | /                            | GET          | text/html        | Returns Drillbit stats in a table in HTML format.                                                                                                                                                                                                           | ALL                                                                                                           |
+| getStatsJSON             | /stats.json                  | GET          | application/json | Returns Drillbit stats such as ports and max direct memory in json format.                                                                                                                                                                                  | ALL                                                                                                           |
+| getStatus                | /status                      | GET          | text/html        | Returns Running!                                                                                                                                                                                                                                            | ALL                                                                                                           |
+| getSystemOptionsJSON     | /options.json                | GET          | application/json | Returns a list of options. Each option consists of name-value-type-kind (for example: (boot system datatype).                                                                                                                                               | ALL                                                                                                           |
+| getSystemOptions         | /options                     | GET          | text/html        | Returns an HTML table where each row is a form containing the option details that allows option values to be modified.                                                                                                                                      | ALL                                                                                                           |
+| updateSystemOption       | /option/{optionName}         | POST         | text/html        | Updates the options and calls getSystemOptions. So again an option list is displayed.                                                                                                                                                                       | ADMIN                                                                                                         |
+| getStoragePluginsJSON    | /storage.json                | GET          | application/json | Returns a list of storage plugin wrappers each containing name-config (instance of StoragePluginConfig) and enabled.                                                                                                                                        | ADMIN                                                                                                         |
+| getStoragePlugins        | /storage                     | GET          | text/html        | Returns an HTML page with two sections: The first section contains a table of rows that are forms containing the plugin button for the update page and a button to disable the plugin. The second section is the same except the button enables the plugin. | ADMIN                                                                                                         |
+| getStoragePluginJSON     | /storage/{name}.json         | GET          | application/json | Returns a plugin config wrapper for the requested web page.                                                                                                                                                                                                 | ADMIN                                                                                                         |
+| getStoragePlugin         | /storage/{name}              | GET          | text/html        | Returns an HTML page that has an editable text box for configuration changes and buttons for creating/updating/deleting. Each button makes calls that regenerate the page.                                                                                  | ADMIN                                                                                                         |
+| enablePlugin             | /storage/{name}/enable/{val} | GET          | application/json | Updates the storage plugin configuration status. Returns success or failure.                                                                                                                                                                                | ADMIN                                                                                                         |
+| deletePluginJSON         | /storage/{name}.json         | DELETE       | application/json | Deletes the storage plugin. Returns success or failure.                                                                                                                                                                                                     | ADMIN                                                                                                         |
+| deletePlugin             | /storage/{name}/delete       | GET          | application/json | Same as deletePluginJSON but a GET instead of a DELETE request.                                                                                                                                                                                             | ADMIN                                                                                                         |
+| createOrUpdatePluginJSON | /storage/{name}.json         | POST         | application/json | Creates or updates the storage plugin configuration. Returns success or failure. Expects JSON input.                                                                                                                                                        | ADMIN                                                                                                         |
+| createOrUpdatePlugin     | /storage/{name}              | POST         | application/json | Same as createOrUpdatePluginJSON expects JSON or FORM input.                                                                                                                                                                                                | ADMIN                                                                                                         |
+| getProfilesJSON          | /profiles.json               | GET          | application/json | Returns currently running and completed profiles from PStore. For each profile a queryId, startTime, foremanAddress, query, user, and state is returned. Each list (running and completed) is organized in reverse chronological order.                     | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles.json)             |
+| getProfiles              | /profiles                    | GET          | text/html        | Generates an HTML page from the data returned by getProfilesJSON with a hyperlink to a detailed query page,                                                                                                                                                 | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles)                  |
+| getProfileJSON           | /profiles/{queryid}.json     | GET          | application/json | Returns the entire profile in JSON.                                                                                                                                                                                                                         | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/{queryid}.json)   |
+| getProfile               | /profiles/{queryid}          | GET          | text/html        | Returns a complicated profile page.                                                                                                                                                                                                                         | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/{queryid})        |
+| cancelQuery              | /profiles/cancel/{queryid}   | GET          | text/html        | Cancels the given query and sends a message.                                                                                                                                                                                                                | [ADMIN, USER]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security/#get-/profiles/cancel/{queryid}) |
+| getQuery                 | /query                       | GET          | text/html        | Gets the query input page.                                                                                                                                                                                                                                  | ALL                                                                                                           |
+| submitQueryJSON          | /query.json                  | POST         | application/json | Submits a query and waits until it is completed and then returns the results as one big JSON object.                                                                                                                                                        | ALL                                                                                                           |
+| submitQuery              | /query                       | POST         | text/html        | Returns results from submitQueryJSON populated in a HTML table.                                                                                                                                                                                             | ALL                                                                                                           |
+| getMetrics               | /metrics                     | GET          | text/html        | Returns a page that fetches metric info from resource, status, and metrics.                                                                                                                                                                                 | ALL                                                                                                           |
+| getThreads               | /threads                     | GET          | text/html        | Returns a page that fetches metric information from resource, status, and threads.                                                                                                                                                                          | ALL                                                                                                           |
+
+### GET /profiles.json
+
+* ADMIN - gets all profiles on the system.  
+* USER - only the profiles of the queries the user has launched.
+
+### GET /profiles
+
+* ADMIN - gets all profiles on the system.  
+* USER - only the profiles of the queries the user has launched.
+
+### GET /profiles/{queryid}.json
+
+* ADMIN - return the profile.  
+* USER - if the query is launched the by the requesting user return it. Otherwise, return an error saying no such profile exists.
+
+### GET /profiles/{queryid}
+
+* ADMIN - return the profile.   
+* USER - if the query is launched the by the requesting user return it. Otherwise, return an error saying no such profile exists
+
+### GET /profiles/cancel/{queryid}
+
+* ADMIN - can cancel the query.  
+* USER - cancel the query only if the query is launched by the user requesting the cancellation. 

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/img/kerberauthprocess.png
----------------------------------------------------------------------
diff --git a/_docs/img/kerberauthprocess.png b/_docs/img/kerberauthprocess.png
new file mode 100644
index 0000000..92bb6ac
Binary files /dev/null and b/_docs/img/kerberauthprocess.png differ

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/img/kerberclientserver.png
----------------------------------------------------------------------
diff --git a/_docs/img/kerberclientserver.png b/_docs/img/kerberclientserver.png
new file mode 100644
index 0000000..caaaa66
Binary files /dev/null and b/_docs/img/kerberclientserver.png differ

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/img/plainauthprocess.png
----------------------------------------------------------------------
diff --git a/_docs/img/plainauthprocess.png b/_docs/img/plainauthprocess.png
new file mode 100644
index 0000000..f078adb
Binary files /dev/null and b/_docs/img/plainauthprocess.png differ

http://git-wip-us.apache.org/repos/asf/drill/blob/535d5184/_docs/img/securecommunicationpaths.png
----------------------------------------------------------------------
diff --git a/_docs/img/securecommunicationpaths.png b/_docs/img/securecommunicationpaths.png
new file mode 100644
index 0000000..72acf0d
Binary files /dev/null and b/_docs/img/securecommunicationpaths.png differ


Mime
View raw message