如何运行具有多个kerberos缓存的python kafka应用程序？

Question

我有一个 python 微服务应用程序，根据请求将特定消息发送到具有特定主体的特定 kafka 主题。所有参数均由用户在请求正文中控制。如何避免Kafka线程安全问题？

我确实知道我可以通过环境变量控制kerberos缓存

KRB5CCNAME

，但是如果我碰它，它就不是线程安全的（Kafka的一个线程可能会与另一个线程发生冲突，毕竟不会让我用正确的方式到达正确的主题）证书）。如果我通过多重处理来完成它，那么它不会提高内存效率，因为我需要处理可能有数百个这样的主题。如果我不触摸

KRB5CCNAME

，那么每个

kinit

命令都会用新票覆盖相同的缓存，这样会导致安全漏洞（错误的应用程序可能会发布到错误的主题）。

我无法控制基础设施，也无法选择更改架构的设计模式（无法获得一个可以访问多个主题的主体，它必须是“自带凭据和主题”方法）

如何在不进行多处理的情况下从单个 python 进程同时实现具有不同主体的并发 Kafka 会话？

我在 RHEL8 上使用

confluent-kafka-python

（以及相应的

librdkafka

）和 vanilla

Flask

以及 MIT kerberos。

Answer 1

不是让 libgssapi 自己查找凭据，而是需要重写 librdkafka 库的部分内容，以使用 GSSAPI 显式获取 Kerberos 凭据凭据存储扩展现在可在 MIT libkrb5 中使用（我也相信 Heimdal）。

gssproxy

守护进程和 Apache

mod_auth_gssapi

模块是在 C 代码中使用这些扩展来访问同一进程中的多组凭据的好例子。对于纯 Python 代码，

python-gssapi

通过

gssapi.Credential

使这些扩展易于使用 – 理想情况下，Python kafka 绑定会以某种方式使用它。

但除了实际重写库中读取进程全局环境变量的部分之外，没有秘密后门可以使非线程安全库以某种方式实现线程安全。 （也许，除了将 Kafka 相关代码分离到自己的守护进程中，并确保它会为每个主题分叉一个新进程之外，它不应该非常低效，因为“多处理”似乎使用 fork() 而不是派生一个全新的进程，即大部分内存实际上是共享的写时复制。）

如果我不接触 KRB5CCNAME，那么每个 kinit 命令都会用新票证覆盖相同的缓存，这样会导致安全漏洞（错误的应用程序可能会发布到错误的主题）。

当前的 MIT Kerberos 或 Heimdal Kerberos 不一定如此。虽然基于

FILE:

的缓存只能保存单个主体的票证，但这两个库还支持

DIR:<path>

基于目录的缓存集合，其中每个新的

kinit

仅 添加 一个新的票证缓存（并且

klist -A

将显示全部）。我认为海姆达尔的

SQLITE:

也是多原则的。

虽然 DIR 仍然具有针对旧 API 的“活动”缓存概念，但对服务主体票证的标准请求将使用所有这些缓存，而不仅仅是活动的 API。借助 MIT Kerberos，在集合中的缓存之间进行选择的算法可以受

~/.k5identity

的影响，将服务主体域映射到 Kerberos 领域。

不幸的是，这在您的情况下完全没有用，因为听起来所有凭据都用于完全相同的服务器。