【问题标题】:Strimzi - Connecting to External OpenShift Route Listener with SCRAM-SHA-512 Authentication with TLS with SaramaStrimzi - 使用 SCRAM-SHA-512 身份验证连接到外部 OpenShift 路由侦听器,使用 TLS 和 Sarama
【发布时间】:2021-10-19 17:44:06
【问题描述】:

我有一个带有以下 yaml 的 Strimzi 集群设置。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: kafka
spec:
  kafka:
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external
        port: 9094
        type: route
        authentication:
          type: scram-sha-512
        tls: true

pod 运行良好,我使用 SCRAM-512 创建了一个 KafkaUser CR,如下所示 -

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: scram-user
  labels:
    strimzi.io/cluster: kafka
spec:
  authentication:
    type: scram-sha-512

我已经从密钥中正确提取了 SCRAM 密码,并从 cluster-ca-cert 密钥中获取了ca.crt 文件。我正在尝试遵循此示例中的 Go Sarama 代码 - https://github.com/Shopify/sarama/blob/master/examples/sasl_scram_client/main.go

我还从 OpenShift Route 正确获取了引导服务器地址,但我似乎无法连接。

go run sarama.go scram_client.go -brokers bootstrap-address:443  -username scram-user -passwd esoy2WksWRBp -topic test-topic -algorithm sha512 -tls true -ca /path/ca.crt

我尝试了上述命令的一些变体,添加了-certificate-key 标志,但似乎都没有。我的监听器设置错误吗?

编辑 - 忘记包含并提及它,但这是我从 Go Sarama 代码中得到的错误。

[Sarama] 2021/08/18 09:22:36 Failed to send SASL handshake kafka-broker:443: x509: certificate signed by unknown authority
[Sarama] 2021/08/18 09:22:36 Closed connection to broker kafka-broker:443
[Sarama] 2021/08/18 09:22:36 client/metadata got error from broker -1 while fetching metadata: x509: certificate signed by unknown authority
[Sarama] 2021/08/18 09:22:36 client/metadata no available broker to send metadata request to
[Sarama] 2021/08/18 09:22:36 client/brokers resurrecting 1 dead seed brokers
[Sarama] 2021/08/18 09:22:36 Closing Client
[Producer] 2021/08/18 09:22:36 failed to create producer:  kafka: client has run out of available brokers to talk to (Is your cluster reachable?)
exit status 1

所以这看起来是一个证书问题,但我似乎已按照正确的说明获取证书。我的 Kafka 代理刚刚命名为 kafka,因此秘密命名为 kafka-cluster-ca-cert。 ca.crt 文件是我提供给 Sarama 代码的路径。

oc get secret kafka-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

如果重要,请描述秘密 -

╰─ oc describe secret kafka-cluster-ca-cert
Name:         kafka-cluster-ca-cert
Namespace:    strimzi
Labels:       app.kubernetes.io/instance=kafka
              app.kubernetes.io/managed-by=strimzi-cluster-operator
              app.kubernetes.io/name=strimzi
              app.kubernetes.io/part-of=strimzi-kafka
              strimzi.io/cluster=kafka
              strimzi.io/kind=Kafka
              strimzi.io/name=strimzi
Annotations:  strimzi.io/ca-cert-generation: 0

Type:  Opaque

Data
====
ca.crt:       1854 bytes
ca.p12:       1687 bytes
ca.password:  12 bytes

【问题讨论】:

  • 监听器配置看起来不错。我没有使用 Sarama 和 SCRAM-SHA-512 的经验……从链接的 Golang 文件中,您的选项看起来不错,但我不知道您是否需要做任何其他事情。您从客户那里得到什么错误并形成经纪人?
  • @Jakub 你好 Jakub。抱歉,我添加了一个带有 Sarama 错误的编辑以及获取 ca 证书的命令。
  • 另一个小注意事项 - 作为健全性检查,我使用 tls: true 的 Route 侦听器启动了一个新的 Kafka 集群,并且没有 SCRAM 身份验证,它使用通常的步骤通过从kafka-cluster-ca-cert secret 等。不确定 SCRAM + TLS 到底是什么问题。虽然我没有使用 Sarama Go 客户端,但我使用了 confluent-go 客户端,因为之前链接的 Sarama 客户端期望 SASL 用户名/密码,这一次显然丢失了。
  • 上次更新 - 我发现了问题并发布了问题的答案。

标签: apache-kafka openshift strimzi sarama


【解决方案1】:

所以事实证明问题主要是命令行问题。当我应该只使用-certificate 标志时,我一直尝试使用-ca 标志。我还需要添加-verify 选项标志。所以允许我生成的命令是使用以下 -

go run sarama.go scram_client.go -brokers <your-kafka-boostrap-address>:443  -username <your-scram-username> -passwd <your-scram-password> -topic <your-topic> -algorithm sha512 -tls -certificate <full-path-to-your-cert-file>/ca.crt -verify true

还有消费的命令

go run sarama.go scram_client.go -brokers <your-kafka-boostrap-address>:443  -username <your-scram-username> -passwd <your-scram-password> -topic <your-topic> -mode consume -logmsg -algorithm sha512 -tls -certificate <full-path-to-your-cert-file>/ca.crt -verify true

我猜的经验教训 - 了解 CA、证书和密钥之间的区别。

【讨论】:

    猜你喜欢
    • 2015-12-20
    • 2017-11-04
    • 2015-10-02
    • 2016-05-30
    • 2018-11-14
    • 2023-04-07
    • 2022-07-14
    • 1970-01-01
    • 2012-09-15
    相关资源
    最近更新 更多