[AdityaThakur1998]

Design proposal for kroxylicious/kroxylicious#3032 — configuring the TLS subject builder through the Kubernetes Operator.

What it proposes

An optional tlsSubjectBuilder field on VirtualKafkaCluster, with a type and a configTemplate, matching the shape of the proxy's existing virtual cluster subjectBuilder. As with KafkaProtocolFilter, configTemplate can refer to Secrets and ConfigMaps, which the Operator resolves before writing the result into the generated proxy configuration. When the field is unset, behaviour is the same as today, so the change is purely additive.

The proxy already supports subject builders; the Operator just has no way to set one. The proposal exposes an existing capability rather than adding a new one, and needs no proxy changes.

Why it matters

Authorization decides what a client may do based on its principal. Clients that authenticate with SASL get a principal from the SASL filters. Clients that authenticate with a TLS client certificate need a subject builder to turn the certificate into a principal, and under the Operator there's no way to configure one. Operator users who rely on certificates therefore can't use Authorization at all.

Points reviewers may want to weigh in on

• The field name. tlsSubjectBuilder was chosen over subjectBuilder, because the SASL filters already use subjectBuilder for something different. The cost is that the name differs from the proxy's own config key.
• Validation. Following filters, the Operator checks that referenced Secrets and ConfigMaps exist but passes the rest of configTemplate through unchecked, and the proxy rejects invalid config at startup. One proxy serves all its virtual clusters, so one cluster's mistake stops the proxy for all of them. Operator-side validation is listed as future work, covering all plugin config.
• Inline rather than a shared resource. A separate resource would let rules be shared, and locked down with Kubernetes permissions separately from the cluster. It's rejected here as too much machinery for a few lines of rules. Feedback is welcome on whether anyone needs separate ownership.
• Scope. SASL subject builders are out of scope. So is sidecar mode, because the app-to-sidecar connection is plaintext over localhost, so there's no client certificate.

Assisted-by: Claude Sonnet 4.6 noreply@anthropic.com

[tombentley]

Hi @AdityaThakur1998 thanks for pushing this forward, it would be nice to support for sure. Mostly this is a good proposal, but I feel the need to push back a bit on what you're saying about the need for secret interpolation.

[tombentley]

Thanks @AdityaThakur1998 this LGTM

[k-wall]

Couple of nits and comments, but LGTM