Type of change

• Bugfix

Description

Currently, we use forbidden prefixes to block users from setting various configurations managed directly by the Strimzi Cluster Operator. When a user configures any option starting with the prefix (apart from the defined exceptions), the option will be ignored and removed from the config. This worked fine so far for most operands which have mostly a static set of configuration options.

But it does not work well for Kafka Connectors. In Kafka Connectors, we block three options: name, connector.class, and tasks.max. These are all important options to block as they would cause errors if they were set by users (especially the name option). But in Kafka Connectors, each connector has different configuration options. And therefore the likelihood of a conflict when blocking the whole prefix is not impossible, especially with a generic option such as name. #10500 describes one such conflict.

This PR improves how we handle the forbidden prefixes. It keeps the original logic, but it also adds support for forbidden options to the AbstractConfiguration. That allows us to keep the existing logic where it suits (for example blocking whole range of security-related options). But it allows to also block individual options such as those in Kafka Connectors instead of treating them as prefixes. That allows us to use options such as namespace.mapper while blocking the option name

I considered some other alternatives as well. For example

• Using regular expressions in the forbidden prefixes -> that way one can specify whether it blocks a particular name or a prefix
• Doing the validation differently for Kafka Connector configs

But the approach used in the PR (and described above) seemed best to me.

Apart from the actual fix, this PR also cleans up the various methods in AbstractConfiguration. It keeps only 3 constructors (one copy constructor and two regular ones) and makes it much easier to test this class as there are only two execution paths and not 8 of them.

This should resolve #10500.

Checklist

• Write tests
• Make sure all tests pass
• Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
• Reference relevant issue(s) and close them after merging