Kudu Security ( 安全 )
译文链接 :
Kudu 包括安全功能,它可以让集群更安全以防止未授权的用户访问。本指南介绍了 Kudu 提供的安全功能,列出了必要的配置选项。 包含了 Kudu 中安全兼容性方面不足的列表。
Kudu 可以配置为在服务器之间和客户端和服务器之间实施安全认证。身份验证可防止不受信任的行为者访问 Kudu,并安全地识别连接的用户或服务以进行授权检查。Kudu 的认证旨在通过使用 Kerberos 与其他安全的 Hadoop 组件进行互操作。
可以在 Kudu servers 上使用 ,它可以被设置为 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 的未认证连接将被拒绝。
可信任的子网可以使用 进行配置,该标记可以设置为以逗号分隔的 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 凭据。
Kudu 认证旨在扩展到数千个节点,这需要避免与中央认证机构(如 Kerberos KDC)的不必要的协调。相反,Kudu 服务器和客户端将使用 Kerberos 与 Kudu 主机建立初始信任,然后使用备用凭据进行后续连接。特别是,master 将向服务器发出内部 X.509 证书,向客户端发出临时认证令牌。
Encryption(加密)
Kudu 允许使用 TLS 对服务器之间以及客户端和服务器之间的所有通信进行加密。
警告 :
Kudu 将自动关闭本地环回连接上的加密,因为来自这些连接的流量不会从外部暴露出来。这允许像 Spark 和 Impala 这样的位置感知计算框架避免加密开销,同时确保数据的机密性。
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 配置的更多信息,请参阅 。
Web UI Redaction
为了防止在 Web UI 中暴露敏感数据,所有行数据都被修改。表元数据,如表名,列名和分区信息不会被修改。可以通过在 Kudu server 上设置 --webserver-enabled=false
标记
来完全禁用 Web UI 。
警告 :
禁用 Web UI 也将禁用 REST endpoints,例如 。监控系统依靠这些 endpoints 来收集 metrics 指标数据。
应在所有服务器(master 和 tablet server)上设置以下配置参数,以确保 Kudu 集群安全 :
有关这些标记的更多信息,请参见配置标记指南。
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 集成)