第 15 章 保护对 Kafka 的访问
通过管理客户端对 Kafka 代理的访问来保护 Kafka 集群。Kafka 代理和客户端之间的安全连接可以包括以下内容:
- 数据交换加密
- 证明身份的身份验证
- 允许或拒绝用户执行操作的授权
在 Apache Kafka 的 Streams 中,保护连接涉及配置监听程序和用户帐户:
- 侦听器配置
使用
Kafka
资源为到 Kafka 代理的客户端连接配置监听程序。侦听器定义客户端如何进行身份验证,如使用 mTLS、SCRAM-SHA-512、OAuth 2.0 或自定义身份验证方法。要提高安全性,请配置 TLS 加密以保护 Kafka 代理和客户端之间的通信。您可以通过在 Kafka 代理配置中指定支持的 TLS 版本和密码套件来进一步保护基于 TLS 的通信。对于添加的保护层,请使用
Kafka
资源为 Kafka 集群指定授权方法,如简单、OAuth 2.0、OPA 或自定义授权。- 用户帐户
使用 Apache Kafka Streams 中的
KafkaUser
资源设置用户帐户和凭证。用户代表您的客户端,并确定它们应该如何使用 Kafka 集群验证和授权。用户配置中指定的身份验证和授权机制必须与 Kafka 配置匹配。另外,定义访问控制列表(ACL)来控制用户对特定主题的访问以及更精细的授权。要进一步提高安全性,请指定用户配额,以根据字节率或 CPU 使用率限制客户端对 Kafka 代理的访问。如果要限制其使用的 TLS 版本和密码套件,您还可以将制作者或消费者配置添加到客户端。客户端上的配置必须使用在代理上启用的协议和密码套件。
如果您使用 OAuth 2.0 管理客户端访问,则用户身份验证和授权凭据将通过授权服务器进行管理。
Apache Kafka operator 的流自动化配置过程并创建身份验证所需的证书。Cluster Operator 会自动为集群中的数据加密和身份验证设置 TLS 证书。
15.1. Kafka 的安全选项
使用 Kafka
资源来配置用于 Kafka 身份验证和授权的机制。
15.1.1. 侦听器身份验证
在创建监听程序时为 Kafka 代理配置客户端身份验证。使用 Kafka
资源中的 Kafka.spec.kafka.listeners.authentication
属性指定监听程序验证类型。
对于 OpenShift 集群中的客户端,您可以创建 plain
(没有加密)或 tls
内部监听程序。内部监听程序
类型使用无头服务,以及提供给代理 pod 的 DNS 名称。作为无头服务的替代选择,您还可以创建内部监听程序的 cluster-ip
类型,以使用每个代理的 ClusterIP
服务公开 Kafka。对于 OpenShift 集群外的客户端,您可以创建 外部监听程序 并指定连接机制,可以是 nodeport
、loadbalancer
、ingress
(仅限 Kubernetes) 或路由
(仅限 OpenShift)。
有关连接外部客户端的配置选项的详情请参考 第 14 章 设置 Kafka 集群的客户端访问权限。
支持的身份验证选项:
- mTLS 身份验证(只在启用了 TLS 的监听程序中)
- SCRAM-SHA-512 身份验证
- 基于 OAuth 2.0 令牌的身份验证
- 自定义身份验证
- TLS 版本和密码套件
您选择的身份验证选项取决于您如何验证客户端对 Kafka 代理的访问。
在使用自定义身份验证前,尝试了解标准身份验证选项。自定义身份验证允许任何类型的 Kafka 支持的身份验证。它可以提供更大的灵活性,但也增加了复杂性。
图 15.1. Kafka 侦听器身份验证选项
listener authentication
属性用于指定特定于该侦听器的身份验证机制。
如果没有指定 身份验证
属性,则监听器不会验证通过该监听程序连接的客户端。侦听器将在没有身份验证的情况下接受所有连接。
在使用 User Operator 管理 KafkaUsers
时,必须配置身份验证。
以下示例显示了:
-
为 SCRAM-SHA-512 身份验证配置
纯文本
-
带有 mTLS 验证的
tls
侦听器 -
带有 mTLS 验证的
外部监听程序
每个监听程序都配置在 Kafka 集群中具有唯一的名称和端口。
当为客户端配置监听程序对代理的访问时,您可以使用端口 9092 或更高版本(9093、9094 等),但有一些例外。侦听程序无法配置为使用为 interbroker 通信(9090 和 9091)、Prometheus 指标(9404)和 JMX (Java 管理扩展)监控(9999)保留的端口。
侦听器身份验证配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... listeners: - name: plain port: 9092 type: internal tls: true authentication: type: scram-sha-512 - name: tls port: 9093 type: internal tls: true authentication: type: tls - name: external3 port: 9094 type: loadbalancer tls: true authentication: type: tls # ...
15.1.1.1. mTLS 身份验证
mTLS 身份验证总是用于 Kafka 代理和 ZooKeeper pod 之间的通信。
Apache Kafka 的流可将 Kafka 配置为使用 TLS (传输层安全)来提供 Kafka 代理和客户端之间的加密通信,而无需 mutual 身份验证。对于 mutual,或双向验证,服务器和客户端都存在证书。当您配置 mTLS 身份验证时,代理会验证客户端(客户端身份验证),客户端会验证代理(服务器身份验证)。
Kafka
资源中的 mTLS 侦听器配置需要以下内容:
-
tls: true
指定 TLS 加密和服务器身份验证 -
authentication.type: tls
来指定客户端身份验证
当 Cluster Operator 创建 Kafka 集群时,它会创建一个名为 < cluster_name>-cluster-ca-cert
的新 secret。secret 包含 CA 证书。CA 证书采用 PEM 和 PKCS #12 格式。要验证 Kafka 集群,请将 CA 证书添加到客户端配置中的信任存储中。若要验证客户端,请在客户端配置中添加用户证书和密钥到密钥存储。有关为 mTLS 配置客户端的详情请参考 第 15.2.2 节 “用户身份验证”。
TLS 身份验证更为常见的单向,另一方验证另一方的身份。例如,当在 Web 浏览器和 Web 服务器之间使用 HTTPS 时,浏览器获取 Web 服务器身份的证明。
15.1.1.2. SCRAM-SHA-512 身份验证
SCRAM (Salted Challenge Response Authentication Mechanism)是一个身份验证协议,可以使用密码建立 mutual 身份验证。Apache Kafka 的流可将 Kafka 配置为使用 SASL (Simple Authentication and Security Layer) SCRAM-SHA-512,以便在未加密的和加密的客户端连接上提供身份验证。
当 SCRAM-SHA-512 身份验证与 TLS 连接一起使用时,TLS 协议会提供加密,但不用于身份验证。
以下 SCRAM 属性使得在未加密的连接中也安全地使用 SCRAM-SHA-512 :
- 密码不会通过通信通道以明文形式发送。取而代之,客户端和服务器都是由另一个挑战的挑战,以提供对其了解验证用户的密码的证明。
- 服务器和客户端各自为每个身份验证交换生成一个新的挑战。这意味着,交换具有弹性地应对重播攻击。
当使用 scram-sha-512
配置 KafkaUser.spec.authentication.type
时,User Operator 将生成一个由大写和小写 ASCII 字母和数字组成的随机 12 个字符密码。
15.1.1.3. 网络策略
默认情况下,Apache Kafka 的 Streams 会自动为每个在 Kafka 代理上启用的监听程序创建一个 NetworkPolicy
资源。此 NetworkPolicy
允许应用程序连接到所有命名空间中的监听程序。使用网络策略作为监听器配置的一部分。
如果要将网络级别的监听程序的访问权限限制为所选应用程序或命名空间,请使用 networkPolicyPeers
属性。每个监听程序都可以有不同的 networkPolicyPeers
配置。有关网络策略对等点的更多信息,请参阅 NetworkPolicyPeer API 参考。
如果要使用自定义网络策略,您可以在 Cluster Operator 配置中将 STRIMZI_NETWORK_POLICY_GENERATION
环境变量设置为 false
。如需更多信息,请参阅 第 9.5 节 “配置 Cluster Operator”。
您的 OpenShift 配置必须支持 ingress NetworkPolicies
,以便在 Apache Kafka 的 Streams 中使用网络策略。
15.1.1.4. 提供监听程序证书
您可以为启用了 TLS 加密的 TLS 监听程序或启用了 TLS 加密的外部监听程序提供您自己的服务器证书,称为 Kafka 侦听器证书。如需更多信息,请参阅 第 15.3.4 节 “为 TLS 加密提供自己的 Kafka 侦听器证书”。
15.1.2. Kafka 授权
使用 Kafka 资源中的 Kafka.spec.kafka.authorization
属性为 Kafka
代理配置授权。如果缺少 authorization
属性,则不会启用授权,并且客户端没有限制。启用后,授权将应用到所有已启用的监听程序。授权方法在 type
字段中定义。
支持的授权选项:
- 简单授权
- OAuth 2.0 授权 (如果您使用基于 OAuth 2.0 令牌的身份验证)
- 开放策略代理 (OPA) 授权
- 自定义授权
图 15.2. Kafka 集群授权选项
15.1.2.1. 超级用户
超级用户都可以访问 Kafka 集群中的所有资源,无论访问限制如何,且都由所有授权机制支持。
要为 Kafka 集群指定超级用户,请在 superUsers
属性中添加用户主体列表。如果用户使用 mTLS 身份验证,则用户名是 TLS 证书主题中的通用名称,前缀为 CN=
。如果您不使用 User Operator 并将您自己的证书用于 mTLS,则用户名是完整的证书主题。一个完整的证书主题可以有以下字段: CN=user,OU=my_ou,O=my_org,L=my_location,ST=my_state,C=my_country_code
.省略不存在的任何字段。
具有超级用户的示例配置
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: simple superUsers: - CN=client_1 - user_2 - CN=client_3 - CN=client_4,OU=my_ou,O=my_org,L=my_location,ST=my_state,C=US - CN=client_5,OU=my_ou,O=my_org,C=GB - CN=client_6,O=my_org # ...