Kudu Security ( 安全 )

原文链接 : http://kudu.apache.org/docs/security.html

译文链接 : http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813635

贡献者 : 小瑶，ApacheCN，Apache中文网

Kudu 包括安全功能，它可以让集群更安全以防止未授权的用户访问。本指南介绍了 Kudu 提供的安全功能，列出了必要的配置选项。 Known Limitations 包含了 Kudu 中安全兼容性方面不足的列表。

Authentication（认证）

Kudu 可以配置为在服务器之间和客户端和服务器之间实施安全认证。身份验证可防止不受信任的行为者访问 Kudu，并安全地识别连接的用户或服务以进行授权检查。Kudu 的认证旨在通过使用 Kerberos 与其他安全的 Hadoop 组件进行互操作。

可以在 Kudu servers 上使用 **--rpc-authentication** 标记来配置认证，它可以被设置为 required，optional，或 disabled。默认情况下，该标记设置为 optional。当设置为 **required** 时，Kudu 将拒绝客户端和缺少身份验证凭证的服务器的连接。当设置为 **optional** 时，Kudu 将尝试使用强身份验证。当配置为 **disabled** 或针对“optional” 的强认证失败时，默认情况下，Kudu 将只允许来自受信任子网的未经身份验证的连接，它们是非私有网络（127.0.0.0.08,10.0.0.08,172.16.0.0/12,192.168.0.0/16,169.254.0.0 / 16）和本地网络接口的本地子网。来自可公开路由的 IP 的未认证连接将被拒绝。

可信任的子网可以使用 **--trusted_subnets** 标记进行配置，该标记可以设置为以逗号分隔的 CIDR 表示法的 IP 块。将其设置为 “0.0.0.0/0” 以允许来自所有远程 IP 地址的未经身份验证的连接。但是，如果网络访问不受防火墙的限制，恶意用户可能会获得未经授权的访问。如果认证被配置为 required，这可以减少这样的行为。

警告 :

当 —rpc-authentication 标记设置为 optional 时，该集群不会阻止来自未授权用户的访问请求。要保护集群，请使用 —rpc-authentication=required。

Internal PKI

Kudu 使用内部 PKI 系统向集群中的服务器发出 X.509 证书。具有获得证书的对等体之间的连接将使用 TLS 进行身份验证，这不需要联系 Kerberos KDC。这些证书 only（仅仅）用于 Kudu 服务器之间以及 Kudu 客户端和服务器之间的内部通信。这些证书永远不会在面向公众的协议中呈现。

通过使用内部颁发的证书，Kudu 提供强大的身份验证功能，可扩展到巨大的群集，并允许使用 TLS 加密，而无需在每个节点上手动部署证书。

Authentication Tokens（认证令牌）

在对安全的群集进行身份验证后，Kudu 客户端将自动向 Kudu主机请求一个身份验证令牌。认证令牌封装认证用户的身份，并携带 master 的 RSA 签名，以便验证其真实性。

该令牌将用于验证后续连接。默认情况下，身份验证令牌仅在七天内有效，因此即使令牌遭到入侵，也不能无限期地使用令牌。在大多数情况下，身份验证令牌应对用户完全透明。通过使用身份验证令牌，Kudu 可以利用强大的身份验证功能，而无需支付与每个连接的中央机构进行通信的可扩展性成本。

当与分布式计算框架（如 Spark）一起使用时，身份验证令牌可以简化配置并提高安全性。例如，Kudu Spark connector（连接器）将在规划阶段自动检索认证令牌，并将令牌分发到任务。这样，Spark 可以对受保护的 Kudu 集群工作，只有 planner node 具有 Kerberos 凭据。

Scalability（可扩展性）

Kudu 认证旨在扩展到数千个节点，这需要避免与中央认证机构（如 Kerberos KDC）的不必要的协调。相反，Kudu 服务器和客户端将使用 Kerberos 与 Kudu 主机建立初始信任，然后使用备用凭据进行后续连接。特别是，master 将向服务器发出内部 X.509 证书，向客户端发出临时认证令牌。

Encryption（加密）

Kudu 允许使用 TLS 对服务器之间以及客户端和服务器之间的所有通信进行加密。

可以在 Kudu servers 上使用 **--rpc-encryption** 标记来配置加密，它可以被设置为 required，optional或 disabled。默认情况下，该标志设置为 optional。当配置为 **required** 时，Kudu 将拒绝未加密的连接。当配置为 **optional** 时，Kudu 将尝试使用加密。与认证相同，当配置为 disabled或针对 **optional** 的情况下加密失败，Kudu 将只允许来自受信任的子网的未加密的连接，并拒绝公开可路由的 IP 的任何未加密的连接。要保护群集，请使用 --rpc-encryption=required。

警告 :

Kudu 将自动关闭本地环回连接上的加密，因为来自这些连接的流量不会从外部暴露出来。这允许像 Spark 和 Impala 这样的位置感知计算框架避免加密开销，同时确保数据的机密性。

Coarse-Grained Authorization（粗粒度授权）

Kudu 支持基于认证的客户端 Kerberos 主体（即用户或服务）对客户端请求进行粗粒度授权。可以配置的两个级别的访问是 :

  • Superuser（超级用户）- 被授权为超级用户的 principals 能够执行某些管理功能，例如使用 kudu命令行工具诊断或修复群集问题。

  • User（用户）- 授权为用户 principals 都能够在 Kudu 集群中访问和修改所有数据。这包括 create（创建），drop（删除）和 alter（更改）表以及 read（读取），insert（插入），update（更新）和 delete（删除）数据的功能。

    警告 :

    在内部，Kudu 针对守护进程本身具有第三的访问级别。这样可以确保用户无法连接到集群，并可以作为 tablet server。

    使用白名单样式的访问控制列表（ACL）授予访问级别，对于两个级别中的每一级都可以访问。每个访问控制列表指定以逗号分隔的用户列表，或者可以设置 *****为表示所有经过身份验证的用户能够以指定级别获得访问权限。有关示例，请参阅下面的 配置安全的 Kudu 群集。

    警告 :

    用户 ACL 的默认值是 *允许所有用户访问集群。但是，如果启用了身份验证，这仍然限制对只能通过 Kerberos 成功验证的用户的访问。与 Kudu server 在同一网络上的未认证用户将无法访问集群。

Web UI Encryption（加密）

可以通过为每个服务器提供 TLS 证书，将 Kudu Web UI 配置为使用安全的 HTTPS 加密。有关 Web UI HTTPS 配置的更多信息，请参阅 配置安全的 Kudu 集群。

Web UI Redaction

为了防止在 Web UI 中暴露敏感数据，所有行数据都被修改。表元数据，如表名，列名和分区信息不会被修改。可以通过在 Kudu server 上设置 --webserver-enabled=false 标记来完全禁用 Web UI 。

警告 :

禁用 Web UI 也将禁用 REST endpoints，例如 /metrics。监控系统依靠这些 endpoints 来收集 metrics 指标数据。

Log Security（日志安全）

为了防止敏感数据包含在 Kudu 服务器日志中，默认情况下会修改所有行数据。该功能可以配置 **--redact** 标记来关闭。

Configuring a Secure Kudu Cluster（配置安全的 Kudu 集群）

应在所有服务器（master 和 tablet server）上设置以下配置参数，以确保 Kudu 集群安全 : 

  1. # Connection Security
  2. #--------------------
  3. --rpc-authentication=required
  4. --rpc-encryption=required
  5. --keytab-file=<path-to-kerberos-keytab>
  7. # Web UI Security
  8. #--------------------
  9. --webserver-certificate-file=<path-to-cert-pem>
  10. --webserver-private-key-file=<path-to-key-pem>
  11. # optional
  12. --webserver-private-key-password-cmd=<password-cmd>
  14. # If you prefer to disable the web UI entirely:
  15. --webserver-enabled=false
  17. # Coarse-grained authorization
  18. #--------------------------------
  20. # This example ACL setup allows the 'impala' user as well as the
  21. # 'nightly_etl_service_account' principal access to all data in the
  22. # Kudu cluster. The 'hadoopadmin' user is allowed to use administrative
  23. # tooling. Note that, by granting access to 'impala', other users
  24. # may access data in Kudu via the Impala service subject to its own
  25. # authorization rules.
  26. --user-acl=impala,nightly_etl_service_account
  27. --superuser-acl=hadoopadmin

有关这些标记的更多信息，请参见配置标记指南。

Known Limitations（已知限制）

Kudu 有一些已知的安全限制 :

Long-lived Tokens（常用的令牌）

Java Kudu 客户端在初始 tokens（令牌）到期后不会自动请求新的 authn tokens（令牌），因此不支持长期存在的安全集群中的 Java 客户端。然而，针对 C 的 Kudu 客户端会自动请求新的 authn tokens 令牌，因此支持安全集群中长久的 C 客户端（即超出 authn token 令牌生存期）。

Custom Kerberos Principal（自定义 kerberos 主体）

Kudu 不支持为 Kudu 进程设置自定义服务 principal。principal 必须是 ‘kudu‘。

External PKI

Kudu 不支持外部颁发的内部线路加密证书（服务器到服务器和客户端到服务器）。细粒度授权 Kudu 无法根据操作类型或目标（表，列等）限制访问。ACL 目前不支持基于组中成员资格的授权。

On-disk Encryption（磁盘加密）

Kudu 没有内置的磁盘加密。然而，Kudu 可以使用全盘加密工具，如 dm-crypt。

Web UI Authentication（认证）

Kudu Web UI 缺少基于 Kerberos 的身份验证（SPNEGO），因此不能基于 Kerberos 的 principals 进行访问限制。

Flume Integration（Flume 集成）

需要验证或加密的安全 Kudu 集群不支持 Flume 集成。