docs for $GATEWAY_SECURITY_MODE #760
Open
+326
−101
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| | `GATEWAY_AUTHENTICATION_CONNECTION_MAX_REAUTH_MS` | Force the client re-authentication after this amount of time. If set to 0, we never force the client to re-authenticate until the next connection | `0` | | ||
| | **Environment variable** | **Description** | **Default value** | | ||
| |---------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------| | ||
| | `GATEWAY_SECURITY_PROTOCOL` | The type of authentication clients should use to connect to Gateway. Valid values are: `PLAINTEXT`, `SASL_PLAINTEXT`, `SASL_SSL`, `SSL`, `DELEGATED_SASL_PLAINTEXT` and `DELEGATED_SASL_SSL`. | The default value depends on KAFKA_SECURITY_PROTOCOL.  | |
There was a problem hiding this comment.
edited... agin. do we really have DELEGATED defaults... surely it will set GATEWAY_SECURITY_MODE etc instead?
Also. we should indicate that although valid DELEGATED protocols are deprecated and link to a guide for upgrading.
| | **Environment variable** | **Description** | **Default value** | | ||
| |---------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------| | ||
| | `GATEWAY_SECURITY_PROTOCOL` | The type of authentication clients should use to connect to Gateway. Valid values are: `PLAINTEXT`, `SASL_PLAINTEXT`, `SASL_SSL`, `SSL`, `DELEGATED_SASL_PLAINTEXT` and `DELEGATED_SASL_SSL`. | The default value depends on KAFKA_SECURITY_PROTOCOL.  | | ||
| | `GATEWAY_SECURITY_MODE` | Define where authentication takes place, Gateway or Kafka. Valid values are: `GATEWAY_MANAGED`, `KAFKA_MANAGED`. Note that `SSL` and `PLAINTEXT` are not valid inputs in `KAFKA_MANAGED` mode and will be rejected. | If not provided, we infer based upon `GATEWAY_SECURITY_PROTOCOL` value.  | |
There was a problem hiding this comment.
Note that SSL and PLAINTEXT are not valid inputs in KAFKA_MANAGED mode and will be rejected.
doesn't amke sense... also i think too much complexity for such a table. i think we should have a dedicated table explaining the valid combinations.
Comment on lines
27
to
36
| | GATEWAY_SECURITY_MODE | GATEWAY_SECURITY_PROTOCOL | Previous version GATEWAY_SECURITY_PROTOCOL equivalent | | ||
| |-----------------------|---------------------------|--------------------------------------------------------| | ||
| | GATEWAY_MANAGED | SASL_PLAINTEXT | SASL_PLAINTEXT | | ||
| | GATEWAY_MANAGED | SASL_SSL | SASL_SSL | | ||
| | GATEWAY_MANAGED | SSL | SSL | | ||
| | GATEWAY_MANAGED | PLAINTEXT | PLAINTEXT | | ||
| | KAFKA_MANAGED | SASL_PLAINTEXT | DELEGATED_SASL_PLAINTEXT | | ||
| | KAFKA_MANAGED | SASL_SSL | DELEGATED_SASL_SSL | | ||
| | KAFKA_MANAGED | SSL | Invalid auth mode with Kafka. Will be rejected. | | ||
| | KAFKA_MANAGED | PLAINTEXT | Invalid auth mode with Kafka. Will be rejected. | |
There was a problem hiding this comment.
this table should be in docs in two places.
- guide for new users
- guide for users migrating
suggest we link to both from here and in relevant sections of env variables table.
|
will tidy this up - lots has changed since I first updated it |
jpalmerr
commented
Jun 2, 2025
Comment on lines
+46
to
+47
| * **SASL_SSL**: Authentication from the client is mandatory and will be forwarded to the backend Kafka cluster for validation. All communication between the client and the Gateway broker is encrypted using TLS. The Gateway will intercept the SASL authentication exchange to detect authenticated principals. | ||
| All credentials are managed by your backend Kafka. |
There was a problem hiding this comment.
There was no mention of SASL_SSL before.
- There could have been a reason for this im unaware of
- I could use a second opinion on this definition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://linear.app/conduktor/project/gateway-security-ux-7d62db5252bc/overview
https://linear.app/conduktor/issue/YSH-17/support-gateway-managed
https://linear.app/conduktor/issue/YSH-18/remove-usage-of-delegated-xxx-security-mode-from-code-base
https://linear.app/conduktor/issue/YSH-19/override-acl-enabled-to-true-when-isgatewaymanaged
Security Mode
The aim of these UX changes are to split the security protocol decision making into two steps. What is responsible for authentication? How will we be authenticating?
Previously both these questions were resolved by the
GATEWAY_SECURITY_PROTOCOL. Instead, we set the who usingGATEWAY_SECURITY_MODEand simplify the options for the how, which is stillGATEWAY_SECURITY_PROTOCOL.Therefore, our documentation should be pointing the new user towards using both variables as part of the recommended set up. Ideally, a new user won't have to encounter the terminology
DELEGATEDat all.However, these changes are non breaking, we still support
DELEGATED_XXXprotocols, so it is important we:a) state the changes begin from version
3.10.0b) point existing users to a migration guide where they would have expected documentation of
DELEGATED.This is why we have lots of deprecation notices in this change.
Acl enabled
We want to migrate users off of setting this explicitly, as we want to decide this capability based upon the security mode
KAFKA_MANAGED-> acl enabled falseGATEWAY_MANAGED-> acl enabled trueHowever, since GATEWAY_SECURITY_MODE is an optional non breaking field, the same must be true of
ACL_ENABLED.Therefore, we must again
a) explain to new users on how this is automatically set
b) show existing users that it is deprecated, how it is still supported, and how to migrate
If the user attempts to set
KAFKA_MANAGEDsecurity mode with acl enabled set totrue, we will error with an appropriate message