You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@drill.apache.org by br...@apache.org on 2017/08/07 19:05:08 UTC
[2/2] drill git commit: Drill 1.11 Encryption and Security Content
from Catherine Skrbina/Drill 1.11 Identifier Quotes Content from Bridget
Bevens
Drill 1.11 Encryption and Security Content from Catherine Skrbina/Drill 1.11 Identifier Quotes Content from Bridget Bevens
Project: http://git-wip-us.apache.org/repos/asf/drill/repo
Commit: http://git-wip-us.apache.org/repos/asf/drill/commit/25aa6a18
Tree: http://git-wip-us.apache.org/repos/asf/drill/tree/25aa6a18
Diff: http://git-wip-us.apache.org/repos/asf/drill/diff/25aa6a18
Branch: refs/heads/gh-pages
Commit: 25aa6a18e5b32fa0461637e22a1390fbdcd209b8
Parents: 7cab70c
Author: Bridget Bevens <bb...@maprtech.com>
Authored: Mon Aug 7 12:02:14 2017 -0700
Committer: Bridget Bevens <bb...@maprtech.com>
Committed: Mon Aug 7 12:02:14 2017 -0700
----------------------------------------------------------------------
.../010-securing-drill-introduction.md | 31 +--
.../020-secure-communication-paths.md | 26 +-
.../050-configure-inbound-impersonation.md | 22 +-
.../070-configuring-user-authentication.md | 23 --
.../070-configuring-user-security.md | 48 ++++
.../080-configuring-plain-authentication.md | 116 --------
.../080-configuring-plain-security.md | 116 ++++++++
...090-configuring-kerberos-auththentication.md | 266 -------------------
.../090-configuring-kerberos-security.md | 250 +++++++++++++++++
...-configuring-web-ui-and-rest-api-security.md | 6 +-
.../design-docs/020-rpc-overview.md | 25 +-
_docs/img/client-encrypt-compatibility.png | Bin 0 -> 13570 bytes
.../drill-channel-pipeline-with-handlers.png | Bin 0 -> 32476 bytes
_docs/img/kerberos-clnt-svr.png | Bin 0 -> 46792 bytes
_docs/sql-reference/030-lexical-structure.md | 67 ++++-
15 files changed, 525 insertions(+), 471 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
index 3d6846d..636ff67 100644
--- a/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
+++ b/_docs/configure-drill/securing-drill/010-securing-drill-introduction.md
@@ -1,36 +1,25 @@
---
title: "Securing Drill Introduction"
-date: 2017-07-31 20:58:54 UTC
+date: 2017-08-07 19:02:23 UTC
parent: "Securing Drill"
---
Before connecting to a data source, you can configure Drill security features and [secure communication pathways]({{site.baseurl}}/docs/secure-communication-paths/) to a secure Drill cluster. Security features include:
- **Authentication** - Drill supports user authentication to secure clusters with:
- - Kerberos.
- See [Configuring Kerberos Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/).
+ - Kerberos.
+ See [Configuring Kerberos Security]({{site.baseurl}}/docs/configuring-kerberos-security/).
- Username and password (with the Plain mechanism or a Custom Authenticator). See:
- - [Configuring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/)
+ - [Configuring Plain Security]({{site.baseurl}}/docs/configuring-plain-security/)
- [Creating Custom Authenticators]({{site.baseurl}}/docs/creating-custom-authenticators)
- - Digest
+ - Digest
+- **Encryption** - Drill supports client-to-drillbit encryption with Kerberos to ensure date confidentiality and integrity in Drill 1.11. See [Configuring Kerberos Security]({{site.baseurl}}/docs/configuring-kerberos-security/).
- **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 supports client-to-drillbit encryption in Drill 1.11.
-
-
-
-
-
-
-
-
-
-
+- **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/)
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
index 4811705..dcdc4e2 100644
--- a/_docs/configure-drill/securing-drill/020-secure-communication-paths.md
+++ b/_docs/configure-drill/securing-drill/020-secure-communication-paths.md
@@ -1,20 +1,19 @@
---
title: "Secure Communication Paths"
-date: 2017-07-31 20:58:55 UTC
+date: 2017-08-07 19:02:29 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.
+As illustrated in the following figure, Drill features five secure communication paths. Drill 1.11 introduces encryption between a Drill client and Drillbit.
-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
+1. [Web Client to Drillbit]({{site.baseurl}}/docs/server-communication-paths/#web-client-to-drillbit)
+1. [C++ Client to Drillbit]({{site.baseurl}}/docs/server-communication-paths/#c++-client-to-drillbit)
+1. [Java Client to Drillbit]({{site.baseurl}}/docs/server-communication-paths/#java-client-to-drillbit)
+1. [Java Client and Drillbit to ZooKeeper]({{site.baseurl}}/docs/server-communication-paths/#java-client-and-drillbit-to-zookeeper)
+1. [Drillbit to Hive Storage Plugin]({{site.baseurl}}/docs/server-communication-paths/#drillbit-to-hive-storage-plugin)
-
## Web Client to Drillbit
The Web Console and REST API clients are web clients. Web clients can:
@@ -25,16 +24,16 @@ The Web Console and REST API clients are web clients. Web clients can:
---
**Note**
-Impersonation, authorization, and encryption are available through the web clients only when authentication and encryption are enabled. Otherwise, the user identity is unknown and encryption is not used.
+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]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security) |
-| Encryption | Drill 1.11 supports encryption between a Drill client and Drillbit using the Kerberos mechanism over a Java SASL framework. Encrypting the client-to-drillbit communication pathway ensures data integrity and prevents data tampering as well as snooping. On the server side, enable encryption in the drill-override.conf file with the security.user.encryption.sasl.enabled parameter. On the client side, use the sasl_encrypt parameter in the connection string. | [Configuring Kerberos Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/) |
+| Encryption | Drill usese SSL for HTTPS access to the Web Console. | [Configuring Web Console and REST API Security]({{site.baseurl}}/docs/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]({{site.baseurl}}/docs/configuring-user-impersonation/#impersonation-and-views) and [Configuring Inbound Impersonation]({{site.baseurl}}/docs/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]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security) | |
+| 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]({{site.baseurl}}/docs/configuring-web-console-and-rest-api-security) |
## Java and C++ Client to Drillbit
@@ -42,7 +41,8 @@ Java (native or JDBC) and C++ (native or ODBC) clients submit queries to Drill.
| 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]({{site.baseurl}}/docs/configuring-user-authentication) |
+| 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 Security]({{site.baseurl}}/docs/configuring-user-security) |
+| Encryption | Drill 1.11 supports encryption between a Drill client and a Drillbit with the Kerberos mechanism over a Java SASL framework. Encrypting the client-to-drillbit communication path ensures data integrity and privacy and prevents data tampering and snooping. If encryption is enabled on a drillbit, it will not allow a client without encryption capabilities to connect. By default, encryption is disabled. | [Configuring Kerberos Security]({{site.baseurl}}/docs/configuring-kerberos-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. 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]({{site.baseurl}}/docs/configuring-user-impersonation) and [Configuring Inbound Impersonation]({{site.baseurl}}/docs/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]({{site.baseurl}}/docs/configuring-user-impersonation) |
@@ -52,7 +52,7 @@ Drill clients and drillbits communicate with ZooKeeper to obtain the list of act
| Security Capability | Description | Reference |
|---------------------|-----------------------------------------------------|---------------------------------|
-| Authentication | Not fully supported. | [Configuring User Authentication]({{site.baseurl}}/docs/configuring-user-authentication) |
+| Authentication | Not fully supported. | [Configuring User Security]({{site.baseurl}}/docs/configuring-user-security) |
| Authorization | Drill does not set ACLs on ZooKeeper nodes (znode). | |
| Encryption | Not fully supported. | [ZooKeeper SSL User Guide](https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide "ZooKeeper SSL User Guide") |
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
index e4c3e38..afe2c8a 100644
--- a/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md
+++ b/_docs/configure-drill/securing-drill/050-configure-inbound-impersonation.md
@@ -1,12 +1,12 @@
---
title: "Configuring Inbound Impersonation"
-date: 2017-07-27 20:41:28 UTC
+date: 2017-08-07 19:02:34 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.
+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-security/) 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.
@@ -46,22 +46,8 @@ 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.
+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:
-The following examples show you how to do this for JDBC and ODBC:
-
-
-- For JDBC, through SQLLine using the `impersonation_target` connection property:
-
- bin/sqlline –u “jdbc:drill:schema=dfs;zk=myclusterzk;impersonation_target=euser1” -n puser1 -p ppass1
+ 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`.
-
-
-- For ODBC on Linux or Mac, you can pass the username through the `DelegationUID` property in the odbc.ini file. See [Configuring ODBC on Linux]({{site.baseurl}}/docs/configuring-odbc-on-linux/) for more information.
-
-
- DelegationUID=euser1
-
-
-If you are using ODBC on Windows, you can use the **ODBC Data Source Administrator** to provide the username through the `Delegation UID` field in the MapR Drill ODBC Driver DSN Setup dialog box. See [Configuring ODBC on Windows]({{site.baseurl}}/docs/configuring-odbc-on-windows/) for more information.
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
deleted file mode 100644
index fb7a6ea..0000000
--- a/_docs/configure-drill/securing-drill/070-configuring-user-authentication.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: "Configuring User Authentication"
-date: 2017-07-31 20:58:56 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** - Featuring Drill client to Drillbit encryption in Drill 1.11. See [Configuring Kerberos Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/).
-* **Plain** [also known as basic authentication (auth), which is username and password-based authentication, through the Linux Pluggable Authentication Module (PAM)] - See [Configuring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/).
-* **Custom authenticators** - See [Creating Custom Authenticators]({{site.baseurl}}/docs/creating-custom-authenticators).
-
-These authentication options are available through JDBC and ODBC interfaces.
-
-
-{% include startnote.html %}Enabling both user impersonation and authentication is recommended to restrict access to data and improve security. When 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.{% include endnote.html %}
-
-For more information, see [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/).
-
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_docs/configure-drill/securing-drill/070-configuring-user-security.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/070-configuring-user-security.md b/_docs/configure-drill/securing-drill/070-configuring-user-security.md
new file mode 100644
index 0000000..f25b457
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/070-configuring-user-security.md
@@ -0,0 +1,48 @@
+---
+title: "Configuring User Security"
+date: 2017-05-17 01:38:49 UTC
+parent: "Securing Drill"
+---
+### Authentication
+
+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 supports several authentication mechanisms through which users can prove their identity before accessing cluster data:
+
+* **Kerberos** - See [Configuring Kerberos Security]({{site.baseurl}}/docs/configuring-kerberos-security/).
+* **Plain** [also known as basic authentication (auth), which is username and password-based authentication, through the Linux Pluggable Authentication Module (PAM)] - See [Configuring Plain Security]({{site.baseurl}}/docs/configuring-plain-security/).
+* **Custom authenticators** - See [Creating Custom Authenticators]({{site.baseurl}}/docs/creating-custom-authenticators).
+
+These authentication options are available through JDBC and ODBC interfaces.
+
+### Encryption
+
+Drill 1.11 introduces client-to-drillbit encryption for over-the-wire security using the Kerberos to:
+
+* Ensure data integrity and privacy
+* Prevent data tampering and snooping
+
+
+See [Configuring Kerberos Security]({{site.baseurl}}/docs/configuring-kerberos-security/) for information about how to enable a drillbit for encryption.
+
+{% include startnote.html %}The Plain mechanism does not support encryption.{% include endnote.html %}
+#### Cipher Strength
+
+By default, the highest security level is negotiated during the SASL handshake for each client-to-drillbit connection so that the AES-256 ciper is used when supported by key distribution center (KDC) encryption types. See [Encryption Types](http://web.mit.edu/kerberos/krb5-1.13/doc/admin/enctypes.html](http://web.mit.edu/kerberos/krb5-1.13/doc/admin/enctypes.html "Encryption Types") in the MIT Kerberos documentation for details about specific combinations of cipher algorithms.
+
+#### Client Compatibility
+The following table shows Drill client version compatibility with secure Drill clusters enabled with encryption. Drill 1.10 clients and lower do not support encryption and will not be allowed to connect to a drillbit with encryption enabled.
+
+
+
+See *Client Encryption* in [Configuring Kerberos Security]({{site.baseurl}}/docs/server-communication-paths/#configuring-kerberos-security#client-encryption) for the client connection string parameter, `sasl_encrypt` usage information.
+
+### Impersonation
+
+Enabling both user impersonation and authentication is recommended to restrict access to data and improve security. When 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.
+
+For more information, see [Configuring User Impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) and [Configuring Inbound Impersonation]({{site.baseurl}}/docs/configuring-inbound-impersonation/).
+
+
+
+
+
+
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
deleted file mode 100644
index 5a4209c..0000000
--- a/_docs/configure-drill/securing-drill/080-configuring-plain-authentication.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: "Configuring Plain Authentication"
-date: 2017-05-17 01:38:50 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-sqlline)
-- [Connecting with BI Tools]({{site.baseurl}}/docs/configuring-plain-authentication/#connecting-with-bi-tools)
-- [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.
-
-
-
-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 Authentication** in the Authentication Type drop-down menu.
-
-
-
-##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.
-
-{% include startnote.html %}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.{% include endnote.html %}
-
-
-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: {
- cluster-id: "drillbits1",
- zk.connect: "qa102-81.qa.lab:5181,qa102-82.qa.lab:5181,qa102-83.qa.lab:5181",
- impersonation: {
- enabled: true,
- max_chained_user_hops: 3
- },
- security: {
- auth.mechanisms : ["PLAIN"],
- },
- 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/25aa6a18/_docs/configure-drill/securing-drill/080-configuring-plain-security.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/080-configuring-plain-security.md b/_docs/configure-drill/securing-drill/080-configuring-plain-security.md
new file mode 100644
index 0000000..190c759
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/080-configuring-plain-security.md
@@ -0,0 +1,116 @@
+---
+title: "Configuring Plain Security"
+date: 2017-05-17 01:38:50 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-security/#authentication-process)
+- [Connecting with SQLLine]({{site.baseurl}}/docs/configuring-plain-security/#connecting-with-sqlline)
+- [Connecting with BI Tools]({{site.baseurl}}/docs/configuring-plain-security/#connecting-with-bi-tools)
+- [Installing and Configuring Plain Security]({{site.baseurl}}/docs/configuring-plain-security/#installing-and-configuring-plain-security)
+
+## 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.
+
+
+
+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 Authentication** in the Authentication Type drop-down menu.
+
+
+
+##Installing and Configuring Plain Security
+
+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.
+
+{% include startnote.html %}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.{% include endnote.html %}
+
+
+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: {
+ cluster-id: "drillbits1",
+ zk.connect: "qa102-81.qa.lab:5181,qa102-82.qa.lab:5181,qa102-83.qa.lab:5181",
+ impersonation: {
+ enabled: true,
+ max_chained_user_hops: 3
+ },
+ security: {
+ auth.mechanisms : ["PLAIN"],
+ },
+ 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/25aa6a18/_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
deleted file mode 100644
index 3261444..0000000
--- a/_docs/configure-drill/securing-drill/090-configuring-kerberos-auththentication.md
+++ /dev/null
@@ -1,266 +0,0 @@
----
-title: "Configuring Kerberos Authentication"
-date: 2017-07-31 20:58:57 UTC
-parent: "Securing Drill"
----
-In release 1.11 Drill supports Kerberos v5 network security authentication and client-to-drillbit encryption. To use Kerberos with Drill and establish connectivity, use the JDBC driver packaged with Drill 1.11.
-
-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.
-
-{% include startnote.html %}Proper setup, configuration, administration, and usage of a Kerberos environment is beyond the scope of this documentation.{% include endnote.html %}
-
-See the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") documentation for information about Kerberos.
-
-
-## Prerequisites
-
-The required Kerberos (JDBC) plugin is part of the 1.11 Drill package. To use it, 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 with secure clusters and have a Drill server configured for Kerberos. See [Enabling Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/#enabling-authentication).
-
-## Client Authentication Process
-
-This section provides a high-level overview of the Kerberos client authentication process. 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.
-
-## Server Authentication Process
-For Kerberos server authentication information, see the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") administration documentation.
-
-
-## Enabling Authentication and Encryption
-During startup, a drillbit service must authenticate. At runtime, Drill uses the keytab file. Trust is based on the keytab file; its 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.
-
-To enable encryption,set the following parameters in the `drill-override.conf` file (as shown in the second example below):
-
-
-- `security.user.encryption.sasl.enabled` to true. This parameter determines if the drillbit is enabled for encryption. Only Drill 1.11 drillbits support encryption.
-
-- `security.user.encryption.sasl.max_wrapped_size`. This parameter specifies the maximum size of encoded buffer in bytes (maxbuffer parameter in sasl) that the client and server will receive. Using this the SASL framework exposes maximum buffer size that the wrap function will accept, so that Drill client/server can chop the Outbound RPC message with the size. The maximum recommended value is 16777215. The default is 65536.
-
-
-
-
-
- 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
-
-
- * 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
-
-
-2. 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: {
- cluster-id: "drillbits1",
- zk.connect: "qa102-81.qa.lab:2181,qa102-82.qa.lab:2181,qa102-83.qa.lab:2181",
- impersonation: {
- enabled: true,
- max_chained_user_hops: 3
- },
- 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 Connfiguring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/#installing-and-configuring-plain-authentication) for Plain PAM configuration instructions.
-
- drill.exec: {
- cluster-id: "drillbits1",
- zk.connect: "qa102-81.qa.lab:2181,qa102-82.qa.lab:2181,qa102-83.qa.lab:2181",
- impersonation: {
- enabled: true,
- max_chained_user_hops: 3
- },
- security: {
- user.auth.enabled:true,
- auth.mechanisms:["KERBEROS","PLAIN"],
- auth.principal:“drill/<clustername>@<REALM>.COM”,
- auth.keytab:“/etc/drill/conf/drill.keytab”
- }
- security.user: {
- auth.enabled: true,
- auth.packages += "org.apache.drill.exec.rpc.user.security",
- auth.impl: "pam",
- auth.pam_profiles: ["sudo", "login"],
- encryption.sasl.enabled: true,
- encryption.sasl.max_wrapped_size: 65536,
- }
- }
-
-
-
-3. Restart the drillbit process on each Drill node.
-
- <DRILLINSTALL_HOME>/bin/drillbit.sh restart
-
-
-
-4. Configure the mapping from a Kerberos principal to a user account used by Drill.
-
-- Drill uses a Hadoop Kerberos name and rules to transform the Kerberos principal provided by client to the one it will use internally as the client’s identity. By default, this mapping rule extracts the first part from the provided principal. For example, if the principal format is `<Name1>/<Name2>@realm`, the default rule will extract only `Name1` from the principal and `Name1` as the client’s identity on server side.
-
-- Administrators can configure custom rules by setting the `drill.exec.security.auth.auth_to_local` property in `drill-override.conf` file.
-
-See [Mapping from Kerberos Principal to OS user account](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Mapping_from_Kerberos_principal_to_OS_user_account "Mapping from Kerberos Principal") in the [Hadoop in Secure Mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html "Secure Mode Hadoop") documentation for details about how the rule works.
-
-## Using Connection URLs
-
-New client side connection URL parameters are introduced for Kerberos authentication in Drill 1.10. You can use these parameters in multiple combinations to authenticate a client with Drill.
-
-### Client Credentials
-
-A client can provide its credentials in two ways:
-
-- With a ticket granting ticket (TGT) generated on client side. The TGT must be present on client node; Drill does not generate the TGT.
-
-- With a keytab file and the client principal provided in the user property of the connection URL.
-
-### Configuration Options
-The following table lists configuration options for connection URLs. See the Connection URL Examples section for sample URLs.
-
-| Connection Parameter | Description | Mandatory/Optional | Default Value |
-|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| auth | Authentication mechanism. The value is deduced if not specified. Kerberos if principal is provided. Plain if a user and password is provided. A Drill client can also explicitly specify a particular authentication mechanism to use using this parameter. For example, <auth=kerberos> for Kerberos along with service_name, service_host or principal and <auth=plain> for the Plain authentication with username and password. | Optional | The preference order is Kerberos and Plain. |
-| principal | Drillbit service principal. The format of the principal is primary/instance@realm. For Kerberos, the Drill service principal is derived if the value is not provided using this configuration. service_name (primary) and service_host (instance) are used to generate a valid principal. Since the ticket or keytab contains the realm information, the realm is optional. | Optional | |
-| keytab | For Kerberos, if the client chooses to authenticate using a keytab rather than a ticket, set the keytab parameter to the location of the keytab file. The client principal must be provided through the user parameter. A Kerberos ticket is used as the default credential (It is assumed to be present on client-side. The Drill client does not generate the required credentials.) | Optional | |
-| sasl_encrypt | When set to true, ensures that a client connects to a server with encryption capabilities. For example, Drill 1.11 drillbits, which support client-to-drillbit encryption. | Optional | false |
-| service_name | Primary name of the drillbit service principal. | Optional | drill |
-| service_host | Instance name of the drillbit service principal. | Optional | Since this value is usually the hostname of the node where a drillbit is running, the default value is the drillbit hostname is provided either through ZooKeeper or through a direct connection string. |
-| realm | Kerberos realm name for the drillbit service principal. The ticket or keytab contains the realm information. | Optional | |
-
-
-### Client Encryption
-A client can specify that it requires a server with encryption capabilities only by setting the `sasl_encrypt` connection parameter to **true**. If the cluster to which client is connecting has encryption disabled, the client will fail to connect to that server.
-
- drill.exec {
- security: {
- user.auth.enabled: true,
- auth.mechanisms: ["KERBEROS"],
- auth.principal: "drill/serverhostname@REALM.COM",
- auth.keytab: "/etc/drill/conf/drill.keytab",
- user.encryption.sasl.enabled: true
- }
- }
-
-
-### Connection URL Examples
-
-The following five examples show the JDBC connection URL that the embedded JDBC client uses for Kerberos authentication. The first section, Example of a Simple Connection URL, includes a simple connection string and the second section, Examples of Connection URLs Used with Previously Generated TGTs, includes examples to use with previously generated TGTs.
-
-- Example 1: TGT for Client Credentials
-- Example 2: Drillbit Provided by Direct Connection String and Configured with a Unique Service Principal
-- Example 3: Drillbit Selected by ZooKeeper and Configured with a Unique Service Principal
-- Example 4: Drillbit Selected by Zookeeper and Configured with a Common Service Principal
-- Example 5: Keytab for Client Credentials
-
-#### Example of a Simple Connection URL
-
-##### Example 1: TGT for Client Credentials
-The simplest way to connect using Kerberos is to generate a TGT on the client side. Only specify the service principal in the JDBC connection string for the drillbit the user wants to connect to.
-
-
- jdbc:drill:drillbit=10.10.10.10;principal=<principal for host 10.10.10.10>
-
-In this example, the Drill client uses the:
-
-- Default `service_name`, which is **`drill`**.
-- `service_host` from the drillbit name provided in the connection URL, which is **`10.10.10.10`**.
-
-The service principal format is `<primary>/<instance>@<realm from TGT>`. The service principal is **`principal for host 10.10.10.10`**.
-
-#### Examples of Connection URLs Used with Previously Generated TGTs
-If you do not provide a service principal in the connection string when using Kerberos authentication, then use the `service_name` or `service_host` parameters. Since these parameters are optional, their default values will be used internally (if not provided) to create a valid principal.
-
-Examples 2 through 4 show a valid connection string for Kerberos authentication if a client has previously generated a TGT. Realm information will be extracted from the TGT if it is not provided.
-
-{% include startnote.html %}For end-to-end authentication to function, it is assumed that the proper principal for the drillbit service is configured in the KDC.{% include endnote.html %}
-
-
-##### Example 2: Drillbit Provided by Direct Connection String and Configured with a Unique Service Principal
-
-This type of connection string is used when:
-
-- Each drillbit in the cluster is configured with its own service principal.
-- The instance component is the host address of the drillbit.
-
- `jdbc:drill:drillbit=host1;auth=kerberos`
-
-In this example, the Drill client uses the:
-
-- Default `service_name`, which is **`drill`**.
-- `service_host`, which is the drillbit name provided in the connection URL (**`host1`**).
-
-The internally created service principal will be **`drill/host1@<realm from TGT>`**.
-
-##### Example 3: Drillbit Selected by ZooKeeper and Configured with Unique Service Principal
-
-This type of connection string is used when the drillbit is chosen by ZooKeeper instead of directly from the connection string.
-
- jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill
-
-In this example, the Drill client uses the:
-
-- Provided `service_name`, which is **`myDrill`** as the primary name of the principal.
-- `service_host` as the address of the drillbit, which is chosen from the list of active drillbits that ZooKeeper provides (**`host01.aws.lab:5181`**).
-
-The internally created service principal will be **`myDrill/<host address from zk>@<realm from TGT>`**.
-
-##### Example 4: Drillbit Selected by Zookeeper and Configured with a Common Service Principal
-
-This type of connection string is used when all drillbits in a cluster use the same principal.
-
- jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill;service_host=myDrillCluster
-
-In this example, the Drill client uses the:
-
-- Provided `service_name`, which is **`myDrill`**.
-- `service_host`, which is **`myDrillCluster`**.
-
-The internally created service principal, which will be **`myDrill/myDrillCluster@<realm from TGT>`**.
-
-##### Example 5: Keytab for Client Credentials
-
-If a client chooses to provide its credentials in a keytab instead of a TGT, it must also provide a principal in the user parameter. In this case, realm information will be extracted from the `/etc/krb5.conf` file on the node if it is not provided in the connection URL. All other parameters can be used as shown in the preceding examples (1-4). This connection string is for the case when all drillbits in a cluster use the same principal.
-
- jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill;service_host=myDrillCluster;keytab=<path to keytab file>;user=<client principal>
-
-In this example, the Drill client:
-
-- Will authenticate itself with the:
- - Keytab (**`path to keytab file`**) and
- - Principal provided in the user parameter (**`client principal`**)
-- Uses the:
- - Provided `service_name`, which is **`myDrill`**.
- - `service_host`, which is **`myDrillCluster`**.
-
-The internally created service principal will be **`myDrill/myDrillCluster@<realm from krb5.conf>`**.
-
-#####
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_docs/configure-drill/securing-drill/090-configuring-kerberos-security.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/securing-drill/090-configuring-kerberos-security.md b/_docs/configure-drill/securing-drill/090-configuring-kerberos-security.md
new file mode 100644
index 0000000..3cea262
--- /dev/null
+++ b/_docs/configure-drill/securing-drill/090-configuring-kerberos-security.md
@@ -0,0 +1,250 @@
+---
+title: "Configuring Kerberos Security"
+date: 2017-05-17 01:38:52 UTC
+parent: "Securing Drill"
+---
+Drill 1.11 supports Kerberos v5 network security authentication and client-to-drillbit encryption for Kerberos. To use Kerberos with Drill and establish connectivity, use the JDBC driver packaged with Drill.
+
+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.
+
+{% include startnote.html %}Proper setup, configuration, administration, and usage of a Kerberos environment is beyond the scope of this documentation.{% include endnote.html %}
+
+See the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") documentation for information about Kerberos.
+
+
+## Prerequisites
+
+The required Kerberos (JDBC) plugin is part of the Drill 1.11 package. To use it, 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 with secure clusters and have a Drill server configured for Kerberos. See [Enabling Authentication]({{site.baseurl}}/docs/configuring-kerberos-authentication/#enabling-authentication).
+
+## Client Authentication Process
+
+This section provides a high-level overview of the Kerberos client authentication process. 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.
+
+## Server Authentication and Encryption Process
+For Kerberos server authentication information, see the [MIT Kerberos](http://web.mit.edu/kerberos/ "MIT Kerberos") administration documentation.
+
+### Enabling Authentication and Encryption
+During startup, a drillbit service must authenticate. At runtime, Drill uses the keytab file. Trust is based on the keytab file; its 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.
+
+With encryption enabled, negotiation occurs for the most secure level of encryption such that a AES-256 cipher is used (if it's available as a KDC-supported encyption type). Setting the `security.user.encryption.sasl.enabled` parameter in the `drill-override.conf` file to **true** enables encryption for Kerberos.
+
+ 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
+
+
+ * 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
+
+
+2. 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`.
+
+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 Connfiguring Plain Authentication]({{site.baseurl}}/docs/configuring-plain-authentication/#installing-and-configuring-plain-authentication) for Plain PAM configuration instructions.
+
+ drill.exec: {
+ cluster-id: "drillbits1",
+ zk.connect: "qa102-81.qa.lab:2181,qa102-82.qa.lab:2181,qa102-83.qa.lab:2181",
+ impersonation: {
+ enabled: true,
+ max_chained_user_hops: 3
+ },
+ security: {
+ **auth.mechanisms**:["KERBEROS","PLAIN"],
+ **auth.principal**:“drill/<clustername>@<REALM>.COM”,
+ **auth.keytab**:“/etc/drill/conf/drill.keytab”
+ }
+ security.user: {
+ auth.enabled: true,
+ auth.packages += "org.apache.drill.exec.rpc.user.security",
+ auth.impl: "pam",
+ auth.pam_profiles: ["sudo", "login"],
+ }
+ }
+
+3. Set the `security.user.encryption.sasl.enabled` parameter to **true**. (Only Kerberos supports encryption.)
+
+
+ drill.exec: {
+ cluster-id: "drillbits1",
+ zk.connect: "qa102-81.qa.lab:2181,qa102-82.qa.lab:2181,qa102-83.qa.lab:2181",
+ impersonation: {
+ enabled: true,
+ max_chained_user_hops: 3
+ },
+ security: {
+ user.auth.enabled: true,
+ user.encryption.sasl.enabled: true,
+ auth.mechanisms: [“KERBEROS”],
+ 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
+
+
+
+4. Configure the mapping from a Kerberos principal to a user account used by Drill.
+
+- Drill uses a Hadoop Kerberos name and rules to transform the Kerberos principal provided by client to the one it will use internally as the client’s identity. By default, this mapping rule extracts the first part from the provided principal. For example, if the principal format is `<Name1>/<Name2>@realm`, the default rule will extract only `Name1` from the principal and `Name1` as the client’s identity on server side.
+
+- Administrators can configure custom rules by setting the `drill.exec.security.auth.auth_to_local` property in `drill-override.conf` file.
+
+See [Mapping from Kerberos Principal to OS user account](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html#Mapping_from_Kerberos_principal_to_OS_user_account "Mapping from Kerberos Principal") in the [Hadoop in Secure Mode](https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SecureMode.html "Secure Mode Hadoop") documentation for details about how the rule works.
+
+## Using Connection URLs
+
+New client side connection URL parameters are introduced for Kerberos authentication in Drill 1.10. You can use these parameters in multiple combinations to authenticate a client with Drill.
+
+### Client Credentials
+
+A client can provide its credentials in two ways:
+
+- With a ticket granting ticket (TGT) generated on client side. The TGT must be present on client node; Drill does not generate the TGT.
+
+- With a keytab file and the client principal provided in the user property of the connection URL.
+
+### Configuration Options
+The following table lists configuration options for connection URLs. See the Connection URL Examples section for sample URLs.
+
+| Connection Parameter | Description | Mandatory/Optional | Default Value |
+|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| auth | Authentication mechanism. The value is deduced if not specified. Kerberos if principal is provided. Plain if a user and password is provided. A Drill client can also explicitly specify a particular authentication mechanism to use using this parameter. For example, <auth=kerberos> for Kerberos along with service_name, service_host or principal and <auth=plain> for the Plain authentication with username and password. | Optional | The preference order is Kerberos and Plain. |
+| principal | Drillbit service principal. The format of the principal is primary/instance@realm. For Kerberos, the Drill service principal is derived if the value is not provided using this configuration. service_name (primary) and service_host (instance) are used to generate a valid principal. Since the ticket or keytab contains the realm information, the realm is optional. | Optional | |
+| keytab | For Kerberos, if the client chooses to authenticate using a keytab rather than a ticket, set the keytab parameter to the location of the keytab file. The client principal must be provided through the user parameter. A Kerberos ticket is used as the default credential (It is assumed to be present on client-side. The Drill client does not generate the required credentials.) | Optional | |
+| sasl_encrypt | When set to **true**, ensures that a client connects to a server with encryption capabilities. For example, Drill 1.11 drillbits, which support client-to-drillbit encryption. | Optional | false |
+| service_name | Primary name of the drillbit service principal. | Optional | drill |
+| service_host | Instance name of the drillbit service principal. | Optional | Since this value is usually the hostname of the node where a drillbit is running, the default value is the drillbit hostname is provided either through ZooKeeper or through a direct connection string. |
+| realm | Kerberos realm name for the drillbit service principal. The ticket or keytab contains the realm information. | Optional | |
+
+
+### Client Encryption
+A client can specify that it requires a server with encryption capabilities only by setting the `sasl_encrypt` connection parameter to **true**. If the cluster to which client is connecting has encryption disabled, the client will fail to connect to that server.
+
+See *Client Compatibility* in [Configuring User Security]({{site.baseurl}}/docs/configuring-user-security/) for information about client version and Drill version compatibility.
+
+### Connection URL Examples
+
+The following five examples show the JDBC connection URL that the embedded JDBC client uses for Kerberos authentication.
+
+- Example of a Simple Connection URL-a simple connection string
+ - Example 1: TGT for Client Credentials
+
+- Examples of Connection URLs Used with Previously Generated TGTs-examples to use with previously generated TGTs
+ - Example 2: Drillbit Provided by Direct Connection String and Configured with a Unique Service Principal
+ - Example 3: Drillbit Selected by ZooKeeper and Configured with a Unique Service Principal
+ - Example 4: Drillbit Selected by Zookeeper and Configured with a Common Service Principal
+ - Example 5: Keytab for Client Credentials
+
+#### Example of a Simple Connection URL
+
+##### Example 1: TGT for Client Credentials
+The simplest way to connect using Kerberos is to generate a TGT on the client side. Only specify the service principal in the JDBC connection string for the drillbit the user wants to connect to.
+
+
+ jdbc:drill:drillbit=10.10.10.10;principal=<principal for host 10.10.10.10>
+
+In this example, the Drill client uses the:
+
+- Default `service_name`, which is **`drill`**.
+- `service_host` from the drillbit name provided in the connection URL, which is **`10.10.10.10`**.
+
+The service principal format is `<primary>/<instance>@<realm from TGT>`. The service principal is **`principal for host 10.10.10.10`**.
+
+#### Examples of Connection URLs Used with Previously Generated TGTs
+If you do not provide a service principal in the connection string when using Kerberos authentication, then use the `service_name` or `service_host` parameters. Since these parameters are optional, their default values will be used internally (if not provided) to create a valid principal.
+
+Examples 2 through 4 show a valid connection string for Kerberos authentication if a client has previously generated a TGT. Realm information will be extracted from the TGT if it is not provided.
+
+{% include startnote.html %}For end-to-end authentication to function, it is assumed that the proper principal for the drillbit service is configured in the KDC.{% include endnote.html %}
+
+
+##### Example 2: Drillbit Provided by Direct Connection String and Configured with a Unique Service Principal
+
+This type of connection string is used when:
+
+- Each drillbit in the cluster is configured with its own service principal.
+- The instance component is the host address of the drillbit.
+
+ `jdbc:drill:drillbit=host1;auth=kerberos`
+
+In this example, the Drill client uses the:
+
+- Default `service_name`, which is **`drill`**.
+- `service_host`, which is the drillbit name provided in the connection URL (**`host1`**).
+
+The internally created service principal will be **`drill/host1@<realm from TGT>`**.
+
+##### Example 3: Drillbit Selected by ZooKeeper and Configured with Unique Service Principal
+
+This type of connection string is used when the drillbit is chosen by ZooKeeper instead of directly from the connection string.
+
+ jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill
+
+In this example, the Drill client uses the:
+
+- Provided `service_name`, which is **`myDrill`** as the primary name of the principal.
+- `service_host` as the address of the drillbit, which is chosen from the list of active drillbits that ZooKeeper provides (**`host01.aws.lab:5181`**).
+
+The internally created service principal will be **`myDrill/<host address from zk>@<realm from TGT>`**.
+
+##### Example 4: Drillbit Selected by Zookeeper and Configured with a Common Service Principal
+
+This type of connection string is used when all drillbits in a cluster use the same principal.
+
+ jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill;service_host=myDrillCluster
+
+In this example, the Drill client uses the:
+
+- Provided `service_name`, which is **`myDrill`**.
+- `service_host`, which is **`myDrillCluster`**.
+
+The internally created service principal, which will be **`myDrill/myDrillCluster@<realm from TGT>`**.
+
+##### Example 5: Keytab for Client Credentials
+
+If a client chooses to provide its credentials in a keytab instead of a TGT, it must also provide a principal in the user parameter. In this case, realm information will be extracted from the `/etc/krb5.conf` file on the node if it is not provided in the connection URL. All other parameters can be used as shown in the preceding examples (1-4). This connection string is for the case when all drillbits in a cluster use the same principal.
+
+ jdbc:drill:zk=host01.aws.lab:5181;auth=kerberos;service_name=myDrill;service_host=myDrillCluster;keytab=<path to keytab file>;user=<client principal>
+
+In this example, the Drill client:
+
+- Will authenticate itself with the:
+ - Keytab (**`path to keytab file`**) and
+ - Principal provided in the user parameter (**`client principal`**)
+- Uses the:
+ - Provided `service_name`, which is **`myDrill`**.
+ - `service_host`, which is **`myDrillCluster`**.
+
+The internally created service principal will be **`myDrill/myDrillCluster@<realm from krb5.conf>`**.
+
+#####
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/drill/blob/25aa6a18/_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
index 2f418d0..d3feb9a 100644
--- 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
@@ -1,9 +1,9 @@
---
title: "Configuring Web Console and REST API Security"
-date: 2016-02-08 21:57:12 UTC
+date: 2017-08-07 19:02:44 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,
+Drill 1.5 extends [Drill user security]({{site.baseurl}}/docs/configuring-user-security/) 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.
@@ -34,7 +34,7 @@ As cluster administrator, you can set the following SSL configuration parameters
You need to perform the following configuration tasks using Web Console and REST API security.
-* Configure [user authentication]({{site.baseurl}}/docs/configuring-user-authentication/)
+* Configure [user security]({{site.baseurl}}/docs/configuring-user-security/)
* Set up Web Console administrators
Optionally, you can set up Web Console administrator-user groups to facilitate management of multiple Web Console administrators.