我有一个python微服务应用程序，根据请求将特定消息发送到具有特定主体的特定Kafka主题。所有参数在请求体中由用户控制。如何避免Kafka线程安全问题？
我确实知道我可以通过env变量KRB5CCNAME控制kerrycache，但是如果我触摸它，它将不是线程安全的（Kafka的一个线程可能会与另一个线程冲突，毕竟不让我用正确的凭据到达正确的主题）。如果我通过多处理来做，那么它将不会是内存有效的，因为我需要处理潜在的数百个这样的主题。如果我不碰KRB5CCNAME，那么每个kinit命令都会用新的ticket覆盖相同的缓存，这样会导致安全漏洞（错误的应用程序可以发布到错误的主题）。
我不能控制基础设施，也不能选择改变架构的设计模式（不能让一个主体访问许多主题，它必须是“带上你自己的凭证和主题”的方法）
如何从单个python进程中同时实现不同主体的并发Kafka会话，而无需多处理？
我使用confluent-kafka-python（以及相应的librdkafka）和带有MIT内核的RHEL8上的vanilla Flask。
1条答案
按热度按时间uqcuzwp81#
与其让libgssapi自己查找凭证，librdkafka库的部分内容需要重写，以使用MIT libkrb 5中现在可用的GSSAPI Credential Store extensions显式获取SSL凭证（我也相信Heimdal）。
gssproxy守护进程和Apachemod_auth_gssapi模块是在C代码中使用这些扩展来访问同一进程中的多个凭据集的很好示例。对于纯Python代码，python-gssapi通过gssapi.Credential使这些扩展易于使用-理想情况下，Python Kafka绑定将以某种方式使用它。但是，除了实际上 * 重写 * 读取进程全局环境变量的库部分为Not Do That之外，没有秘密后门可以使非线程安全的库以某种方式线程安全。（也许，除了将Kafka相关的代码分离到自己的守护进程中，并确保它会为每个主题派生一个新进程-它不应该非常低效，因为“多处理”似乎使用fork（）而不是产生一个全新的进程，即大部分存储器实际上是共享的写时复制。
如果我不碰KRB 5CCNAME，那么每个kinit命令都会用新的ticket覆盖相同的缓存，这样会导致安全漏洞（错误的应用程序可以发布到错误的主题）。
对于当前的MIT Kerberos或Heimdal Kerberos来说，这不一定是正确的。虽然基于
FILE:的缓存只能为单个主体保存票据，但这两个库还支持基于目录的缓存集合的DIR:<path>，其中每个新的kinit仅 * 添加 * 一个新的票据缓存（而klist -A将显示所有）。我认为Heimdal的SQLITE:也是多主体的。尽管DIR仍然有用于遗留API的“活动”缓存的概念，但对服务主体票证的标准请求将使用所有缓存-而不仅仅是活动缓存。使用MIT Cache，在集合中选择缓存的算法可以受
~/.k5identity的影响，将服务主体域Map到缓存域。不幸的是，这在您的情况下将完全无用，因为听起来所有凭据都用于完全相同的服务器。