Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed
  • Is something wrong?
#4,093 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@aliok is already working on this.

Since Oct 21, 2026.

  • #4101 by @aliok — merged

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go, kubernetes
Domain
backend, devops

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
Go
Stars
366
Forks
226
Avg merge
1d 10h
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from knative/func

All issues in knative/func

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.