Skip to content

Proposal: Support for Custom Authentication Type in Kafka Clients #148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Proposal: Support for Custom Authentication Type in Kafka Clients #148

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
da17166
Proposal: Support for Custom Authentication Type in Kafka Clients
Feb 9, 2025
5cdbca4
better formatting to improve the readability
Feb 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions 095-support-for-custom-authentication-type-in-kafka-clients.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Support for Custom Authentication Type in Kafka Clients
## Current situation
Strimzi currently supports several standard authentication mechanisms for Kafka clients, including:
- TLS-based authentication
- SASL mechanisms such as `scram-sha-256`, `scram-sha-512`, `plain`, and `oauth`
These mechanisms cover a wide range of use cases, but there is no built-in capability for users who need highly customized authentication logic.
## Motivation
Organizations may have unique security requirements that cannot be addressed by the existing authentication mechanisms. These requirements may involve integrating with proprietary security systems, leveraging custom token-based schemes, or handling complex credential management.
By providing support for custom authentication types, Strimzi will enable users to supply their own authentication logic while maintaining compatibility with Kafka security standards.
### Benefits:
- Greater flexibility for organizations with custom security requirements.
- Reduced need for workarounds when integrating with non-standard authentication systems.
- Better alignment with enterprise security architectures.
## Proposal
### Introduction
The proposal introduces a new Kafka client authentication type called `custom`. This type allows users to specify a fully qualified class name of a custom `AuthenticateCallbackHandler` implementation to handle their specific authentication logic.
### Configuration
The configuration for the custom authentication would look like this:
```yaml
authentication:
type: custom
customCallbackClass: com.example.kafka.auth.MyCustomAuthHandler
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

other than just configuring, you should explain that a user has to bake an image by adding the jar including the handler class, right?

```
### Key Changes
1. **New Class:** `KafkaClientAuthenticationCustom`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should be clear that it's going to be part of the api module

- Defines the `custom` authentication type.
- Includes a property `customCallbackClass` for specifying the custom handler.
2. **Volume and Secret Handling:**
- No volumes or secrets will be automatically mounted for the custom authentication type.
- Users are responsible for managing any required resources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine, but you should still explain how will the users do it -> the answer here is using the additional volumes through the spec.template section. You should expain it here. You should also explain how the users will add their own custom plugins you expect to use (likely by building a new container image and adding the required jar(s) there.

3. **Validation:**
- Strimzi will ensure the `customCallbackClass` property is provided and correctly formatted.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does exactly mean "correctly formatted"?

## Affected/not affected projects
### Affected
- **Cluster Operator:** Will require changes to handle the `custom` authentication type.
- **API:** New class and CRD validation for `KafkaClientAuthenticationCustom`.
- **Documentation:** Updated guidance for configuring and using custom authentication.
### Not affected
- Kafka Brokers (custom logic is client-side).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is relevant here. Brokers are anyway part of Apache Kafka project so not within Strimzi and a Strimzi proposal can't have any effect on Apache Kafka.

- User Operator.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also remove this one, otherwise the Topic Operator would be here as well.
Let's leave the affected part only.

## Compatibility
This proposal maintains backward compatibility by introducing an additional authentication option. Existing configurations using standard authentication mechanisms remain unaffected.