Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Kafka sidecar: a volume mounted at a parent of a run.kafka.tls cert path is wrongly removed from the function container

クローズ
  • 何か問題がありますか？
#4,093 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@aliok がすでに取り組んでいます。

2026年10月21日 から。

  • #4101 @aliok による — マージ済み

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go, kubernetes
領域
backend, devops

調査の方向性

Start with kafkaSidecarVolumeMounts in pkg/k8s/deployer.go and compare its path matching with findSecretForPath in pkg/keda/kafka_scaling.go. Trace how the selected mounts are passed to excludeVolumeMounts, then run the relevant deployer tests or add a case for a PVC at /data and a Kafka Secret at /data/certs. Done when the PVC remains mounted in the function and only the Secret backing the certificate is moved to the sidecar.

索引モデルが issue の本文から書いたものです。

説明

kind/bug

What happens

When a function consumes from Kafka with TLS (run.kafka.tls.*), the Kafka
runtime sidecar is given the volume mount(s) that back the configured certificate
paths, and those volumes are then excluded from the function (user) container so
the private key never lands in application code's filesystem.

The mount-selection logic over-matches: it keeps every volume mount whose path
is an ancestor directory of a cert path, not just the volume that actually backs
the certificate. If an unrelated volume (a PVC, ConfigMap, emptyDir, or another
Secret) is mounted at a parent directory of a Kafka cert path, that volume is:

  1. mounted into the sidecar (unnecessary), and
  2. removed from the function container (by excludeVolumeMounts, which drops
    by volume name).

The function therefore silently loses a volume mount it depends on.

Reproduce

run:
  volumes:
    - persistentVolumeClaim:
        claimName: data-pvc
      path: /data
    - secret: kafka-cert
      path: /data/certs
  kafka:
    brokers: kafka:9092
    topic: orders
    consumerGroup: my-func
    securityProtocol: SSL
    tls:
      caCert: /data/certs/ca.crt

Deploy with the raw or keda deployer. The kafka-cert secret at /data/certs
legitimately backs the CA cert, so it is moved to the sidecar. But because
/data (the PVC) is also a parent directory of /data/certs/ca.crt, the PVC mount
is swept into the same set and then excluded from the function container. The
function comes up without /data.

Root cause

kafkaSidecarVolumeMounts in pkg/k8s/deployer.go matches a mount when the cert
path equals the mount path or is nested under it:

for _, vm := range volumeMounts {
    mountPath := path.Clean(vm.MountPath)
    for _, cp := range certPaths {
        if cp == mountPath || strings.HasPrefix(cp, mountPath+"/") {
            mounts = append(mounts, vm)
            break
        }
    }
}

This has two problems:

  • It considers all volume types, not only Secrets. A Kafka TLS certificate can
    only come from a Secret, so a PVC/ConfigMap/emptyDir at an ancestor path should
    never be treated as backing the cert.
  • It keeps every ancestor mount rather than the single most-specific (longest
    mount path) one that actually provides the file.

The sibling resolver on the keda path, findSecretForPath
(pkg/keda/kafka_scaling.go), already skips non-Secret volumes
(if v.Secret == nil || v.Path == nil { continue }), so the KEDA
TriggerAuthentication wiring resolves the correct secret in this scenario. The
two code paths are not actually at parity even though the comment on
kafkaSidecarVolumeMounts says they use "the same path-to-volume matching."

Impact

  • Silent: no error; the function just comes up missing a volume, which typically
    surfaces later as a confusing runtime failure.
  • Scope: only functions that both (a) configure run.kafka.tls.* and (b) mount an
    unrelated volume at a parent directory of a cert path. Mounting the cert Secret
    at a path that is not nested under another volume avoids it.

Workaround

Mount the Kafka TLS Secret at a path that is not nested under another volume's
mount path (e.g. /etc/kafka/certs instead of /data/certs when /data is a
PVC).

Suggested fix

Make kafkaSidecarVolumeMounts mirror findSecretForPath: only consider Secret
volumes as cert backers, and select the single most-specific matching mount (or
resolve the exact backing Secret via findSecretForPath and mount only that
volume into the sidecar). That keeps the sidecar/user-container split correct and
brings the two code paths genuinely into parity.

Follow-up to #4060 (language-agnostic Kafka runtime sidecar).

/kind bug

主要言語
Go
スター
366
フォーク
226
平均マージ
1日 9時間
マージ済み PR（30日）
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

knative/func のほかの issue

knative/func の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。