【大数据】Apache Knox 概述

Apache Knox 概述

1.概述
- [1.1 Kerberos 封装](#1.1 Kerberos 封装)
- [1.2 简化客户端证书的管理](#1.2 简化客户端证书的管理)
- [1.3 Apache Ranger 集成](#1.3 Apache Ranger 集成)
- [1.4 Hadoop URLs VS Knox URLs](#1.4 Hadoop URLs VS Knox URLs)
[2.自定义 Apache Knox](#2.自定义 Apache Knox)
- [2.1 Topology](#2.1 Topology)
- [2.2 Provider](#2.2 Provider)
- [2.3 Services](#2.3 Services)
- [2.4 Personalized services](#2.4 Personalized services)
3.Tips
- [3.1 Setting up SSL](#3.1 Setting up SSL)
- [3.2 常见问题](#3.2 常见问题)
- - [3.2.1 Bulky answer](#3.2.1 Bulky answer)
  - [3.2.2 Apache Solr](#3.2.2 Apache Solr)
  - [3.2.3 Apache Hive connections often disconnected via Apache Knox](#3.2.3 Apache Hive connections often disconnected via Apache Knox)
- [3.3 How to check my deployment?](#3.3 How to check my deployment?)
- - [3.3.1 Certificate validation](#3.3.1 Certificate validation)
  - [3.3.2 Topology validation](#3.3.2 Topology validation)
  - [3.3.3 Authentication and authorization via LDAP](#3.3.3 Authentication and authorization via LDAP)
  - [3.3.4 Topology / LDAP binding](#3.3.4 Topology / LDAP binding)
  - [3.3.5 Gateway test](#3.3.5 Gateway test)
  - [3.3.6 Direct reading（直接查看）](#3.3.6 Direct reading（直接查看）)
- [3.4 Apache Knox Ranger 插件调试](#3.4 Apache Knox Ranger 插件调试)
- [3.5 通过 Apache Knox 缩短响应时间](#3.5 通过 Apache Knox 缩短响应时间)
4.结论

Apache Knox 是 Hadoop 集群的安全入口点，那么它可以作为我们自己的 REST 应用程序的入口点吗?

1.概述

Apache Knox 是一个应用程序网关，用于以安全的方式与一个或多个 Hadoop 集群的 REST API 和用户界面进行交互。

支持 Hadoop 集群中最常用的服务（WebHDFS、Apache Oozie、Apache Hive/JDBC 等）和用户界面（Apache Ambari、Apache Ranger 等）;
与企业认证系统（Microsoft Active Directory、LDAP、Kerberos 等）的强集成;

⭕ 注意：它不是 Hadoop 集群中替代 Kerberos 的方案，也不要把它当成数据导入导出的通道。

我们可以将网关的好处定义为四个不同的类别：

安全增强：通过访问暴露的 REST 和 HTTP 服务进行访问集群，而不暴露集群内部信息，对 Web 应用程序的漏洞进行过滤，或使用 SSL 协议来增强安全性。
控制中心：通过使用单一网关进行集中控制，这有助于审计和授权（使用 Apache Ranger）。
简化访问：通过使用 Kerberos 封装服务或使用单个 SSL 证书，简化了访问。
企业集成：通过领先的市场解决方案（Microsoft Active Directory、LDAP、Kerberos 等）或使用自定义解决方案（Apache Shiro 等）进行企业集成。

1.1 Kerberos 封装

封装主要用于与 Kerberos 协议不兼容的产品。用户通过使用 HTTP 基本认证协议提供他的用户名和密码。

1.2 简化客户端证书的管理

用户只依赖 Apache Knox 证书，因此我们将不同服务的证书集中在 Apache Knox 服务器上，而不是所有客户机上。这在撤销和创建新证书时非常有用。

1.3 Apache Ranger 集成

Apache Knox 包括一个 Apache Ranger 代理，用于检查希望访问集群资源的用户的权限。

1.4 Hadoop URLs VS Knox URLs

使用 Apache Knox URL 掩盖了集群架构，并允许用户只记住一个 URL。

2.自定义 Apache Knox

要配置 Apache Knox 网关，我们需要修改 topology 类型文件。这些文件由三个组件组成：Providers、HA Provider、Services。

2.1 Topology

topology 文件在 /conf/topologies 目录下。拓扑文件的名称将指定 Apache Knox URL，如果文件名为 sandbox.xml，则 URL 为 https://knox-host:8443/gateway/sandbox/webhdfs。

下面是一个拓扑文件的示例：

xml 复制代码

<topology>
  <gateway>
    <!-- Authentication provider -->
    <provider>
      <role>authentication</role>
      <name>ShiroProvider</name>
      <enabled>true</enabled>
      [...]
    </provider>

    <!-- Identity assertion provider -->
    <provider>
      <role>identity-assertion</role>
      <name>HadoopGroupProvider</name>
      <enabled>true</enabled>
      [...]
    </provider>

    <!-- Authorization provider -->
    <provider>
      <role>authorization</role>
      <name>XASecurePDPKnox</name>
      <enabled>true</enabled>
      [...]
    </provider>

    <!-- HA provider -->
    <provider>
      <role>ha</role>
      <name>HaProvider</name>
      <enabled>true</enabled>
      [...]
    </provider>
  </gateway>

  <!-- Services -->
  <service>
    <role>WEBHDFS</role>
    <url>http://webhdfs-host:50070/webhdfs</url>
  </service>
</topology>

注意：如果你使用 Apache Ambari，拓扑 admin，knoxsso， manager 和 default 必须通过 Web 界面修改，否则在重启服务的情况下，文件将被覆盖。

2.2 Provider

Provider 向网关添加了新的特性（authentication，federation，authorization，identity-assertion 等），这些特性可以被不同的服务使用，通常是一个或多个添加到一个或多个拓扑中的过滤器。

默认的身份验证提供者是 Apache Shiro（ShiroProvider）。它用于向 Active Directory 或 LDAP 进行身份验证。对于通过 Kerberos 进行身份验证，我们将使用 HadoopAuth。

主要有 5 个主要的 identity-assertion Providers：

Default：这是方便映射用户名称和用户组的默认提供程序。它负责建立传递给集群其余部分的身份。
Concat：它是允许通过连接前缀或后缀来组合新名称或用户组的 Provider。
SwitchCase：该 Provider 解决生态系统需要用户名称或组的特定情况。
Regex：它允许使用正则表达式翻译传入的标识。
HadoopGroupProvider：该 Provider 程序可在组内查找用户，大大方便了权限的定义（通过 Apache Ranger）。

2.3 Services

服务位于 /data/services 目录下。下面是组成 HIVE 服务的文件示例：

bash 复制代码

-bash-4.1$ ls -lahR hive/
hive/:
total 12K
drwxr-xr-x  3 knox knox 4.0K Nov 16  2017 .
drwxr-xr-x 84 knox knox 4.0K Nov 16 17:07 ..
drwxr-xr-x  2 knox knox 4.0K Nov 16  2017 0.13.0

hive/0.13.0:
total 16K
drwxr-xr-x 2 knox knox 4.0K Nov 16  2017 .
drwxr-xr-x 3 knox knox 4.0K Nov 16  2017 ..
-rw-r--r-- 1 knox knox  949 May 31  2017 rewrite.xml
-rw-r--r-- 1 knox knox 1.1K May 31  2017 service.xml

在 Hive 目录中，我们找到目录 0.13.0（对应于服务的版本）。在这个文件夹中，我们找到了 rewrite.xml 和 service.xml 文件。

2.4 Personalized services

让我们假设在 http://rest-application:8080/api/ 上有一个 REST 应用程序。只需创建一个新服务并将其添加到 topology 文件中。

xml 复制代码

<topology>
  [...]
  <!-- Services -->
  <service>
    <role>{{ service_name | upper }}</role>
    <url>http://rest-application:8080</url>
  </service>
</topology>

service.xml 文件中，{``{knox_service_version}} 的值必须等于父文件夹的名称。

xml 复制代码

<service role="{{ service_name | upper }}" name="{{ service_name | lower }}" version="{{ knox_service_version }}">
  <policies>
    <policy role="webappsec"/>
    <policy role="authentication"/>
    <policy role="federation"/>
    <policy role="identity-assertion"/>
    <policy role="authorization"/>
    <policy role="rewrite"/>
  </policies>
  <routes>
    <route path="/{{ service_name | lower }}">
      <rewrite apply="{{ service_name | upper }}/{{ service_name | lower }}/inbound/root" to="request.url"/>
    </route>
    <route path="/{{ service_name | lower }}/**">
      <rewrite apply="{{ service_name | upper }}/{{ service_name | lower }}/inbound/path" to="request.url"/>
    </route>
    <route path="/{{ service_name | lower }}/?**">
      <rewrite apply="{{ service_name | upper }}/{{ service_name | lower }}/inbound/args" to="request.url"/>
    </route>
    <route path="/{{ service_name | lower }}/**?**">
      <rewrite apply="{{ service_name | upper }}/{{ service_name | lower }}/inbound/pathargs" to="request.url"/>
    </route>
  </routes>
</service>

在 rewrite.xml 文件中，我们重写了 URL（在这里添加 /api）：

xml 复制代码

<rules>
  <rule dir="IN" name="{{ service_name | upper }}/{{ service_name | lower }}/inbound/root" pattern="*://*:*/**/{{ service_name | lower }}">
    <rewrite template="{$serviceUrl[{{ service_name | upper }}]}/api/{{ service_name | lower }}"/>
  </rule>
  <rule dir="IN" name="{{ service_name | upper }}/{{ service_name | lower }}/inbound/path" pattern="*://*:*/**/{{ service_name | lower }}/{path=**}">
    <rewrite template="{$serviceUrl[{{ service_name | upper }}]}/api/{{ service_name | lower }}/{path=**}"/>
  </rule>
  <rule dir="IN" name="{{ service_name | upper }}/{{ service_name | lower }}/inbound/args" pattern="*://*:*/**/{{ service_name | lower }}/?{**}">
    <rewrite template="{$serviceUrl[{{ service_name | upper }}]}/api/{{ service_name | lower }}/?{**}"/>
  </rule>
  <rule dir="IN" name="{{ service_name | upper }}/{{ service_name | lower }}/inbound/pathargs" pattern="*://*:*/**/{{ service_name | lower }}/{path=**}?{**}">
    <rewrite template="{$serviceUrl[{{ service_name | upper }}]}/api/{{ service_name | lower }}/{path=**}?{**}"/>
  </rule>
</rules>

3.Tips

3.1 Setting up SSL

bash 复制代码

# Requirements
$ export KEYALIAS=gateway-identity
$ export PRIVATEKEYALIAS=gateway-identity-passphrase
$ export KEYPASS=4eTTb03v
$ export P12PASS=$KEYPASS
$ export JKSPASS=$KEYPASS

# Save old Keystore
$ mv /usr/hdp/current/knox-server/data/security/keystores /usr/hdp/current/knox-server/data
$ mkdir /usr/hdp/current/knox-server/data/security/keystores
$ chown knox:knox /usr/hdp/current/knox-server/data/security/keystores
$ chmod 755 /usr/hdp/current/knox-server/data/security/keystores

# Generate Knox Master Key
$ /usr/hdp/current/knox-server/bin/knoxcli.sh create-master --force
> Enter master secret: $JKSPASS
> Enter master secret again: $JKSPASS

# Generate the Keystore
$ openssl pkcs12 -export -in /etc/security/.ssl/`hostname -f`.cer -inkey /etc/security/.ssl/`hostname -f`.key -passin env:KEYPASS \
    -out /usr/hdp/current/knox-server/data/security/keystores/gateway.p12 -password env:P12PASS -name $KEYALIAS
$ keytool -importkeystore -deststorepass $JKSPASS -destkeypass $KEYPASS \
    -destkeystore /usr/hdp/current/knox-server/data/security/keystores/gateway.jks \
    -srckeystore /usr/hdp/current/knox-server/data/security/keystores/gateway.p12 \
    -srcstoretype PKCS12 -srcstorepass $P12PASS -alias $KEYALIAS

# Import the parents certificates
$ keytool -import -file /etc/security/.ssl/enterprise.cer -alias enterprise \
    -keystore /usr/hdp/current/knox-server/data/security/keystores/gateway.jks -storepass $JKSPASS

# Save the private key in the Keystore
$ /usr/hdp/current/knox-server/bin/knoxcli.sh create-alias $PRIVATEKEYALIAS --value $JKSPASS

在密钥存储中备份私钥时，$PRIVATEKEYALIAS 值必须是 gateway-identity-passphrase。

密码必须与生成主密钥（Apache Knox 主密钥）时使用的密码一致。这就是我们在任何地方都使用相同密码（$JKSPASS）的原因。

3.2 常见问题

首先，在重新启动有问题的查询之前，干净利落地重启 Apache Knox 就能解决问题并清除日志。

bash 复制代码

# Stop Apache Knox via Ambari

# Delete topologies and services deployments
$ rm -rf /usr/hdp/current/knox-server/data/deployments/*.topo.*

# Delete JCEKS keystores
$ rm -rf /usr/hdp/current/knox-server/data/security/keystores/*.jceks

# Purge logs
$ rm -rf /var/log/knox/*

# Kill zombie process
$ ps -ef | grep `cat /var/run/knox/gateway.pid`
$ kill -9 `cat /var/run/knox/gateway.pid`

# Start Apache Knox via Ambari

3.2.1 Bulky answer

如果查询很快失败并返回 500 错误，则可能是请求响应过大（默认为 8 K b 8Kb 8Kb）。您会在 gateway-audit.log 文件中发现类似的内容：

bash 复制代码

dispatch|uri|http://<hostname>:10000/cliservice?doAs=<user>|success|Response status: 500

只需修改拓扑结构，在相关服务中添加参数即可：

xml 复制代码

<param name="replayBufferSize" value="32" />

3.2.2 Apache Solr

如果您在 Apache Ranger 中启用了 Apache Solr 审计（xasecure.audit.destination.solr=true），那么在 Apache Solr 文件系统没有剩余空间的情况下，Apache Knox 有可能无法继续工作。

3.2.3 Apache Hive connections often disconnected via Apache Knox

要纠正这一问题，必须添加 gateway-site 配置文件（这些值必须根据环境进行修改）。

powershell 复制代码

gateway.httpclient.connectionTimeout=600000 (10 min)
gateway.httpclient.socketTimeout=600000 (10 min)
gateway.metrics.enabled=false
gateway.jmx.metrics.reporting.enabled=false
gateway.httpclient.maxConnections=128

3.3 How to check my deployment?

Apache Knox 提供了一个客户端，用于检查实例部署过程中的若干事项。

3.3.1 Certificate validation

验证 Apache Knox 实例使用的证书，以确认您拥有贵公司的证书。

bash 复制代码

$ openssl s_client -showcerts -connect {{ knoxhostname }}:8443

3.3.2 Topology validation

验证群集描述（群集用户名等于拓扑结构）是否遵循正确的格式规则。

bash 复制代码

$ /usr/hdp/current/knox-server/bin/knoxcli.sh validate-topology [--cluster clustername] | [-- path "path/to/file"]

3.3.3 Authentication and authorization via LDAP

该命令测试集群配置（topology）通过 ShiroProvider 设置对用户进行身份验证的能力。参数 --g 列出用户所属的组。--u 和 --p 参数是可选参数，如果没有提供，终端会要求你提供一个。

bash 复制代码

$ /usr/hdp/current/knox-server/bin/knoxcli.sh user-auth-test [--cluster clustername] [--u username] [--p password] [--g]

3.3.4 Topology / LDAP binding

该命令测试群集配置（topology）对仅提供 ShiroProvider 设置的用户进行身份验证的能力。

bash 复制代码

$ /usr/hdp/current/knox-server/bin/knoxcli.sh system-user-auth-test [--cluster c] [--d]

3.3.5 Gateway test

使用 HTTP Basic 访问认证方式：

bash 复制代码

$ export $KNOX_URL=knox.local
$ curl -vik -u admin:admin-password 'https://$KNOX_URL:8443/gateway/default/webhdfs/v1/?op=LISTSTATUS'

使用 Kerberos 身份验证方法：

bash 复制代码

$ export $KNOX_URL=knox.local
$ export $KNOX_USER=knoxuser
$ kdestroy
$ kinit $KNOX_USER

$ curl -i -k --negotiate -X GET -u 'https://$KNOX_URL:8443/gateway/kdefault/webhdfs/v1/?op=LISTSTATUS'

在本例中，我们使用 kdefault 拓扑，它使用 HadoopAuth 身份验证提供程序。

3.3.6 Direct reading（直接查看）

/usr/hdp/current/knox-server/data/deployments/ 目录包含不同拓扑对应的不同文件夹。每次更新拓扑时，都会根据 {``{ topologyname }}.topo.{``{ timestamp }} 创建一个新目录。

在 %2F/WEB-INF/ 子目录中可以找到 rewrite.xml 文件，它是拓扑文件和服务文件的连接。在该文件中，您可以检查重写规则是否已被考虑在内。

bash 复制代码

$ cd /usr/hdp/current/knox-server/data/deployments/
$ ll
total 0
drwxr-xr-x. 4 knox knox 31 22 janv. 16:04 admin.topo.168760a5c28
drwxr-xr-x. 4 knox knox 31 24 janv. 18:53 admin.topo.16880fef4b8
drwxr-xr-x. 4 knox knox 31 22 janv. 16:04 default.topo.168760a5c28
drwxr-xr-x. 5 knox knox 49 22 janv. 16:04 knoxsso.topo.168760a5c28
drwxr-xr-x. 5 knox knox 49 22 janv. 16:04 manager.topo.15f6b1f2888
$ cd default.topo.168760a5c28/%2F/WEB-INF/
$ ll
total 104
-rw-r--r--. 1 knox knox 70632 22 janv. 16:04 gateway.xml
-rw-r--r--. 1 knox knox  1112 22 janv. 16:04 ha.xml
-rw-r--r--. 1 knox knox 19384 22 janv. 16:04 rewrite.xml
-rw-r--r--. 1 knox knox   586 22 janv. 16:04 shiro.ini
-rw-r--r--. 1 knox knox  1700 22 janv. 16:04 web.xml

3.4 Apache Knox Ranger 插件调试

通过该配置，可以查看通过 Apache Knox 插件传输到 Apache Ranger 的内容。你必须修改 gateway-log4j.properties 文件，如下所示。重启 Apache Knox 实例并检查 ranger.knoxagent.log 文件中的长日志。

java 复制代码

ranger.knoxagent.logger=DEBUG,console,KNOXAGENT
ranger.knoxagent.log.file=ranger.knoxagent.log
log4j.logger.org.apache.ranger=${ranger.knoxagent.logger}
log4j.additivity.org.apache.ranger=false
log4j.appender.KNOXAGENT=org.apache.log4j.DailyRollingFileAppender
log4j.appender.KNOXAGENT.File=${app.log.dir}/${ranger.knoxagent.log.file}
log4j.appender.KNOXAGENT.layout=org.apache.log4j.PatternLayout
log4j.appender.KNOXAGENT.layout.ConversionPattern=%d{ISO8601} %p %c{2}: %m%n %L
log4j.appender.KNOXAGENT.DatePattern=.yyyy-MM-dd

3.5 通过 Apache Knox 缩短响应时间

如果您通过 Apache Knox 获得了更长的响应时间，则可以在 gateway.site 配置文件中更改这些不同的设置。

java 复制代码

gateway.metrics.enabled=false 
gateway.jmx.metrics.reporting.enabled=false 
gateway.graphite.metrics.reporting.enabled=false

4.结论

总之，Apache Knox 是一个强大的工具，具有 Apache Ranger 审核功能，可以过滤和审核对您环境的所有访问。但它也允许您通过配置的方式作为您的各种个性化服务面前的经典网关。例如，您可以在没有 Kerberos 身份验证的 REST API 前面添加它。