第 4 章 管理对 Kafka 的安全访问
您可以通过管理每个客户端对 Kafka 代理的访问权限来保护 Kafka 集群。
Kafka 代理和客户端之间的安全连接可以包含：
- 为数据交换加密
- 验证以证明身份
- 允许或拒绝用户执行的操作的授权
本章解释了如何在 Kafka 代理和客户端之间设置安全连接，包含如下所述：
- Kafka 集群和客户端的安全选项
- 如何保护 Kafka 代理
- 如何使用授权服务器进行基于 OAuth 2.0 令牌的身份验证和授权
4.1. Kafka 的安全选项
使用 Kafka 资源配置用于 Kafka 身份验证和授权的机制。
4.1.1. 监听程序验证
对于 OpenShift 集群内的客户端，您可以创建 普通 （无需加密）或 tls 内部 侦听器。
对于 OpenShift 集群外的客户端，您可以创建 外部 侦听器并指定连接机制，可以是 节点端口、负载均衡器、 入口 或 路由 （在 OpenShift 上）。
有关连接外部客户端的配置选项的更多信息，请参阅配置外部监听程序。
支持的验证选项：
- 双向 TLS 身份验证（仅在启用了 TLS 加密的监听器中）
- SCRAM-SHA-512 验证
- 基于 OAuth 2.0 令牌的身份验证
您选择的身份验证选项取决于您要如何验证客户端对 Kafka 代理的访问。
图 4.1. Kafka 侦听程序验证选项
侦听器 身份验证 属性用于指定特定于该侦听器的身份验证机制。
如果没有指定 身份验证 属性，侦听器不会验证通过该侦听器进行连接的客户端。侦听器将接受所有连接，无需身份验证。
在使用 User Operator 管理 KafkaUsers 时，必须配置身份验证。
以下示例显示：
-
为 SCRAM-SHA-512 身份验证配置
的普通监听器 -
具有 mutual TLS 身份验证的 A
tls侦听器 -
具有 mutual TLS 身份验证
的外部监听程序
每个监听程序都使用 Kafka 集群中的唯一名称和端口进行配置。
无法将监听器配置为使用为 Interbroker 通信(9091)和指标(9404)设置的端口。
显示监听器身份验证配置的示例
# ...
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: external
port: 9094
type: loadbalancer
tls: true
authentication:
type: tls
# ...
4.1.1.1. 双向 TLS 身份验证
双向 TLS 身份验证始终用于 Kafka 代理和 ZooKeeper pod 之间的通信。
AMQ Streams 可以配置 Kafka 以使用 TLS（传输层安全），以提供 Kafka 代理和客户端之间的加密通信，无论是否带有或不使用相互身份验证。为互相或双向身份验证，服务器和客户端都提供证书。当您配置相互身份验证时，代理会验证客户端（客户端身份验证），客户端验证代理（服务器身份验证）。
TLS 身份验证更通常是单向，一个方验证另一方的身份。例如，当 Web 浏览器和 Web 服务器之间使用 HTTPS 时，浏览器会获得 Web 服务器身份验证。
4.1.1.2. SCRAM-SHA-512 验证
SCRAM（销售挑战响应身份验证机制）是一种身份验证协议，可以使用密码建立相互身份验证。AMQ Streams 可以配置 Kafka，以使用 SASL（简单身份验证和安全层） SCRAM-SHA-512 提供未加密和加密客户端连接的身份验证。
当 SCRAM-SHA-512 身份验证与 TLS 客户端连接一起使用时，TLS 协议提供加密，但不用于身份验证。
以下 SCRAM 属性可以安全地在未加密连接中使用 SCRAM-SHA-512：
- 密码不会通过通信通道在明文中发送。相反，客户端和服务器都受到另一用户的挑战，难以提供他们知道验证用户密码的证明。
- 服务器和客户端各自为每个身份验证交换生成新的挑战。这意味着交换具有应对重播攻击的弹性。
当使用 scr am-sha-512 配置 KafkaUser.spec.authentication.type 时，User Operator 将生成由大写和小写 ASCII 字母和数字组成的随机 12 个字符密码。
4.1.1.3. 网络策略
AMQ Streams 自动为每个在 Kafka 代理上启用的监听程序创建一个 NetworkPolicy 资源。默认情况下，NetworkPolicy 会 授予监听器访问所有应用程序和命名空间的权限。
如果要将网络级别的监听器访问限制为仅选择的应用程序或命名空间，请使用 networkPolicyPeers 属性。
使用网络策略作为监听器身份验证配置的一部分。每个监听器都可以具有不同的 networkPolicyPeers 配置。
如需更多信息，请参阅 Listener 网络策略 部分和 NetworkPolicyPeer API 参考。
您的 OpenShift 配置必须支持 Ingress NetworkPolicies，以便在 AMQ Streams 中使用网络策略。
4.1.1.4. 其他监听程序配置选项
您可以使用 GenericKafkaListenerConfiguration 模式 的属性在监听器中添加更多配置。
4.1.2. kafka 授权
您可以使用 Kafka. spec.kafka 资源中的 代理配置授权。如果缺少 authorization 属性为 Kafkaauthorization 属性，则不启用授权，并且客户端没有限制。启用后，授权将应用到所有启用的监听程序。授权方法在 type 字段中定义。
支持的授权选项：
- 简单授权
- OAuth 2.0 授权 （如果您使用基于 OAuth 2.0 令牌的身份验证）
- 打开策略代理(OPA)授权
图 4.2. Kafka 集群授权选项
4.1.2.1. 超级用户
无论访问限制如何，超级用户可以访问 Kafka 集群中的所有资源，并受所有授权机制的支持。
要为 Kafka 集群指定超级用户，请在 superUsers 属性中添加用户主体列表。如果用户使用 TLS 客户端身份验证，则其用户名是其证书主题的通用名称，前缀为 CN=。
带有超级用户的示例配置
authorization:
type: simple
superUsers:
- CN=client_1
- user_2
- CN=client_3
