[labrenbe]

Part of stackabletech/issues#888.

Depends on stackabletech/operator-rs#1290.

Description

Adds management access: an optional agent, deployed by the operator next to a KafkaCluster, to manage resources inside Kafka.

• New spec.clusterConfig.managementAccess on the KafkaCluster, which enables the agent and chooses how it authenticates to Kafka: anonymously, with a client certificate from a SecretClass, or with a static Secret.
• The operator deploys one agent per KafkaCluster as a Deployment with its own ServiceAccount and RoleBinding, and removes it again when management access is disabled. The agent binary ships in the operator image.
• The agent connects through the headless Services of the broker role groups, so its traffic stays inside the Kubernetes cluster regardless of the ListenerClasses, and verifies the brokers with the CA of the client listener.
• Management access requires the operator image to be known to the operator and is currently limited to KRaft clusters. Clusters with Kerberos authentication are not supported in this version.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Helm chart can be installed and deployed operator works
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible
• Links to generated (nightly) docs added
• Release note snippet added

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added
• Links to generated (nightly) docs added
• Release note snippet added
• Add type/deprecation label & add to the deprecation schedule
• Add type/experimental label & add to the experimental features tracker

[adwk67]

TODO: revert to a tag when ready.

[adwk67]

Assuming that the agent image can use the same credentials as the product image is fine as long as they come from the same registry. If they don't, there should be an optional field platformAccess.image.pullSecrets that allows the user to specify these independently; when unset, the agent falls back to spec.image.pullSecrets as it currently does.

[labrenbe]

This is currently following the precedence of opa-operator. If that pull secret doesn't work then objectOverrides can still be used to override it. I think it's worth a discussion how much customization we want to allow for the agent without overrides.

[xeniape]

Just a question if this is intended behavior: if the address in the discovery dir is an external one (external ListenerClass), is it intended that the agent connects from outside using that external path?

[labrenbe]

This is a very good call-out. I thought there were limitations that prevent us from using the headless services, but I realized my assumption was wrong. Changed the agent to use the headless service instead which is how it should be done anyway in 14f9ee8.

[maltesander]

This is pretty arbitrary. Can we document / comment why?

[labrenbe]

I decided to focus on KRaft for the first version of the admin client as supporting clusters with zookeeper would add extra complexity. I will document that this is a current limitation of the first version of the kafka-agent. Similarly we decided not to support Kerberos for version 1 in stackabletech/issues#888.