14.3. 保护对 Kafka 代理的访问
要建立对 Kafka 代理的安全访问,请配置并应用:
一个
Kafka
资源:- 使用指定验证类型创建监听程序
- 为整个 Kafka 集群配置授权
-
通过监听程序安全地访问 Kafka 代理的
KafkaUser
资源
配置 Kafka
资源来设置:
- 侦听器身份验证
- 限制访问 Kafka 监听器的网络策略
- Kafka 授权
- 超级用户对代理的访问没有限制
身份验证是为每个监听器独立配置的。始终为整个 Kafka 集群配置授权。
Cluster Operator 创建监听程序并设置集群和客户端证书颁发机构(CA)证书,以便在 Kafka 集群中启用身份验证。
您可以通过安装自己的证书来替换 Cluster Operator 生成的证书。
您还可以为启用了 TLS 加密的任何监听程序提供自己的服务器证书和私钥。这些用户提供的证书称为 Kafka 侦听器证书。通过提供 Kafka 侦听器证书,您可以利用现有的安全基础架构,如机构的私有 CA 或公共 CA。Kafka 客户端需要信任用于为监听器证书签名的 CA。在需要时,您必须手动续订 Kafka 侦听器证书。证书以 PKCS #12 格式 (.p12) 和 PEM (.crt) 格式提供。
使用 KafkaUser
启用特定客户端用来访问 Kafka 的身份验证和授权机制。
配置 KafkaUser
资源来设置:
- 与启用的监听程序身份验证匹配的身份验证
- 与启用的 Kafka 授权匹配的授权
- 客户端控制资源使用的配额
User Operator 根据所选的验证类型,创建代表客户端的用户以及用于客户端身份验证的安全凭证。
有关访问配置属性的更多信息,请参阅 schema 参考:
14.3.1. 保护 Kafka 代理
此流程显示在运行 AMQ Streams 时保护 Kafka 代理的步骤。
为 Kafka 代理实现的安全性必须与需要访问权限的客户端实现的安全兼容。
-
Kafka.spec.kafka.listeners[*].authentication
匹配KafkaUser.spec.authentication
-
Kafka.spec.kafka.authorization
匹配KafkaUser.spec.authorization
这些步骤显示简单授权的配置以及使用 mTLS 身份验证的监听程序。有关监听器配置的更多信息,请参阅 GenericKafkaListener
模式参考。
另外,您可以使用 SCRAM-SHA 或 OAuth 2.0 进行 监听程序身份验证,并将 OAuth 2.0 或 OPA 用于 Kafka 授权。
流程
配置
Kafka
资源。-
配置授权的
authorization
属性。 配置
listeners
属性,以创建具有身份验证的监听程序。例如:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... authorization: 1 type: simple superUsers: 2 - CN=client_1 - user_2 - CN=client_3 listeners: - name: tls port: 9093 type: internal tls: true authentication: type: tls 3 # ... zookeeper: # ...
- 1
- 2
- 对 Kafka 有无限访问权限的用户主体列表。当使用 mTLS 身份验证时,CN 是客户端证书的通用名称。
- 3
- 可以为每个监听程序配置监听程序身份验证机制,并指定为 mTLS、SCRAM-SHA-512 或基于令牌的 OAuth 2.0。
如果要配置外部监听程序,则配置取决于所选的连接机制。
-
配置授权的
创建或更新
Kafka
资源。oc apply -f <kafka_configuration_file>
Kafka 集群使用 mTLS 身份验证配置 Kafka 代理监听程序。
为每个 Kafka 代理 pod 创建一个服务。
创建一个服务作为与 Kafka 集群连接的 bootstrap 地址。
在 secret <cluster
_name> -cluster-ca-cert 中还创建了用于验证 kafka 代理的身份的集群
CA 证书。
14.3.2. 保护用户对 Kafka 的访问
创建或修改 KafkaUser
以代表需要对 Kafka 集群进行安全访问的客户端。
当您配置 KafkaUser
身份验证和授权机制时,请确保它们与对应的 Kafka
配置匹配:
-
KafkaUser.spec.authentication
匹配Kafka.spec.kafka.listeners[*].authentication
-
KafkaUser.spec.authorization
匹配Kafka.spec.kafka.authorization
此流程演示了如何使用 mTLS 身份验证创建用户。您还可以创建带有 SCRAM-SHA 身份验证的用户。
所需的身份验证取决于 为 Kafka 代理监听程序配置的验证类型。
Kafka 用户和 Kafka 代理之间的身份验证取决于每个代理的身份验证设置。例如,如果在 Kafka 配置中也未启用,则无法验证带有 mTLS 的用户。
先决条件
- 正在运行的 Kafka 集群使用 mTLS 身份验证和 TLS 加密配置 Kafka 代理监听程序。
- 正在运行的用户 Operator (通常使用 Entity Operator 部署)。
KafkaUser
中的身份验证类型应与 Kafka
代理中配置的身份验证匹配。
流程
配置
KafkaUser
资源。例如:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: 1 type: tls authorization: type: simple 2 acls: - resource: type: topic name: my-topic patternType: literal operations: - Describe - Read - resource: type: group name: my-group patternType: literal operations: - Read
创建或更新
KafkaUser
资源。oc apply -f <user_config_file>
创建了用户,以及名称与
KafkaUser
资源相同的 Secret。Secret 包含 mTLS 身份验证的私钥和公钥。
有关配置带有与 Kafka 代理安全连接的属性的 Kafka 客户端的详情,请参考 第 13.4 节 “使用监听程序设置对 Kafka 集群的客户端访问”。
14.3.3. 使用网络策略限制 Kafka 侦听程序的访问
您可以使用 networkPolicyPeers
属性限制对监听程序的访问。
先决条件
- 支持 Ingress NetworkPolicies 的 OpenShift 集群。
- Cluster Operator 正在运行。
流程
-
打开
Kafka
资源。 在
networkPolicyPeers
属性中,定义允许访问 Kafka 集群的应用程序 pod 或命名空间。例如,将
tls
侦听器配置为只允许来自应用程序 pod 的连接,标签app
设置为kafka-client
:apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: kafka: # ... listeners: - name: tls port: 9093 type: internal tls: true authentication: type: tls networkPolicyPeers: - podSelector: matchLabels: app: kafka-client # ... zookeeper: # ...
创建或更新资源。
使用
oc apply
:oc apply -f your-file
14.3.4. 为 TLS 加密提供自己的 Kafka 侦听器证书
监听器提供对 Kafka 代理的客户端访问。在 Kafka
资源中配置监听程序,包括使用 TLS 进行客户端访问所需的配置。
默认情况下,监听程序使用由 AMQ Streams 生成的内部 CA (证书颁发机构)证书签名的证书。Cluster Operator 在创建 Kafka 集群时生成 CA 证书。当您为 TLS 配置客户端时,您可以将 CA 证书添加到其信任存储配置中以验证 Kafka 集群。您还可以安装和使用自己的 CA 证书。或者,您可以使用 brokerCertChainAndKey
属性配置监听程序,并使用自定义服务器证书。
brokerCertChainAndKey
属性允许您使用在监听器级别自己的自定义证书访问 Kafka 代理。您可以使用自己的私钥和服务器证书创建 secret,然后在监听器的 brokerCertChainAndKey
配置中指定密钥和证书。您可以使用由公共(外部)CA 或私有 CA 签名的证书。如果由公共 CA 签名,通常不需要将其添加到客户端的信任存储配置中。自定义证书不由 AMQ Streams 管理,因此需要手动续订。
侦听器证书仅用于 TLS 加密和服务器身份验证。它们不用于 TLS 客户端身份验证。如果还想将自己的证书用于 TLS 客户端身份验证,您必须安装和使用自己的客户端 CA。
先决条件
- Cluster Operator 正在运行。
每个监听程序都需要以下内容:
由外部 CA 签名的兼容服务器证书。(提供 PEM 格式的 X.509 证书。)
您可以将一个监听程序证书用于多个监听程序。
- 主题备用名称(SAN)在每个监听器的证书中指定。更多信息请参阅 第 14.3.5 节 “Kafka 监听器的服务器证书中的替代主题”。
如果您不使用自签名证书,您可以提供一个证书中包含整个 CA 链的证书。
如果为监听程序配置了 TLS 加密(tls: true
),则只能使用 brokerCertChainAndKey
属性。
AMQ Streams 不支持为 TLS 使用加密私钥。存储在 secret 中的私钥必须未加密的才能正常工作。
流程
创建包含私钥和服务器证书的
Secret
:oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
编辑集群的
Kafka
资源。将监听程序配置为在
configuration.brokerCertChainAndKey
属性中使用您的Secret
、证书文件和私钥文件。启用 TLS 加密的
loadbalancer
外部监听程序配置示例# ... listeners: - name: plain port: 9092 type: internal tls: false - name: external3 port: 9094 type: loadbalancer tls: true configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
TLS 侦听器配置示例
# ... listeners: - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
应用新配置以创建或更新资源:
oc apply -f kafka.yaml
Cluster Operator 启动 Kafka 集群的滚动更新,该集群更新监听程序的配置。
注意如果您在被监听程序使用的
Secret
中更新 Kafka 侦听器证书,也会启动滚动更新。
14.3.5. Kafka 监听器的服务器证书中的替代主题
要将 TLS 主机名验证与您自己的 Kafka 侦听器证书 搭配使用,您必须为每个监听程序使用正确的主题备用名称(SAN)。证书 SAN 必须为以下内容指定主机名:
- 集群中的所有 Kafka 代理
- Kafka 集群 bootstrap 服务
如果您的 CA 支持,您可以使用通配符证书。
14.3.5.1. 内部监听程序的 SAN 示例
使用以下示例帮助您为内部监听程序在证书中指定 SAN 的主机名。
将 <cluster-name
> 替换为 Kafka 集群的名称,将 <namespace
> 替换为运行集群的 OpenShift 命名空间。
类型的通配符示例:内部监听程序
//Kafka brokers *.<cluster-name>-kafka-brokers *.<cluster-name>-kafka-brokers.<namespace>.svc // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
类型:内部监听程序
的非通配符示例
// Kafka brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc <cluster-name>-kafka-1.<cluster-name>-kafka-brokers <cluster-name>-kafka-1.<cluster-name>-kafka-brokers.<namespace>.svc # ... // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
类型的非通配符示例:cluster-ip
listener
// Kafka brokers <cluster-name>-kafka-<listener-name>-0 <cluster-name>-kafka-<listener-name>-0.<namespace>.svc <cluster-name>-kafka-<listener-name>-1 <cluster-name>-kafka-<listener-name>-1.<namespace>.svc # ... // Bootstrap service <cluster-name>-kafka-<listener-name>-bootstrap <cluster-name>-kafka-<listener-name>-bootstrap.<namespace>.svc
14.3.5.2. 外部监听程序的 SAN 示例
对于启用了 TLS 加密的外部监听程序,您需要在证书中指定的主机名取决于外部监听程序 类型
。
外部监听程序类型 | 在 SANs 中,指定… |
---|---|
|
所有 Kafka 代理 您可以使用匹配的通配符名称。 |
|
所有 Kafka 代理 您可以使用匹配的通配符名称。 |
|
所有 Kafka 代理 您可以使用匹配的通配符名称。 |
| Kafka 代理 pod 可能调度到的所有 OpenShift worker 节点的地址。 您可以使用匹配的通配符名称。 |