[Enhancement]: Improve Kafka Connect CR usability with additional CRD validations

[AkhilaMohan-24]

Related problem

No response

Suggested solution

I was creating new Kafka Connect resources, and realised my resource did not contain valid values. I think this experience can be improved by adding validation for a few commonly misconfigured fields, such as bootstrapServers and secretName etc. in fact this can be applied across all Strimzi resources too (incrementally)
I wondered if adding CEL validations at the CRD level to ensure these fields contain valid values would be a good way to do this without adding complexity of webhooks. I understand this feature is more useful for K8s 1.29+, and currently Strimzi supports 1.27+, so it will only be useful for users on newer version for now and in
For example, we could add a pattern validation to verify that bootstrapServers follows the hostname:port format (or a comma-separated list of such entries). Similarly, for secret names, we could add a pattern validation to ensure they follow Kubernetes naming conventions. This would enable users to provide valid values upfront, reducing the need to analyze logs and fix issues later due to invalid input.
I'm happy to contribute, but wanted to know if this would be something the community feels would add value before I create any PRs.

Alternatives

No response

Additional context

No response

[scholzj]

I'm afraid you missed the window where things like this could have been added to the v1 API. Now - once the API is rolled out - we cannot really introduce anything that would possibly reject a previously valid values. So the next opportunity will be only in another few years with the next API version.

I'm also not sure how feasible it is to use it to validate something as complex as the bootstrap address. Pattern itself does not need a CEL validation rule if I remember correctly. But having a pattern for bootstrap address is not as simple as it sounds. It is not just hostname and port. It is also IP addresses etc. Things can get pretty messy pretty quickly. So I think there is pretty big risk that it even breaks something valid.

Also, when trying some CEL validations in practice, I found out that they are pretty limited and cannot be used in many situations because of the complexity limitations.

[AkhilaMohan-24]

Thanks for the detailed explanation — that makes sense, especially around the v1 API stability guarantees and the risk of rejecting previously valid configurations.

On the bootstrapServers point: the intention was to keep the validation deliberately conservative. The pattern I had in mind already allows both IP addresses and DNS names, and does not attempt to enforce strict DNS-1123 rules. The goal is mainly to catch clearly invalid values (for example placeholders like , missing ports, or illegal characters), rather than to strictly validate all possible bootstrap formats.
Validating bootstrapServers would also add value across multiple Strimzi resources, not just KafkaConnect. Since KafkaBridge and KafkaMirrorMaker2 rely on this field as well, a common validation could help users catch configuration issues early and improve consistency across the operator.

For secretName, the valid format is already clearly defined by Kubernetes. Since Secret names must follow DNS-1123 conventions anyway, adding a CRD-level pattern validation there should not reject any previously valid values and would mainly help catch obvious misconfigurations early.
For example, today a user can specify a Secret name like:

secretName: < instance >-ca-cert
This is accepted by the CRD, but later fails because < and > are not valid characters for Kubernetes Secret names. The user then has to inspect logs or status messages to understand what went wrong.
If we add a simple CRD-level validation for secretName, this would fail early at resource creation time with a clear error message, helping users fix the issue immediately. Since this only enforces existing Kubernetes naming rules, it would not reject any previously valid values.
This would also have broader impact across Strimzi, as secretName is used in multiple resources such as KafkaConnect, KafkaBridge, KafkaMirrorMaker2, Kafka listeners (TLS and authentication), KafkaUser, and Kafka authorization. Having consistent early validation for this field would improve the user experience across all of these CRs.

Would adding validation for fields like secretName (where the allowed format is already well-defined by Kubernetes) be more acceptable, or does the same API-stability concern apply there as well?
Happy to align with whatever approach the community feels is safest — I mainly wanted to explore whether there is any room for incremental validation improvements in areas with minimal risk.

[scholzj]

adding a CRD-level pattern validation there should not reject any previously valid values and would mainly help catch obvious misconfigurations early.

No. This is not about rejecting valid values from the Strimzi perspective. It is about rejecting previously valid values from the CRD perspective. So if the CRD allows an invalid Secret name today, you cannot restrict it because there might be CRs with such a name used that would break. It does not matter that such a CR does not really work in practice and does not result in a correctly deployed operand.

As I said, there was space to change these things as part of the v1 introduction, and that was when we were looking for suggestions like this. Unfortunately, that opportunity is gone now. So the next chance will be likely in a few years with some v2* API.

[AkhilaMohan-24]

Thank you for the detailed explanation — that helps clarify the API stability constraints and the rationale behind them.

I just wanted to double-check my understanding using a concrete example from my testing, to make sure I’m interpreting this correctly.

I tried creating a KafkaConnect resource with an invalid secretName. The CRD accepted the resource successfully, but the resource then transitioned to a NotReady state. Only after checking the operator logs did the underlying issue become clear. For example, I saw errors such as:

BuildConfig.build.openshift.io "names-connect-build" is invalid: spec.output.to.name: Invalid value: "http://us.icr.io/ea-dev-scratch/es/akhila/kafka-connects-img:latest": name is not a valid Docker pull specification: invalid reference format

From a user’s perspective, this means:

The CR is accepted by the API server

The operand never becomes ready

The root cause is only visible later through logs or detailed status messages

I wanted to confirm whether, in this situation, preserving CRD schema compatibility (i.e. not rejecting values that were previously accepted by the CRD) is still considered more important than failing early during admission — even when the configuration is guaranteed to result in a non-functional operand.

I fully understand if the answer is yes due to the long-term API stability guarantees. I mainly wanted to validate this understanding, as from a user-experience point of view this behavior can sometimes be confusing.

Thanks again for taking the time to explain this — I really appreciate the guidance.

[scholzj]

I wanted to confirm whether, in this situation, preserving CRD schema compatibility (i.e. not rejecting values that were previously accepted by the CRD) is still considered more important than failing early during admission — even when the configuration is guaranteed to result in a non-functional operand.

It is not about what we consider more important. Breaking the comptibility at the CRD level can cause all kind of issues to various tools using the resources. So I do not think it is something where we can decide what is more important.

Leaving that aside, to be honest, from my experience, this is not a major issue among our users. You also have many ways to mitigate it:

• Using tooling to generate the custom resources rather than writing them by hand
• Proper review process of the custom resources with some GitOps process
• Custom validating webhooks - you can probably do it even without any real code with tools such as OPA Gatekeeper or Kyverno