-
-
Notifications
You must be signed in to change notification settings - Fork 280
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.
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
docs: extend example for kafka with x509 security #670
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putting this in the spec would say that client applications could either use mutual TLS or SASL/SCRAM to authenticate with the Kafka cluster - using the same address for either.
More typically when using different auth approaches with Kafka, you'd have different URLs (in Kafka jargon, "listeners") for each security method.
Which would make the spec more like:
servers:
scram-connections:
url: test.mykafkacluster.org:18092
protocol: kafka-secure
description: Test broker
security:
- saslScram: []
mtls-connections:
url: test.mykafkacluster.org:28092
protocol: kafka-secure
description: Test broker
security:
- certs: []
components:
securitySchemes:
saslScram:
type: scramSha256
description: Provide your username and password for SASL/SCRAM authentication
certs:
type: X509
description: Download the certificate files from service provider
I touched base with @nictownsend as well, and we don't actually know how you could configure a single Kafka listener to support both mutual TLS and SASL/SCRAM. We've not tried, so we're not 100% certain, but we suspect it wouldn't be possible to setup Kafka to support the spec as it is in the PR. (We know you can get a single listener to support different SASL mechanisms, so you could support both SASL/PLAIN and SASL/SCRAM on a single URL for example. But not different protocols like SASL and mTLS).
@dalelane thanks for the review, I update example by following your advice |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
/rtm |
🎉 This PR is included in version 2.5.0-next-major-spec.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Forget about the last comment saying it was released in version 2.5.0-next-major-spec.1. I made a mistake and it created this version but it should actually be |
🎉 This PR is included in version 2.5.0-next-spec.5 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Recent comments about the release from the bot were added by mistake. More details in #899 |
this is driven by https://github.com/asyncapi/nodejs-template/pull/103/files PR where I had to add customized asyncapi file just with one tiny change, could be better to extend official example and use it in test instead of custom version
I think we still have this unwritten rule that best if templates work with official examples, if only possible